Weekly Edition
Return to the Distributions page
| |||||||||||||
Shuttleworth: Quality has a new name
Here's the
traditional naming post from Mark Shuttleworth; the next Ubuntu release
will be code-named Quantal Quetzal. Various other bits of information can
be found there as well: "Rumours and allegations of a move from
Upstart to SystemD are unfounded: Upstart has a huge battery of tests, the
competition has virtually none. Upstart knows everything it wants to be,
the competition wants to be everything. Quality comes from focus and
clarity of purpose, it comes from careful design and rigorous
practices. After a review by the Ubuntu Foundations team our course is
clear: we’re committed to Upstart, it’s the better choice for a modern
init, innit."
Those who are interested can also read Lennart Poettering's response. (Log in to post comments)
Upstart vs systemd Posted Apr 24, 2012 14:14 UTC (Tue) by man_ls (subscriber, #15091) [Link] Good, we needed another technical divide between Canonical and Red Hat. And the next flamewar about init systems was long overdue; it makes one miss the good old times when init systems were just another boring topic.I am only half-joking. To tell the truth, the matter is not all that interesting, flamewars notwithstanding. Both of them should work fine on any modern Linux system. If any of them is harder to maintain, well, distros are doing that job so they should know better. I just want to start my custom processes using a script and I guess that option will continue to work.
Upstart vs systemd Posted Apr 26, 2012 11:25 UTC (Thu) by hummassa (subscriber, #307) [Link]
OTOH, the RH vs Canonical, emacs-vs-vim-style flamefest below is funny to read.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 14:27 UTC (Tue) by spaetz (subscriber, #32870) [Link]
I do not want to comment on the decision to adopt or not adopt any init system. But Lennart's response is flawed. I recall:
1 devfs was deprecated, with udev being the hailed successor 2 Ubuntu develops upstart 3 Lennart develops systemd 4 udev gets merged into upstart 5 Lennart criticizes Ubuntu for sticking to an inferior init system which requires Upstart to rely on orphaned infrastructure such as *independent udev*. WHAT? This might well be an issue of control, but if it is, I can see where it comes from. 6 On an unrelated side note systemd now also contains a reimplementation of readahead.
It might well be that systemd is superior infrastructure, I cannot judge this. But the way to go about and call out others as control freaks, when what I see is unilateral decisions being made in systemd-land. If it is not possible to use udev anymore without systemd without being critized, something is very wrong.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 14:33 UTC (Tue) by rfunk (subscriber, #4054) [Link]
udev got merged into systemd, not into upstart.
https://lwn.net/Articles/490413/ I *think* that's what you meant, but it's not entirely clear.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 14:36 UTC (Tue) by ovitters (subscriber, #27950) [Link]
Which bit is flawed? Does it really matter who did something first? You say something about control, but Lennart + udev people merged it. He cannot do that on his own.
I do see advocacy in his blogpost, but that's pretty much to be expected (he develops systemd, of course he'll think it is great).
Shuttleworth: Quality has a new name Posted Apr 24, 2012 15:14 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
when udev was merged with systemd, everyone was assured that this would not force them to use systemd, that udev would continue to be available stand-along.
now he is saying that it's orphaned??? that didn't take long.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 16:54 UTC (Tue) by cmorgan (guest, #71980) [Link]
It sounded like he meant that because Ubuntu was sticking with some older version of udev that they were missing out on improvements brought by being able to build systemd and udev together. Would be useful to ask Lennart to clarify though.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 17:08 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
Ubuntu should not have to stick to an older version of udev unless the new versions are so tied in to systemd that they can't be used independently.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:28 UTC (Tue) by spaetz (subscriber, #32870) [Link]
no, it did not sound like he meant it this way. he said "
Because they have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development."
how does this leave room for interpretation? independent udev is "orphaned by its developers"
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:50 UTC (Tue) by ovitters (subscriber, #27950) [Link]
I read independent as in different tarball. The original announcement made it really clear that it was just about sharing some code and the build system.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:40 UTC (Tue) by scientes (guest, #83068) [Link]
did udev once have links to consolekit in some form or fashion that Canonical needs? (barring their adoption of systemd-logind)
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:13 UTC (Tue) by ovitters (subscriber, #27950) [Link]
No clue. Hope Lennart or someone else will read LWN and clarify.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:43 UTC (Tue) by mezcalero (subscriber, #45103) [Link]
We don't support udev in an separate tarball anymore. We do support udev built from the systemd tree used independently of systemd. We need that for our own initrds, so we will support that for a long time.
Lennart
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:49 UTC (Tue) by jubal (subscriber, #67202) [Link] Is there a big problem to write a couple of lines that generate a separate udev tarball for those who don't need the systemd part?
Shuttleworth: Quality has a new name Posted Apr 25, 2012 5:09 UTC (Wed) by scientes (guest, #83068) [Link]
I don't think Ubuntu is using a tarball, I think they are using git.
(I was going to write a mocking post initially)
Shuttleworth: Quality has a new name Posted Apr 25, 2012 9:31 UTC (Wed) by jond (subscriber, #37669) [Link]
There isn't a big problem having the systemd code in the source tarballs for udev packages.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 8:54 UTC (Wed) by chrisV (subscriber, #43417) [Link]
"We don't support udev in an separate tarball anymore. We do support udev built from the systemd tree used independently of systemd. We need that for our own initrds, so we will support that for a long time."
Then why did you say in your Google+ posting:
"Because [Canonical] have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development"
Both your statements cannot be true, except perhaps in relation to ConsoleKit (if independent development of that is ceasing), but that is a relatively trivial piece of code.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:34 UTC (Tue) by scientes (guest, #83068) [Link]
> 6 On an unrelated side note systemd now also contains a reimplementation of read-ahead.
IIRC, upstarts readahead requires a patch to the kernel, systemd's does not.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 2:38 UTC (Fri) by geissert (subscriber, #61258) [Link]
there's no such thing such as "upstarts readahead" (sic). It's yet another readahead implementation, with its own merits, and happens to be started by an upstart job. That's it.
Last I checked, systemd's used the audit subsystem, which is what the previous "readahead" from Fedora used. Using the audit subsystem has its own issues.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 3:52 UTC (Fri) by spaetz (subscriber, #32870) [Link]
> Last I checked, systemd's used the audit subsystem, which is what the previous "readahead" from Fedora used. Using the audit subsystem has its own issues.
But it has a built-in reimplementation which is pretty new
Shuttleworth: Quality has a new name Posted Apr 27, 2012 9:01 UTC (Fri) by michich (subscriber, #17902) [Link]
systemd's readahead uses fanotify, not audit.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 14:31 UTC (Tue) by ovitters (subscriber, #27950) [Link]
Really unfortunate.
Already about 7 GNOME modules or so have different code paths for systemd vs upstart (ConsoleKit). Some features are systemd only (the GDM multi seat stuff). Different code paths is bad for QA and also limits what you can do.
I'd wish for the major distributions at least everything until "X" starts was the same (so not only systemd); makes things so much easier (less code paths, more QA, etc). Now the responsibility and effort to keep supporting ConsoleKit also lies within the maintainers of those GNOME modules (more code paths costs time and effort).
Note that I don't really care if systemd or upstart had the majority of the support
Shuttleworth: Quality has a new name Posted Apr 24, 2012 17:55 UTC (Tue) by Lennie (subscriber, #49641) [Link]
Development of ConsoleKit seems pretty dead already, right ?:
https://mail.gnome.org/archives/distributor-list/2012-Jan...
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:48 UTC (Tue) by ovitters (subscriber, #27950) [Link]
A few people stepped up to maintain ConsoleKit after that email (the stepping up was triggered by the email fwiw). ConsoleKit is also used on other operating systems. IMO, I'd prefer if another OS just implemented the same functionality as systemd. On Linux, systemd.
Burden often lies with higher (kernel,init system being low, GUI stuff = high) components to support the various ways of doing things (between distributions and operating systems). Lately I think the better solution it to make a few assumptions/requirements about .
Like setting the timezone in GNOME 3.4. It now only calls a d-bus API. There are some daemons which implement these. If some distribution has their own ideas on how timezones configuration is done: cool, but either support the d-bus API + write your own daemon else GNOME won't be able to set the timezone anymore. This caused a bit of a flamewar though (IIRC mostly because the requirement&change was not so well announced+communicated).
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:58 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
If Gnome only supports setting the timezone via d-bus, then it also needs to include the daemon to listen to d-bus and set the timezone in the traditional way.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:39 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
I believe GNOME is doing exactly that, by making systemd a blessed external dependency with the expectation that systemd will be providing the service.
And systemd can be used in this way without also being the init for the system. This has been repeatedly stated.
So vendors who want to provide a GNOME desktop on top of a linux kernel will most likely take the easiest path, build/package a version of systemd that provides all the DBUS services GNOME expects but not use it for init. I'm pretty sure Ubuntu and Debian will be doing exactly that for their alternative GNOME desktop environment offerings. ChromeOS doesn't have to worry about it.
-jef
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:55 UTC (Tue) by mbiebl (subscriber, #41876) [Link]
If you look at e.g. the timedated component of systemd, you'll notice that it is tightly coupled with systemd itself, specifically for the ntp bits [1].
So while you theoretically can install timedated independend of systemd, it will only work fully, if systemd is also pid 1.
[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/time...
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:14 UTC (Tue) by mbiebl (subscriber, #41876) [Link]
That said, (re)implementing the timedated or hostnamed D-Bus interfaces is not particular complicated. The D-Bus API is well defined and it would be very easy to implement those two daemons in say a few lines of python.
A bigger issue is the move from ConsoleKit to systemd-logind. Last time I checked, we had around 80 packages [1] in Debian using the ConsoleKit D-Bus interface [2]. ConsoleKit and systemd-logind do not provide a compatible interface, so applications need to be updated to support systemd-logind, and while a few (GNOME) applications support a fallback during runtime, most of them don't. And as systemd-logind is again tightly coupled to systemd, it's an all or nothing decision.
[1] http://people.debian.org/~biebl/ck/ck-by-package.txt
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:12 UTC (Tue) by ovitters (subscriber, #27950) [Link]
I already said that it is not for GNOME to do that. Systemd provides daemons which implement the API. However, those daemons might not do the right thing on every distribution. But the reliance is just on the d-bus API, not on the "systemd" daemons (they don't rely on systemd, though likely do the wrong thing on other distributions).
If some distribution wants to do their own thing, implement the API. It is fairly easy and e.g. Ubuntu has done so. If not, too bad, no timezone setting (and a few other things.. IIRC date+time as well) for your distribution.
That some people don't like d-bus and want extreme ability to change things: cool, but distribution choice, their burden to either maintain these daemons, or not have the feature. Ability to customize comes at a price; excepting others to share the same view and do that work might result in some disappointment.
Note that due to just relying on d-bus API, GNOME time zone setting should actually work on more distributions than before (old code only had support for 3-4 IIRC; exact amount was mentioned in the desktop-devel-list thread).
What I do acknowledge (and have mentioned before, so...) is that communication should've been handled better. Also, at that time general expectation was that everyone (distributions) would use systemd eventually (aside from distributions which advocate being different).
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:19 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
this is the attitude that is really hurting linux desktop acceptance
you are in effect saying
>I invent something new that uses some new mechanism to do something that has been done one way for the last 30 years.
>It's up to everyone else to adapt the old software to support my new mechanism, and if they choose not to, tough luck, they (and their users) just suffer.
There is nothing wrong with introducing something new. The problem only occurs when you insist that it's everybody else's job to support your new thing. What you should be doing instead is maintaining backwards compatibility and fallbacks to continue to support doing things the old way.
You obviously think your way is the best ever, but the problem is that the next guy comes along and thinks the same thing. As a result you end up with lots and lots of programs, all trying to redefine the 'correct' way to do something, and they are all doing it in slightly different ways.
It's far better to have incremental improvements that doesn't break existing users rather than having drastic improvements that break some subset of users in the process. The reason for this is that the "small subset" of users that get broken are different each time, and the result is that every user ends up getting broken at some point.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:00 UTC (Tue) by rahvin (subscriber, #16953) [Link]
Backward compatibility can be a very nasty trap. I wouldn't lightly suggest that backward compatibility be either essential or expected. One of the nice things about Linux is that it keeps moving forward, once you lay the legacy trap this progress becomes very difficult.
I agree we should minimize disruptions but sacrificing progress for compatibility is not something I personally want. That's what Redhat is for, so you can pay them lots of money to backport everything new to really old versions.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:11 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
Backwards compatibility can be a trap, if taken to extremes and done poorly
However, is there anyone who doesn't think the kernel has been better after implementing the "no regressions" policy? This is a form of mandated backwards compatibility.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:34 UTC (Tue) by Company (guest, #57006) [Link]
Linux - just like every other project in the Free desktop - takes the "we'll just remove the subsystem and adopt a new one" policy. In that approach you:
1. introduce a new thing that provides the same functionality 2. deprecate the old approach 3. (optionally) provide a compat mechanism to the old approach 4. port your software to the new approach 5. disable the old approach in distros 6. remove the old approach from upstream If you want examples of this, you can look into various multimedia backends (OSS, V4L1), /dev naming schemes or the names of your ethernet devices.
Keep in mind that step 4 does not necessarily involve "keeping stuff working with the old approach". That is usually dependent on the software projects' willingness to inflict pain on themselves.
Oh, and some more examples:
Shuttleworth: Quality has a new name Posted Apr 25, 2012 14:54 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you leave out a couple of critical points
in step 4 you need to make sure that your software continues to do everything it used to do
and you completely left out step 4.5, which is to wait until nobody is using the old approach before you go on to step 5
Gnome is a perfect example of how not to do this.
My making Gnome 2 and Gnome 3 unable to be installed at the same time, and incompatible with each other, they forced stesp 2-6 to all happen at the same time
Shuttleworth: Quality has a new name Posted Apr 26, 2012 1:01 UTC (Thu) by nevets (subscriber, #11875) [Link]
And you left out step 7. Which is for the dissatisfied user to:
a) find another implementation that suits their needs (xfce)
b) leave Linux all together (Mac OS/X)
Shuttleworth: Quality has a new name Posted Apr 25, 2012 6:30 UTC (Wed) by ovitters (subscriber, #27950) [Link]
I don't get what you mean with backwards compatibility, at all. It comes across as disagreement for the sake of disagreeing, or maybe I didn't explain myself, so I'll try again...
To summarize: GNOME 3.2 support 3-4 distributions. In GNOME 3.4 all these distributions are still supported, but via a different API. In practice, way more distributions are supported (as it is automatic if you use systemd).
There was no API exposing the timezone stuff in GNOME 3.2, just stuff in gnome-control-center. Every program which wanted to provide the same functionality had to repeat this implementation (e.g. KDE, GNOME Puppet scripts, etc).
Now, the maintainer making the change has been talking to loads of distributions and getting them to agree (except "hickup" with Ubuntu).
So pretty much all your fears have been thought of and handled.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:02 UTC (Tue) by drag (subscriber, #31333) [Link]
This is a traditional Linux problem.
It's core to the problems of having multiple distributions. People say that they want to have multiple implementations in order to get the best technical solution. This is great (with all sincerity), but the downside is that you are creating major headaches for people that want to build on top of your systems.
The closest analogy that comes to mind quickly is that the situation with Linux distributions is akin to trying to build railroads across the Sahara desert.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:25 UTC (Tue) by dgm (subscriber, #49227) [Link]
It's part of how software evolves. When a project tries to break new ground there's no standard interface with the rest of the World to conform to, so you make your own. If multiple projects try to cover the same needs at the same time they are going to develop different (and competing) interfaces. If all works right, all interfaces but one will die.
But what will happen if things do not go right? There will be a split, with different entrenched factions. This usually is a sign of lack of collaborative spirit between the parts. And it's not a good thing.
That this does not happen is our responsibility as users. We should be building pressure on Ubuntu and Fedora to agree -at least- on a common interface definition, so people can build on their work. You can start sending mails right now.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:31 UTC (Tue) by drag (subscriber, #31333) [Link]
Yes. I understand the theory very much.
The problem is that it is very rare that a technical solution is so poor that it can't be fixed or one that is so superior that it is worth abandoning the years of effort that went into making the old solution work.
There is no perfect answer to these problems.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:32 UTC (Tue) by pboddie (subscriber, #50784) [Link] I think you summarise the problem quite well, but there are obviously factors which drive people to go and make incompatible (and potentially less featured) solutions such as...
Combine the above with a disdain for transitional solutions - it's not as much fun to have a measured pace of development as it is to work on radically new stuff - and you have the conditions for some of the more prominent controversies of the Free Software desktop.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 9:49 UTC (Thu) by cas (subscriber, #52554) [Link] > There is no perfect answer to these problems. of course there is. You get all your development done by a gaggle of attention deficit disorder teenagers and twenty-somethings who know everything there is to know, certainly more than boring old farts, and who especially know that rewriting stuff from scratch every year or two is far cooler than boring stuff like fixing bugs. anyone who objects is automatically an old fart and "not our target audience" so their objections can be ignored or dismissed with varying degrees of sneering contempt, depending on how reasoned and sensible their objections were (and thus how uncomfortable they made you feel).
Shuttleworth: Quality has a new name Posted Apr 26, 2012 10:29 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Attention deficit disorder teenagers? Talk about being emotional!
Shuttleworth: Quality has a new name Posted Apr 26, 2012 10:40 UTC (Thu) by cas (subscriber, #52554) [Link]
it's a reference to JWZ's CADT definition:
Shuttleworth: Quality has a new name Posted Apr 26, 2012 12:24 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Said document succinctly (and, I believe, accurately) diagnoses the cause of the problem and in so doing makes it obvious that there is only one cure consistent with the ideals of software freedom which can possibly work: create an incentive. One could of course choose to hold forth about how it's manifestly evident that having bug-free software should be in and of itself all the incentive one should ever need to fix bugs, but the heathens aren't listening and the choir already agrees.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 16:27 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Ah, interesting. I disagree with jwz then :P
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]
I don't think there's much point in sending emails at this point. Upstart gained support for socket activation some time after systemd did, yet its author didn't make his mechanism compatible with systemd's and keeps bitching and whining about Poettering.
https://lists.ubuntu.com/archives/upstart-devel/2011-Marc...
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:31 UTC (Tue) by jubal (subscriber, #67202) [Link] Strange, we seem to have read something completely different.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:34 UTC (Tue) by filteredperception (guest, #5692) [Link]
"If all works right, all interfaces but one will die."
... "This usually is a sign of lack of collaborative spirit between the parts. And it's not a good thing."
I disagree, though perhaps semanticly if you are one of those people that tends to discuss things in a way which refers to the 95% market share as the entire market share. I.e. I agree with what you say *in large part*. But there is the 5% market share that thrives with multiplicity of solutions and seeming redundancy of work that you suggest is _always_ a bad/negative thing. Even if the non-primary remaining interfaces that did not 'die' as you hoped they would, only serve a <5% market share, or even if there are 2 that split the 90% primary market share, I see that situation as entirely healthy, and in fact a net benefit. It can facilitiate a development environment with more developers working on, and thusly understanding core areas of development. Take deep SELinux 'voodoo' for example, or anything sufficiently complex and infrastructural, that barring motivational factors, nobody in their right mind would want to waste their life's braincycles trying to understand. Do you really want such deeply important infrastructural code to only be understood by a couple of developers on one team? Or is it not beneficial to have a few competing seemingly redundant teams, motivated only by the kind of vi/emacs religious wars, continuing to understand and explore all the nooks and crannies of the problem space. All I'm saying, is that the attitudes you ascribe, make sense in a battlestar galactica, only 50K humans left scenario. But we've got 7 billion people on this planet. A little redundancy, even if motivated by partly-il-conceived geeky competitiveness and 'bikeshedding', seems like an entirely beneficial thing to me. I fear for a groupthink future that hammers down those with views that are competitive, often self-interested, and different from the primary consensus. Again, 7 billion people on this planet, that when they aren't engaged in seemingly inneficient artificial competition like sports or linux distribution competition, tend to get in much more damaging trouble.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 2:00 UTC (Wed) by dgm (subscriber, #49227) [Link]
What you say is true when talking about implementations. The case with interfaces is more simple, because:
1. competing options usually offer the same or very similar functionality. So, as long as it allows you to get the work done, it's not that important which standard is chosen as the fact that _one_ is chosen. The reason is that having one standard allows for networking effects that add the real value for users. An example would be pipe sections, or bolt sizes. 2. The standard is just a minimum. You can always add extensions, specially if the standard itself was designed for having them (think the X11 protocol).
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 14:55 UTC (Tue) by martin.langhoff (subscriber, #61417) [Link]
I find both Mark's and Lennart's comments un-enlightening. As part of OLPC (using Fedora) and long time Debian/Ubuntu user, this topic has my attention.
Even if you like systemd, it is clear to see that it is a very bold bet; it leads to a tightly coupled "core distro". This tight coupling is hard for Debian to manage, and would be very hard for Ubuntu to fork from Debian over this.
There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.
If you want to fast-track to a modern, competitive product, this "core distro" model is a winner. If you want not just the opportunity but the _concurrent shipping_ of many possible/competing implementations of core distro components, then it is unacceptable.
OLPC's team is shipping a "vertically integrated" product, we want to move fast and our system to use the latest smarts of the kernel and the whole stack. Debian is still catering to sysadmins and developers running quirky setups (FreeBSD kernels, alternative inits...).
This is the root of the divide. It is not pretty, and my best guess is that it will take a while to shake out. Hopefully not too long.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 19:26 UTC (Tue) by oldtomas (guest, #72579) [Link]
Very insightful overall. There's one aspect I often miss in this discussions, and that's hackability: a low-key entry path for folks who are not yet at the level of checking out C code and managing a patched version.
To me that is the *practical side* of GNU's "freedom 1". And SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding (no, I'm no fan of SysV init, but in the presence of the attitudes of the proponents of systemd and upstart, it still seems the best choice. Not technically, but socially).
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 20:41 UTC (Tue) by hazeii (guest, #82286) [Link]
Hear hear; the 'hackability' of linux (distros) is reducing fast.
The hood is not so much being welded shut, as everything underneath it is being made so complex and inter-related that only big companies have sufficient resources to make meaningful changes.
And that, of course, is exactly how they want it.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 20:59 UTC (Tue) by ovitters (subscriber, #27950) [Link]
I'm pretty sure the people who want to hack on things will still be able to; doesn't matter if they are paid by a company or not.
I further do not agree things are more difficult. Having just one way of doing things across distributions should make things easier to grasp; not more difficult. Further, a lot can now just be changed with a config file instead of knowing the right shell command (e.g. instead of knowing that there is a ulimit command and you can put that in a sysvinit script instead you can now change an option in a documented config file).
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 21:03 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
it may be nicer if you start learning things that way, but you have to know to go looking into the systemd documentation for this, and in the process ignore everything that you find in Unix/Linux documentation that predates systemd.
that's a huge change, and part of what people are objecting to.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 16:01 UTC (Thu) by pspinler (subscriber, #2922) [Link]
Except that shell knowledge is transitive, and applies to lots and lots of stuff. A 5% increase in your shell skills thus is a 5% increase in a quite large number of things.
On the other hand, systemd config files are specific to systemd, and knowledge gained there, even if it's easier to learn, is non-transitive. So I have to learn many, unrelated things to hack here. For instance, systemd config files, dbus interfaces and scripting, etc.
On the whole, I prefer the one skill set -> many areas approach.
-- Pat
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 17:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I'm inclined to suspect that the reason shell applies to so many things heavily depends on it having been the thing you could rely on to be there rather than actually being a good fit to the problem.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 2:17 UTC (Wed) by dgm (subscriber, #49227) [Link]
What a ridiculous claim. Why on Earth would a "big company" that makes a living on the work of volunteers, want to woo away those volunteers? That's not only stupid, it would be suicidal!
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 6:03 UTC (Wed) by paulj (subscriber, #341) [Link]
A few RedHat employed hackers now have raised concerns about Canonicals' ability to maintain the software they need to (including Lennart, in this post of his). It's at least well within the realms of possibility that RedHat has adopted a strategy of using their superior engineering resources to try exhaust those of their smaller rival, by re-engineering as many aspects of the Linux stack with closely-coupled and/or more monolithic systems.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 6:32 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
I assume you are referring to Lennart's changes: NetworkManager, pulse, systemd and friends.
I would say rather that these are fixes to real problems affecting real desktop users -- the old ifup scripts could not handle switching between wireless networks all the time, and init was slow as a dog and (as much as we all grew to know and love it) really did involve deep magic to manage.
The point of pulse was to manage sound across multiple users and applications smoothly. There were some apps *cough*flash*cough* which would routinely hijack the audio system, and I remember often having to reboot just to get my music back. Pulse, after the first few versions of Fedora anyway, has never given me that kind of crap.
In my experience, I've always resisted these changes at first, then after a year or two, started to love them. Because after the early bugs were worked through, they really were technically superior to the old systems, and often more configurable and more flexible. Since they're new, they tend not to be so discoverable or well-documented, which I think is what most "I loved init like a child!" posters here are actually complaining about.
For example, I still can't figure out how to use NetworkManager from a command-line, so I don't. (As a result, I need to do all sorts of ugly crap when moving between networks, crap which no end-user should be required to deal with. But no end-user -is- required to, as long as they install a DE, so this is fine.)
This stuff is all open-source and freely licensed, so there's no reason for other distributions not to use it. If this is Red Hat's strategy, it's pretty stupid, since it amounts to working for free for the competition.
To compare, consider the changes Ubuntu makes. In my experience, these start out as irritating, then transition to unusable. (After Unity, I threw in the towel, and stopped using Ubuntu anywhere) so I have no idea what they've been up to in the last few years. Upstart was crashy and confusing, hard to configure and poorly documented. Unity is a complete gong show. It looks like garbage, is non-discoverable and unusable, doesn't work on most computers, depends on high-end video drivers (which are mostly proprietary), and involved special tools and BINARY BLOBS to configure. The Ubuntu attitude has always been "our way or the highway", and this attitude has gotten worse, as they deviate further and further from the mainstream, in the WRONG DIRECTION, for NO REASON.
I had technically illiterate family members using Ubuntu. At first (around the 6.06 era) it worked great. Then they started breaking things in weird ways. For a while, I was able to work around their crap, apologize profusely and insist that I was "talking to the developers" about this "completely unprofessional" behaviour. Then Unity came around, and X stopped starting, and when I went to poke around, found the system internals completely trashed. Stuff was renamed, deleted, replaced, whatever, for seemingly no other reason than to be different. Since half the stuff couldn't be configured over SSH, and I had literally no clue what the UI looked like (even though it was a stock UI), this involved me physically travelling around to maintain these computers. In the 20th century.
After dicking around for a few hours, I said "go to Futile Shop, buy a $250 refurbished computer with Windows on it".
I didn't mean for this to be a rant about Ubuntu. My point was simply that I would not blame Red Hat for being hostile and uncooperative with the community. And I would absolutely accuse Canonical of this.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 7:58 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> Ubuntu attitude has always been "our way or the highway", and this attitude has gotten worse
Not that I believe Canonical is always making the right decisions, but it is possible to run stock Gnome Shell on an unmodified Ubuntu. Personally, I run Xubuntu and I am very happy with it, even using old and crappy graphics drivers. So, you can't really claim my way or the highway when other DEs are simply making similar decisions.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 8:34 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
>So, you can't really claim my way or the highway...
Without rehashing the specific arguments, I recall there being a lot of complaints in the beta release, followed by a grandiose blog post from Mark Shuttleworth, and the new buttons appeared in the final release anyway.
Of course, as the spin-off distros show, it is still possible to do your own thing with Ubuntu, provided you have the know-how.
> when other DEs are simply making similar decisions.
Yes, I should have been clearer that Unity is not alone in their silly changes. Gnome 3, Windows Metro, and any other "touchscreen" desktop environments are just as guilty of making poor UI choices. The difference is that Canonical has put a significant amount of effort into making their -own- poor UI, whereas other distributions focus their efforts on more useful pursuits.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 17:47 UTC (Thu) by JanC_ (guest, #34940) [Link]
> My "our way or the highway" comment was regarding Ubuntu's
> attitude toward user feedback -- for example, the flak they > got when they moved the maximize/minimize/close buttons to > the other side of the title bar.
The majority of Ubuntu users never complained about that, but a loud minority did. (Personally, I find that it's not really all that important which side these buttons are, and most people get used to it.)
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 17:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I see that most Ubuntu users around me just adjusted the settings using regedit^W gsettings.
systemd & the tightly couple core band vs a world of many inits Posted Apr 30, 2012 15:52 UTC (Mon) by jbicha (subscriber, #75043) [Link]
For full-screen windows in Unity, the minimize/maximize buttons make the most sense in the top left corner.
Of course Unity didn't exist in 10.04 and the reasoning wasn't explained well then.
systemd & the tightly couple core band vs a world of many inits Posted Apr 30, 2012 16:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>For full-screen windows in Unity, the minimize/maximize buttons make the most sense in the top left corner.
Why?
systemd & the tightly couple core band vs a world of many inits Posted Apr 30, 2012 19:35 UTC (Mon) by jbicha (subscriber, #75043) [Link]
The entire top right side is taken up with "indicator" status menus, which frees up the top left corner as a hot corner for the minimize/maximize/close buttons.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 7:58 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
I didn't write NetworkManager.
Lennart
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 8:35 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
My mistake. I (mis)read somewhere that you had.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 21:36 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
It's an easy mistake:
1. People like to flame about anything Lennart has written. 2. People like to flame about NetworkManager. 3. Therefore Lennart wrote NetworkManager.
systemd & the tightly couple core band vs a world of many inits Posted May 3, 2012 0:52 UTC (Thu) by josh (subscriber, #17465) [Link]
For much the same reasons, really. NetworkManager, systemd, and pulseaudio all follow a similar policy of "no hacking around broken kernel code, fix the kernel". In all three cases, that policy results in occasional short-term breakage and "doesn't work for me", and long-term awesomeness.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 12:08 UTC (Wed) by james (subscriber, #1325) [Link] I still can't figure out how to use NetworkManager from a command-line, so I don't.man nmcli should tell you how to manage it, and https://live.gnome.org/NetworkManager/SystemSettings should tell you how to configure it through text files.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 15:46 UTC (Wed) by drag (subscriber, #31333) [Link]
Network-Manager is awesome on a server.
For example:
I wouldn't even know were to start with configuring 802.1x network access controls (very different from 802.11) on Redhat and Debian and Suse, but I know I can do it all the same way on all three systems if I am using Network Manager.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 21:38 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
Please tell me how I can connect to a WPA2-protected network with a passphrase using nmcli. Please.
I've read 'man nmcli'. It didn't help.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 21:47 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
I am not familiar with nmcli, but cnetworkmanager[1] can connect to WPA networks with passphrases from the command-line, using NetworkManager. It has a fairly simple, high-level interface.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 1:54 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
nmcli is the successor to cnetworkmanager[1]. nmcli cannot yet make new connection configurations on its own.
[1]http://repo.or.cz/w/cnetworkmanager.git/commitdiff/e2c001...
systemd & the tightly couple core band vs a world of many inits Posted May 3, 2012 20:55 UTC (Thu) by runciter (guest, #75370) [Link]
I'd like to recommend wicd with wicd-curses. Managing wireless connections has been a pleasure ever since I discovered it.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 21:32 UTC (Tue) by vonbrand (subscriber, #4458) [Link] To me, the baroque SysVinit scripts are some of the more opaque code I've ever seen. This stuff is definitively not easily hackable at all (yes, I had to tweak some of those scripts and even wrote a few very simple ones from scratch). Besides, the whole idea is very fundamentally broken: There can't be a "reasonable order for starting/shutting down services," the same way as just adding some "precedence" doesn't help a bit at figuring out the prerequisites, even less making sure they are all running OK before starting something. It was enough for SysVr4 (i.e., server-ish machines which were started in some almost unchanging configuration once a month or so), but it definitely doesn't cut it for today's ever-changing desktops.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 21:45 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I have no trouble with the idea that desktops/laptops/tablets want to do things differently then how servers have done it for years.
However, I do have trouble with the idea that if it's a good thing for (some/many) laptops, then servers and embedded devices need to use it as well.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 23:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
My embedded devices use SystemD for socket activation and startup. It works really really great.
And I won't mind systemd's containment functionality on my servers.
For instance, a SIMPLE task like "allow the Java program started by this script to listen on port 80" is not really possible with initscripts. At least my puny brain was not able to cope with all the capability inheritance over UID change crap.
With systemd? It's easy! A few lines in the service file and you're done.
Ditto for filesystem containment and secure /tmp.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 5:33 UTC (Wed) by misc (subscriber, #73730) [Link]
With software such as bind ( where you never can be sure that it got shutdown thanks to the rdnc message passing system to close it ), or apache, where I routinely see restart being blocked by some child that only arcane shell can kill, I would be among the first to celebrate systemd and cgroup controled process on the server.
I faced issue with sympa not starting and blocking on wait because it needed postgresql to be started first. We see issues with some daemons starting faster than the network card ( cause network service say "ok, i am ok", while it is not, Mandriva used to have a service "network-up" just for that ).
The way we set limit on file descriptor or anything is dependent on the initscript, the distribution, and usually hard to automate. With systemd, that's just .ini, in well defined location with the same and guaranteed semantics, something that is much easier to automate and to deploy.
The old approach was fragile and, stuff like "having 3 openvpn" was done by cut and paste of the initscripts, that's not really ideal IMHO. There is lots of duplicated code in all initscripts from distribution, and that's not how I envision long term maintainance. Gentoo init system was a fresh approach on that point, kudos to them, and systemd push that further.
I cannot comment on embedded device, but for a server, I see the values, even if I understand that some people feel the sysv init way to be fine for them.
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 22:49 UTC (Sat) by speedster1 (subscriber, #8143) [Link]
> To me, the baroque SysVinit scripts are some of the more opaque code I've ever seen. This stuff is definitively not easily hackable at all (yes, I had to tweak some of those scripts and even wrote a few very simple ones from scratch).
I'm curious which startup scripts you ran across that were a painful mess. I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed. Plenty of startup scripts for custom services as well. Wondering if our standards for painful shell code are different, or if you were poking in an area that I never had to modify.
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 23:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
How about Postfix or something like Tomcat or Jetty?
And I still can't get why my BIND hangs during shutdown (something to do with RNDC which I just don't have energy to debug).
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 23:52 UTC (Sat) by speedster1 (subscriber, #8143) [Link]
Never dealt with any of those, so maybe my running services are just better behaved and don't require twisted setup scripts... exim, dovecot, lighttpd, dhcp, dnsmasq, apache, mysql, nfs, upnp, vnc, mdadm etc
systemd & the tightly couple core band vs a world of many inits Posted Apr 29, 2012 1:21 UTC (Sun) by jimparis (subscriber, #38647) [Link]
> And I still can't get why my BIND hangs during shutdown
If you're running Debian or Ubuntu: http://bugs.debian.org/570852
systemd & the tightly couple core band vs a world of many inits Posted Apr 29, 2012 10:10 UTC (Sun) by anselm (subscriber, #2796) [Link] I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed. They are still 90% boiler plate, and distribution-specific boiler plate at that. If systemd did nothing except replacing that boiler plate with small distribution-independent configuration files (which is a minuscule part of what it actually does) it would still be a net win.
A bit of boilerplate is not always a big deal, but systemd respawn is nice Posted Apr 29, 2012 18:29 UTC (Sun) by speedster1 (subscriber, #8143) [Link]
If you mean net win on the large scale, for developers of large distros, I'd agree with you. However there are other niches where systemd would not win on that basis.
Boilerplate code is not automatically terrible in all situations. For projects that have lots of churn, it can be a hiding place for bugs unless there are good automated tools to ensure every instance gets updated. If the boilerplate is horribly ugly, it can make your eyes hurt from having to look at it so often.
However the init scripts on my embedded projects don't fit that category, nor RHEL init scripts for a non-embedded project, nor the init scripts on my debian server, nor the init scripts on my gentoo development station. The scripts are normal-looking shell scripts which are all the more easily understood because they follow a common pattern and well-known purpose. For a small number of already well-behaved systems (not servers that must run somewhat ill-behaved services), switching from shell scripts to denser config files may not offer any benefit.
BUT, for my embedded projects, systemd does currently offer one much more compelling feature than replacing some small easily-understood shell scripts with even smaller systemd configs: finer respawn control. Busybox init is very limited in that respect. Ability to start and stop a service (init.d), OR ability to respawn (inittab). No control over respawn timing either. In the one current project where we are able to give systemd a spin, configurable respawn policy is the actual practical advantage over sysv-style init for ; we don't have the sorts of daemons that really call for cgroup features otherwise (e.g. misbehaving child processes that don't get cleaned up properly otherwise).
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 22:33 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> And SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding
What a load of crap. sh is an *extremely* baroque and quirky language, and you have to learn a bazillion tools as well in order to write anything useful. Writing systemd unit files otoh is a piece of cake, and if you really, really need to write a shell script in order to start your daemon, systemd won't stop you.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 22:40 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> sh is an *extremely* baroque and quirky language, and you have to learn a bazillion tools as well in order to write anything useful.
yes, but it's one that sysadmins are very familiar with. They need it and use it for all sort of other things so your objection really doesn't matter.
systems that don't have sysadmins will probably not change the configuration anyway, so whatever the distro provides is almost always good enough for them.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 22:51 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> yes, but it's one that sysadmins are very familiar with. They need it and use it for all sort of other things so your objection really doesn't matter.
Oh, it very much does. Writing sh scripts is much harder than writing simple ini-style configuration files even if you know sh. And actually, many admins know it barely enough to somehow get by. When did you last meet a sysadmin who knows the difference between cat << EOF and cat << "EOF"?
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 12:36 UTC (Wed) by sciurus (subscriber, #58832) [Link]
Variable interpolation. Don't underestimate the sysadmin's ability to memorize arcana. :-)
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 19:22 UTC (Thu) by cdmiller (subscriber, #2813) [Link]
Hmm, that would be every sysadmin in our shop, including the primary Windows server admin.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 23:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
As a sysadmin maintaining a big money-sucking cluster on Amazon EC2, I wish to go back in time and exterminate EVERYONE who thinks that shell scripts are a good idea before they are born.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 23:26 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you are entitled to do whatever you want on your systems.
But why do you think you have the right to dictate what other people do on their systems?
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 5:28 UTC (Wed) by cmccabe (guest, #60281) [Link]
He's a sysadmin. Of course he wants to dictate what you do on the system :)
(joke)
But in all seriousness, the whole "SysV init is simpler" thing just ain't true. And you can still write SysV init scripts under either Upstart or Systemd, if you feel like you must.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 11:04 UTC (Wed) by dgm (subscriber, #49227) [Link]
Well, it is, and it isn't at the same time.
Init, the process, is simple. It's code is simple, because it's job is simple. And that's because the grunt work is left for the shell scripts that init runs. Init itself doesn't do much.
If you consider init, plus the directory layout conventions, plus the script conventions, plus the additional tools, then maybe init is not so much simpler than Systemd or Upstart. But all that is optional, mind you. Remember how Arjan van de Ven got his system booting to desktop in just five seconds. They did so with plain old init (and plenty of ingenuity).
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 14:41 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
The same Arjan is now working with the systemd folks and pushed systemd into multiple intel projects, simply because it offers the best performance.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 19:16 UTC (Wed) by oldtomas (guest, #72579) [Link]
Hm. If one trusts this source [1], Debian SysV is the most concise, by a long shot.
[1] <http://en.wikipedia.org/wiki/OpenRC#Size_and_complexity>
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 22:49 UTC (Thu) by s0f4r (subscriber, #52284) [Link]
The same Arjan who game the talk at Linux Plumbers together with me. And, our newest work will reduce boot time even further, while doing more, be more robust, and scale across many more services and devices in systems.
Arjan and me are supporting systemd in many ways, with code, feedback, prototypes and exploration of unwritten mechanisms.
For example, at the Tizen Conference in May, I will be presenting a prototype `systemd --user` initialized desktop that entirely removes XDG autostart in favor of treating everything that starts as `a service`, even for user-started programs (such as, Xorg, your window manager, the session bus).
sysvinit didn't scale - we knew that already in 2009, which is exactly why we had been talking with Lennert and folks for a loooong time to come up with something better.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 15:40 UTC (Wed) by jedidiah (guest, #20319) [Link]
The simpler part of init scripts is not the scripts themselves but how they interact with each other. As far as the script themselves being unmaintainable spaghetti, you can do that with any language. I am sure as Upstart gains more traction more cruft and craziness will build up.
Init and bash are things that have had decades to show it's warts.
You just haven't given Upstart a chance yet. '-)
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 7:56 UTC (Wed) by HelloWorld (guest, #56129) [Link]
+1
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 10:44 UTC (Wed) by njs (guest, #40338) [Link]
> SysV init is definitely the most hackable of the alternatives discussed here -- all its baroque clumsiness notwithstanding
It occurs to me that this is exactly the same argument that justifies using PHP.
I don't know if that makes it more or less convincing.
Hackability Posted Apr 26, 2012 17:20 UTC (Thu) by oldtomas (guest, #72579) [Link]
"It occurs to me that this is exactly the same argument that justifies using PHP"
Sorry. Wrong analogy: In which way is PHP code more hackable than say Perl, Python, shell or Tcl?
If the code is more or less well-written, they are more or less at the same hackability level.
OTOH, a bunch of more or less well written shell scripts, as Debians SysV init is, is infinitely more hackable than a fuzzball of 100-200 kloc for systemd and its dependencies.
Not that I am a friend of SysV init. One of the things I miss from BSD init is the possibility of letting init watch the daemons (remember respawn)?, which the newer systems are acquiring again. But the "collateral baggage" they all bring in is so unappetizing overall that I'll prefer to cling to SysV.
Hackability Posted Apr 26, 2012 17:35 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
One thing that I think people are not accounting for is the fact that RedHat sysV init scripts tend to be especially bad, with scripts calling other scripts taht source other scripts that read and parse config files.... so that you have to dig many layers down to figure out what's happening.
SysV init scripts don't need to be nearly this complicated, and on other distros they aren't.
Hackability Posted Apr 26, 2012 18:21 UTC (Thu) by njs (guest, #40338) [Link]
Yes, that's my point. PHP's "hackability" has nothing to do with its merits as a language -- if it did, then it would have been strangled at birth. Its "hackability" is that random users can open up a file, see some HTML and familiar bits of their webpage and bits of code scattered around, and start copy-pasting and tweaking to get it to do something different. The code is horrible, but easily accessible for tweaking. PHP's success is entirely due to its providing a "low-key entry path for folks who are not yet at the level of [doing real programming]".
Also, typical PHP web-pages and typical SysV init scripts probably have comparable levels of copy-pasted code...
Hackability Posted Apr 26, 2012 19:21 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> OTOH, a bunch of more or less well written shell scripts, as Debians SysV init is, is infinitely more hackable than a fuzzball of 100-200 kloc for systemd and its dependencies.
That's just a lie. If you want to compare systemd and sysvinit in a meaningful way, you can't just look at the source code of sysvinit and the init scripts. You also have to include the shell which runs the init scripts and all tools called from therein (i. e. cat, sed, awk and whatnot). And if you do that, it turns out that the sysvinit solution is much, *much*, *MUCH* bigger and definitely less hackable than systemd.
Hackability Posted Apr 26, 2012 19:33 UTC (Thu) by cdmiller (subscriber, #2813) [Link]
As one never needs to patch and recompile anything from /bin to hack a work around into an init script, It's your proposed comparison which lacks any pragmatic meaning.
Hackability Posted Apr 26, 2012 20:26 UTC (Thu) by HelloWorld (guest, #56129) [Link]
I've never needed to recompile systemd either, so what kind of argument is that supposed to be?
Hackability Posted Apr 28, 2012 20:21 UTC (Sat) by man_ls (subscriber, #15091) [Link] In the context of hackability it makes perfect sense; if you never had to recompile then you never did hack systemd. To hack on SysV init you just change a script (and you don't have to recompile bash).
Hackability Posted Apr 26, 2012 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Nobody stops you from rewriting a systemd unit file as a sh/bash script if you hit a deficiency in systemd.
Remember, it's fully compatible with SysV init.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 21:00 UTC (Tue) by drag (subscriber, #31333) [Link]
> There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.
Not really. All operating systems need to do a more-or-less the same job regardless of what you plan on doing with them. It doesn't really matter what you want to do with them.
On embedded systems or servers... what they want to accomplish and what they need is trivial compared to what it takes to support desktop and mobile devices properly. So if you are using something like SystemD or NetworkManager you end up with a overabundance of capabilities, which is almost never a bad thing. Once you learn to use them properly then you'll find that they are easier and better, even for embedded systems or sever systems. (and this is no joke)
Which ever Debian chooses to use (sysV, systemd, or upstart) the most important thing they need to do is make a decision. I am far less concerned about which they choose, just that they make a choice.
systemd & the tightly couple core band vs a world of many inits Posted Apr 24, 2012 21:05 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> you end up with a overabundance of capabilities, which is almost never a bad thing.
This overabundance of capabilities brings a significant amount of additional complexity along with it, which is almost never a good thing.
Add to it the fact that a lot of these tools try _really_ hard to do what a desktop user would want them to do, and it can frequently be hard to get them to _not_ do that and instead do what you need them to do.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 15:35 UTC (Wed) by drag (subscriber, #31333) [Link]
> This overabundance of capabilities brings a significant amount of additional complexity along with it, which is almost never a good thing.
But it is necessary complexity in many regards.
Either you have it done in systemd or you find some other mechanism to do it.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 2:59 UTC (Thu) by salimma (subscriber, #34460) [Link]
>> There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this "core distro" can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the "universal" distros.
> Not really. All operating systems need to do a more-or-less the same job regardless of what you plan on doing with them. It doesn't really matter what you want to do with them.
I think Martin meant something else by "universal" -- he meant that Debian, unlike say Fedora and Ubuntu, support multiple different ways of providing the same feature, even in the base OS -- different kernels (Linux, FreeBSD, GNU Hurd), different init systems, etc., and thus life gets harder for them when people push for tighter integration.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 10:07 UTC (Thu) by cas (subscriber, #52554) [Link]
That's the first time i've ever seen NetworkManager accused of having an overabundance of capabilities.
I guess there must be leakage from some parallel universe where NM isn't a pile of worthless crap that makes it impossible to have anything but the most basic network configuration.
NM is OK (as in tolerable) on laptops and desktop machines where all you want is a dhcp assigned IP and a simple GUI to configure access to your wireless AP.
For anything else, it's a complete PITA that actively prevents you from getting your network working.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 10:31 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Hi, this is the second message I see from you. If you want to be taken seriously, suggest to not use phrasings like "pile of worthless crap". Thanks.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 10:49 UTC (Thu) by cas (subscriber, #52554) [Link]
I can think of no compelling reason for me to care in the slightest whether you take me seriously or not. Feel free to try to convince me that your opinion should be worth something to me. It won't be easy.
As for Network Manager, given that it is a steaming pile of worthless crap, I have no hesitation in describing it as such.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 11:58 UTC (Thu) by ean5533 (subscriber, #69480) [Link] It's not just bkor's opinion you should care about -- it's the entire LWN community that will take you less seriously. Perhaps you don't care about anyone's opinion, but if that's the case, then why are you here?
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 22:18 UTC (Thu) by ovitters (subscriber, #27950) [Link]
You're turning things around. I already stated that the way you communicate is not very nice. As such, why are you asking me to convince you? I fail to see the logic in this. Of course it's your choice to continue communicating in the same way (eventhough I'd appreciate some more strict moderation on LWN).
Some "communities" (as far as LWN is a community) are different; on e.g. GNOME you can disagree/agree as much as you want, but it is not a free for all.
Suggest saying the same as you do here in real life / conferences such as GUADEC/FOSDEM. You'll see that some communication methods just don't get you much further.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 2:36 UTC (Fri) by cas (subscriber, #52554) [Link]
1. lecturing people because they don't live up to or believe in YOUR PERSONAL IDIOSYNCRATIC PREFERENCES is offensive and annoying.
If you don't like me saying that "software package X is crap, and here are some of the reasons why" then DON'T READ ANYTHING I POST, but don't insist that I conform to YOUR standards as if they are some universal objective standard of correct behaviour.
2. it is you who are turning things around. you said words to the effect of "be nice as i define it or i won't listen to you" - this is a repulsively passive-aggressive form of attempted censorship. I said "why should i care if you listen to me or not?". you still haven't provided any reason why i should care and seem to be going out of your way to provide reasons why i shouldn't.
3. Don't bother me again with this tedious garbage. i'm not interested.
some days i really wish forums like this had a killfile.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 2:43 UTC (Fri) by sfeam (subscriber, #2841) [Link] "some days i really wish forums like this had a killfile."It does. You're now in it.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 19:08 UTC (Thu) by jimparis (subscriber, #38647) [Link]
> I guess there must be leakage from some parallel universe where NM isn't a pile of worthless crap that makes it impossible to have anything but the most basic network configuration.
I suspect you're basing that on old versions of NM. When it started, it was how you describe, capable of only very basic network configuration. But many more features have been added since then. For example, I've recently used it on a remote data-capture system to:
I also occasionally plug my cell phone into my laptop, let NM connect to the Internet through it, and then tell NM to run a DHCP server on my wired connection and share the connection there.
Those cases might not be useful for you, but I think it's still far improved from "very basic network configuration". In general, I've found that if NM _does_ support a particular configuration, it goes one
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 19:15 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> I've found that if NM _does_ support a particular configuration, it goes one step further and makes that configuration _easy_.
I think this sums up the issue almost completely.
_IF_ it supports the configuration, it makes it easy for a desktop user to use it.
but if it doesn't support that configuration, or if you aren't a desktop user (i.e. server, embedded), then it is a problem.
systemd & the tightly couple core band vs a world of many inits Posted Apr 26, 2012 20:05 UTC (Thu) by jimparis (subscriber, #38647) [Link]
>_IF_ it supports the configuration, it makes it easy for a desktop user to use it.
> but if it doesn't support that configuration, or if you aren't a desktop user (i.e. server, embedded), then it is a problem.
I agree that you're basically out of luck if it doesn't support your configuration. But those situations are getting more and more rare in my experience.
Regarding "embedded", I disagree. The main example I gave was essentially an embedded system -- a laptop hooked up to data-capture equipment shoved in an inaccessible machine room somewhere. And in that case, I purposely installed and used network-manager because it supported what I needed (multiple interfaces, 3G modem, OpenVPN). Tweaking pppd and its config for just the 3G would have been quite a pain in comparison.
For "server", I'd still tend to agree -- having multiple bridged and bonded network interfaces in separate zones is, AFAIK, still not something NM would be helpful for.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 2:42 UTC (Fri) by cas (subscriber, #52554) [Link]
this is *exactly* the problem with NM.
You can do what is pre-programmed into it very easily. the catch is that you can *ONLY* do what is pre-programmed into it, and you can not use a combination of NM for the simple stuff plus your own hand-crafted config for the more complex / non-preprogrammed stuff.
If you could convince NM to leave your hand-crafted stuff alone and not break your network configuration because it doesn't understand it, then it would merely be a somewhat useful but quite limited tool. But you can't do that. which makes it a pile of worthless crap.
(and, btw, the most recent version of NM i tested was whatever was in debian sid about a month ago. i used it for a few days until it interfered with stuff i needed to do to get kvm running on my new workstation)
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 12:36 UTC (Fri) by mpr22 (subscriber, #60784) [Link] you can not use a combination of NM for the simple stuff plus your own hand-crafted config for the more complex / non-preprogrammed stuff. A cursory examination of a nearby Ubuntu 10.04 system gives me the impression that NetworkManager can be configured to only touch the interfaces the administrator wants it to touch, which means that at least some cases satisfying your description are viable (obviously there are plenty that are not). I also note that the existence of network configurations which it is reasonable to desire and which NetworkManager cannot be coerced into understanding (or at least into not breaking) is clearly a bug in NetworkManager which should be reported through the appropriate channels.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 16:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> I also note that the existence of network configurations which it is reasonable to desire and which NetworkManager cannot be coerced into understanding (or at least into not breaking) is clearly a bug in NetworkManager which should be reported through the appropriate channels.
The problem is how you define "reasonable to desire"
there are an incredible number of situations where the right thing to do in a particular situation is not something that would be considered sane in most other situations. Listing all these special cases in a tool like NM would confuse users and cause them to select the wrong thing.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 16:14 UTC (Fri) by mpr22 (subscriber, #60784) [Link] NetworkManager, the daemon, is not nm-connection-editor, the GUI tool for manipulating the daemon's configuration.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 3:33 UTC (Fri) by shemminger (subscriber, #5739) [Link]
The good and the bad of NM. NM makes setting up VPN's etc on my laptop easy, but it interferes horribly when doing anything moderately serverish like setting up VLAN's, bridging, bonding, fiddling with devices. I.e all the things you hope a network developer tests. So yes for users it's great but for developers it is a nuisance.
I fear systemd will end up the same way. Kind of like the Apple IOS, when everything works its wonderful, but when you want to develop hardware support or run another OS, or have a hardware error, it just says "your not worthy" and spits in your face.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 22:06 UTC (Fri) by zlynx (subscriber, #2285) [Link]
Setting up the VPN is easy, but NM fails at something I used to have scripts doing: getting name service set properly.
I *used* to run a caching named with forwarding servers defined for the internal nameservers on remote networks. The scripts would set the reference to the server and reconfig named.
To do the same thing on NetworkManager I'd have to write a plugin. Considering the state of other NM plugins, the NM authors have zero concern for API compatibility and therefore I'd also have to rewrite the code every six months or so.
systemd & the tightly couple core band vs a world of many inits Posted Apr 27, 2012 22:14 UTC (Fri) by jimparis (subscriber, #38647) [Link]
A plugin might be overkill. Is putting your scripts in /etc/NetworkManager/dispatcher.d not sufficient? It seems that you would just have to check that the interface coming up is your VPN, and then do your named config magic as usual.
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 1:45 UTC (Sat) by jspaleta (subscriber, #50639) [Link]
by plugin do you mean a script networkmanager's dispatcher.d facilility that fires on network up/down?
i just want to be clear as to what you have attempted.
-jef
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 2:29 UTC (Sat) by jspaleta (subscriber, #50639) [Link]
replying to myself... somehow i punched the wrong comment to reply to and i was too late to be relevant anyways. Please ignore me.. just this once.
-jef
systemd & the tightly couple core band vs a world of many inits Posted Apr 28, 2012 21:02 UTC (Sat) by zlynx (subscriber, #2285) [Link]
I just looked around at the man pages and http://live.gnome.org/NetworkManager
Do you realize the dispatch stuff isn't documented anywhere?
Besides that, NM makes it quite difficult to use DHCP and still point the DNS at ::1.
Which seems to be why someone wrote the dns=plugin stuff that is in the NetworkManager configuration file.
systemd & the tightly couple core band vs a world of many inits Posted Apr 29, 2012 0:44 UTC (Sun) by jimparis (subscriber, #38647) [Link]
> Do you realize the dispatch stuff isn't documented anywhere?
On my system, it's the majority of the "Description" section in "man networkmanager". See http://linux.die.net/man/8/networkmanager
> Besides that, NM makes it quite difficult to use DHCP and still point the DNS at ::1.
Under your IPv4 or IPv6 settings tab, just set the "method" to "Automatic (DHCP) addresses only" or "Automatic, addresses only". Then fill in the DNS servers yourself.
systemd & the tightly couple core band vs a world of many inits Posted May 1, 2012 6:50 UTC (Tue) by zlynx (subscriber, #2285) [Link]
Hmm. Sure enough, it is there in the Description section. I never saw it. I probably skipped Description in order to get to the good stuff. It seems to me that most man pages put a description in Description and then the actually useful information in other sections.
Or it is possible that I was logged into a CentOS 5 system when I ran the man command. NetworkManager 0.7 (the RHEL 5 version) has a dispatcher.d directory, but nothing in the man page about it. And this time I double-checked.
systemd & the tightly couple core band vs a world of many inits Posted Apr 25, 2012 22:47 UTC (Wed) by ballombe (subscriber, #9523) [Link]
The problem of the "core distro" model is that whoever control the development of the core distro can dictate how your distribution will run (for example which kernel you can use). Of course you can patch over or fork the core distro, but that defeats the purpose.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 15:10 UTC (Tue) by juliank (subscriber, #45896) [Link]
Why does everyone only talk about upstart and systemd? Clearly, there are many more ways to boot a system. Both Slackware and Gentoo also have their own init systems, what will happen to them?
Shuttleworth: Quality has a new name Posted Apr 24, 2012 17:57 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
ISTR some rumblings about Gentoo using systemd (there is a wiki section[1]). I'd be shocked if Slackware was seriously considering it[2].
[1]http://en.gentoo-wiki.com/wiki/Systemd#Removing_OpenRC
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:48 UTC (Tue) by chithanh (guest, #52801) [Link]
The official Gentoo init system is OpenRC.
But as Gentoo is about choice, of course you can run init-ng, launchd, or systemd instead. You can use udev, Busybox mdev or BSD devd. (Within limitations, of course.)
Shuttleworth: Quality has a new name Posted Apr 25, 2012 14:57 UTC (Wed) by Pawlerson (guest, #74136) [Link] Both Slackware and Gentoo also have their own init systems, what will happen to them?I hope they'll die soon. SysV init is so slow and its scripts are so terrible that's not even funny. Gentoo and Arch can migrate to systemd at any time, because they are prepared for such move. I'm quite disappointed Ubuntu is sticking to Upstart, because I found systemd to be more comfortable.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 15:34 UTC (Tue) by dowdle (subscriber, #659) [Link]
This isn't about Canonical vs Red Hat. It's about two guys disagreeing about their babies. Let others make the technical arguments... both (Mark and Lennart) are too close to be objective.
This sort of thing happens in the mainline kernel all the time (or so I've read in LWN's weekly kernel page over the years)... and sometimes there are clear winners and losers... and other times there remain multiple implementations. I'm not sure how it is going to turn out in the long run but I'm sure it is going to be ok.
Who laughed when Mark mentioned clarity and focus? I don't mean to slight Canonical nor the hard work the Ubuntu community puts into it... but they do have so many projects going all at once (while still being a fairly small operation) that most people assess it as the "throwing things against a wall and seeing what sticks" strategy. Perhaps that's the path to helping them figure out what to concentrate on but it did make me laugh.
The next big disruption on the horizon appears to be the migration from X11 to Wayland. Who is looking forward to that? I know I'm not... but I'm sure it'll feel better once the dust has settled.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 12:20 UTC (Wed) by jond (subscriber, #37669) [Link]
To be honest I'd welcome the disruption of a Wayland change, but I suspect we'll get a compromise: (perhaps milder) disruption, but a big, slow X compatibility layer, a plethora of toolkits ported to Wayland (GTK and QT), still encoding design decisions that made sense on X and perhaps don't otherwise and a lot of broken apps despite these efforts.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:18 UTC (Tue) by dbenamy (subscriber, #39458) [Link]
I haven't seen anyone who thinks this was a poor decision on Canonical's part address a valid advantage Shuttleworth gave for Upstart: comprehensive tests. What's the deal?
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
What use are the tests if the software you're testing is obsolete?
The 'we have a lot of tests' argument would have been good if systemd were a new project without any users. But right now systemd is used in pretty much all other major distributions (that had time for at least one release cycle after the systemd introduction).
Let's see: OpenSUSE uses it, Fedors uses it, Gentoo supports it, Debian supports it, RHEL will probably support it in the next release.
So the decision to use Upstart is purely political, not technical.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:29 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
to be fair, don't Gentoo and Debian also support upstart?
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, yes. Debian supports even KitchenSi^W^W GNU Hurd.
Gentoo doesn't really support upstart - it can be used in SysV compatibility mode, but it's not being actively advanced.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 18:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
is ANYONE using upstart native jobs to a large extent? Is Ubuntu? Or is Ubuntu still basically relying on sysV compatibility mode? Upstart introduced the concept of an event driven model....who is actively using that model to do anything interesting beyond implement runlevel equivalents.
Seriously I have no idea what the state of the art is. Is Ubuntu using upstart native job definitions for services like sshd or apache right now?
-jef
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:56 UTC (Tue) by drag (subscriber, #31333) [Link]
Well Fedora jumped whole hog into using systemd.
Pretty much all the default services have been moved over to using it natively and a significant portion of packaged services have also. It has made a significant impact on the character of the OS.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:04 UTC (Tue) by tpo (subscriber, #25713) [Link] $ ls /etc/init|wc -l 59 $ lsb_release -r Release: 10.04 $ ls /etc/init|grep apache $ ls /etc/init|grep ssh ssh.conf $
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:04 UTC (Tue) by misc (subscriber, #73730) [Link]
It doesn't seems so for apache
http://packages.ubuntu.com/precise/amd64/apache2.2-common...
but there is for ssh :
Upstart jobs are stored in /etc/init/. There is lots of them on a lucid lynx system :
But that's mostly replacement for the old /etc/rcS.d/ system.
In fact, the real issues is not "using upstart vs using systemd".
Switching to systemd is not just a upgrade when coming from upstart, since you cannot just replace upstart jobs by systemd jobs. So I can see why the Ubuntu team thought it would not be worth. They seems to have suffered from switching ( http://undacuvabrutha.wordpress.com/2011/04/29/why-ubuntu... ). So I can see why they prefer to focus their resources to more differentiating features than a init system.
I do not think this will be a huge burden on Canonical since Google also use it and they have enough people to take care of that.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 21:33 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Switching to systemd is not just a upgrade when coming from upstart, since you cannot just replace upstart jobs by systemd jobs.
systemd units for most interesting services have already been written, and writing them isn't even difficult. So I doubt that this would be a major problem.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:42 UTC (Tue) by rahvin (subscriber, #16953) [Link]
This is the price Canonical pays for being the first to the party. They were the first (distro) to jump head first into upstart, now that the rest of the community is reworking upstart into systemd they are given the option to either convert and spend the resources twice or to hang on and handle the old code problem. That's the risk of being an early adopter. They're choosing the wrong option in my opinion, I agree with Pottering that they are going to be stuck maintaining a bunch of code like udev that they've never planned or budgeted for and will likely result in total stagnation for them.
If they are counting on Google pulling the weight they are making a mistake (unless they have intimate knowledge of Google's plans that is). Because IMO trusting Google to do anything is asking for trouble. They've got to be the most bi-polar company in existence. The only part of their business that's consistently the same is the advertising arm (and we don't see the internal on that so it could be equally troublesome as the rest). Personally I'm not sure how I would bet on a wager of Google throwing out all previous work and starting over in some radically different direction.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 0:16 UTC (Thu) by mrons (subscriber, #1751) [Link]
> is ANYONE using upstart native jobs to a large extent?
What about RedHat 6?
In a strange twist, Redhat will need to support upstart for several years now.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 0:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
Yep, if RHEL 6 uses upstart, RedHat will be supporting upstart for 7-10 years (possibly more). I didn't realize this.
this may impact the 'obvious' move to systemd in RHEL7, it depends on how disruptive this is to sysadmins and if RedHat is willing to change init packages twice in two releases.
I think that people assume that if something is in Fedora, it will be in the next RHEL. Even if Fedora is the testing ground for RHEL (something disputed by Fedora people regularly), there's still time for the test to fail (for some definition of fail)
Shuttleworth: Quality has a new name Posted Apr 26, 2012 1:11 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Im pretty sure RHEL is not making use of "native" jobs by default for much of the init scripts beyond early boot just as Fedora did.
Upstart was introduced in Fedora (just as it was in Ubuntu) running in a sysVinit compatibility mode...which created upstart native jobs that mimicked traditional runlevels to run everything else.
In Fedora i'm pretty sure none of the installable services...such as sshd ever had upstart "native" job files and were run as traditional initscripts under the compatibility mode. I expect RHEL 6 to be using upstart in the same way. Which is to say...as close to a replacement of sysvinit and no further than that.
And since I asked the question originally I've looked over the open upstart bugs that have bubbled up in the context of other discussions and it seems upstart has some long standing issues that prevent conversion of a number of significant services like apache and other forking services.
Bug from 2010:
This is pretty much a showstopper for "native" upstart process control across an important swath of daemon (especially for the cloud..cough cough.) I am NOT saying this is unfixable. The original lead developer clearly thought it was fixable...in 2010..by moving away from ptrace in how upstart did its magic. But its NOT FIXED going on a year and a half later to my understanding.
This really brings home the point I think that Canonical has a problem keeping up with their own project development long term. Canonical's choice to keep upstart would make more sense if they were actively cultivating upstart so it could be a full init replacement so all services could gain access to the enhanced event based job control. But they aren't. They made a push to "go native" for as much as was feasible..but they haven't fixed upstart to be able to take it further and complete the work. That's a problem. The longevity of that bug speaks to focus and to quality more than perhaps a lot of people inside the Canonical fenceline realize.
An init replacement system that can't be used to transition from the legacy sysvinit scripts to get access to advanced job flow control features sort of defeats the point a little bit. Especially for a company that is really pushing the server motto. But hey if they want to stick their heels in the sand they are only hurting their own long term prospects. It's always a bit sad to watch it happen. Hopefully they'll double down and put some more engineering manpower into getting upstart polished off instead of letting it linger a slow death.
-jef
Shuttleworth: Quality has a new name Posted Apr 26, 2012 11:16 UTC (Thu) by ovitters (subscriber, #27950) [Link]
I'm wondering if they could switch between RHEL 6.x versions. Though I guess that might be a bit too invasive (systemd relying on new kernel versions, udev, etc).
Shuttleworth: Quality has a new name Posted Apr 28, 2012 23:23 UTC (Sat) by speedster1 (subscriber, #8143) [Link]
I think swapping init systems in a minor version bump would be very inappropriate for RHEL. Too much system config churn for their very conservative customer base, without a compelling excuse for making such an exception in their normal upgrade strategy.
Shuttleworth: Quality has a new name Posted Apr 28, 2012 23:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
They don't even update kernels between releases. So little chance of that.
Though RHEL7 should be fairly soon - in 2014 or so :)
Shuttleworth: Quality has a new name Posted May 1, 2012 17:05 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] They don't even update kernels between releases. Yes they do. And it's not just updating drivers; they've backported quite large new features, like KVM into RHEL 5.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 1:57 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>Well, yes. Debian supports even KitchenSi^W^W GNU Hurd.
Any takers for (Solaris's) SMF? :)
Shuttleworth: Quality has a new name Posted Apr 25, 2012 12:21 UTC (Wed) by jond (subscriber, #37669) [Link]
Hurd is not (yet) a supported kernel for Debian.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 19:38 UTC (Thu) by cdmiller (subscriber, #2813) [Link]
And jumping off the bridge cause everyone else is doing it, is a logical fallacy.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
As is staying in a sinking ship just because you think that all other passengers are idiots.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 14:28 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
It is a potentially valid advantage if that claim is accurate
https://plus.google.com/115547683951727699051/posts/JCDko...
Shuttleworth: Quality has a new name Posted Apr 27, 2012 16:23 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
And there this is this gem:
https://bugs.launchpad.net/upstart/+bug/703800
Whatever test coverage they have... its not clear its helping them fix issues. They may know about them... know about them for years...and they aren't getting fixed.
There's a lot of complexity in the native job stuff... and I'm really not sure it has testing coverage either pre-deployment or real world to shake it all loose. There are several outstanding issues with going completely native that Ubuntu hasn't figured out that would point to a need for some deep tissue massage therapy in upstart itself. Just sort the upstart bugs by heat and go from hottest to coldest.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:13 UTC (Tue) by slashdot (guest, #22014) [Link]
How about the huge downsides of fragmentation?
How about the fact that cgroups and socket activation make systemd strictly better than anything else?
Shuttleworth is being a total idiot in this case.
I wonder whether he is really fit to lead a distribution, or whether he simply bought his leadership position and has been given way more respect and consideration than he deserves.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:17 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
in case you haven't noticed, there are a lot of people who aren't thrilled with systemd.
Disagreeing with LP does not make you an idiot.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:25 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Yeah, and at least 95% of those are simply badly informed or clueless.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:29 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
so please let us 'clueless' people have a distro that does things the way we want, instead of trying to force us to do things your way.
why do you have to be so hostile to different opinions?
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:34 UTC (Tue) by aleXXX (subscriber, #2742) [Link]
He did not "buy" his leadership position.
He created with his own money the whole organization.
Alex
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:50 UTC (Tue) by donbarry (guest, #10485) [Link]
For some value of "whole organization."
But as the great majority of Ubuntu is simply rebranded Debian, his investment was far, far less than it would take to actually build from scratch. Therefore, it is fair to call the invention of Ubuntu as a Debian fork the buying of a vanity distribution. The "self-appointed" business could hardly be clearer, could it?
I'd only agree with your phraseology when the bulk of the code for his product originated from Canonical. The chance of that happening is infinitesimal.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:06 UTC (Wed) by jond (subscriber, #37669) [Link]
Speaking as a Debian Developer, I don't think this is fair at all.
Yes, Ubuntu harnessed Debian and saved themselves a lot of grunt work by doing so. But do not underestimate their contribution to improving the readiness of Linux and free software for the mainstream desktop, nor the popularisation of Linux amongst the masses.
Debian has, in turn, benefited hugely from the work that Ubuntu has done.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:19 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
There is no evidence whatsoever that mass appeal has been achieved by Ubuntu. There is evidence that Ubuntu has successfully solidified interest in the linux enthusiast community that would have otherwise gone to other distributions. An achievement for sure, but let's be very clear about the scope of that achievement.
I can find no evidence anywhere I can find that the overall adoption rate of linux globally (prior to Android) was accelerated by the introduction of Ubuntu.
Sadly the wikimedia OS useragent stats don't go back more than a couple of years so they don't tell a story long enough to really speak to the long term trend. But what I do see in the wikimedia stats is effectively...stagnation of linux (other than Android). The trend is cycle with a 12 or 13 month cycle but once you account for that cyclic nature the longer term trend is...flat. This is the most credible publicly available dataset that I know exists. If there is another public dataset of merit, I'm more than happy to look at it.
The _only_ _linux_ software vendor to reach and sustain a quantifiable mass market appeal has been Google with Android. Wikimedia stats show this clearly in the same way that it shows traditional linux distribution market penetration stagnation.
-jef
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:32 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
The problem is with figuring out the stats for each disto and for linux overall
a lot of the people who are using Ubuntu instead of windows are not going to techie sites (including wikipedia), they are non-techie people just using the system for their day-to-day needs.
you also have to think back to what the linux landscape looked like when Ubuntu was introduced, there was a distinct gap in the desktop niche at the time.
Ubuntu didn't do anything that other distros couldn't have done, and it couldn't have done what it did without the entire ecosystem, but it was a major wake-up call in terms of making Linux "just work" out of the box without having to answer lots of technical questions first.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:48 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
There was no gap. That is revisionist. Linspire was being sold at Walmart. That's not a gap...that's progress. And prior to that HP sold a laptop with Suse pre-installed.
But please, point me to any quantifiable evidence that Ubuntu change the rate of adoption for linux. You can believe what you want. I'm not going to argue over matters of faith. But don't state it as fact unless there is evidence you can point me at.
-jef
Shuttleworth: Quality has a new name Posted Apr 26, 2012 1:47 UTC (Thu) by nevets (subscriber, #11875) [Link]
I can't give you any hard evidence, but there's a lot of people I personally know that used Linux for the first time, and it was with Ubuntu. Note, this was all before Unity came along.
I have to admit, that it did seem that Ubuntu made the entrance into Linux easier. I'm not so sure that is true today.
I personally never liked Ubuntu. I started with Slackware (in the days of the 13 floppies), moved to Red Hat Linux (before Fedora) and have switched and stayed on Debian. I'm a grumpy old developer that enjoys hacking on SysV init scripts and running 2.6.9 kernels as well as 3.4-rc4 (compat sys is a PITA). I've switched to xfce to get away from the Gnome3 nightmare, and avoid systemd, upstart, and grub2.
Yes, I may be stubborn, and hate drastic changes, but it took me 15 years to come up with a workflow that suits me well, and I'll be damn if I'm going to throw it all away overnight.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 19:51 UTC (Tue) by Zack (guest, #37335) [Link]
"How about the huge downsides of fragmentation?"
That's a bit rich, since one of the perceived problems with Lennart's software is that it is very linux centric.
I'm glad to see the GNU/Linux operating system is being one of the more successful in the "fringe os pool", but I don't feel that's a good enough excuse to willfully start introducing incompatibilities with other unix and unix-like operating systems and kernels.
Charging too far ahead of "the pack" might not be the best long term option.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:02 UTC (Tue) by drag (subscriber, #31333) [Link]
If Linux is trying to do things that nobody else can do then it's not a terrible thing to have something Linux-centric.
Why should Linux have to wait for NetBSD, AIX, and Solaris to implement currently Linux-only features before Linux can use them?
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you can go ahead and do incompatible things, but if you then try and claim that people who don't jump on board with your incompatible things are fragmenting linux, you deserve to be laughed at.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:08 UTC (Tue) by drag (subscriber, #31333) [Link]
Well I can't read Lennart's response right now because the work firewall is incomparable with google plus, but I'll just assume that Lennart is accusing Ubuntu of fragmentation and that is what you are referring to.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 5:11 UTC (Wed) by misc (subscriber, #73730) [Link]
The meat of the argument is not the fragmentation per se, more that not using systemd is gonna be costly for them in the long run.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:53 UTC (Tue) by Zack (guest, #37335) [Link]
>If Linux is trying to do things that nobody else can do then it's not a >terrible thing to have something Linux-centric.
>Why should Linux have to wait for NetBSD, AIX, and Solaris to implement >currently Linux-only features before Linux can use them?
Well, of course linux development shouldn't have to halt or restrain itself from charging ahead. But it is, imo, considered good form to write your software for the unix-platform as broadly as possible. Taking advantages of certain kernel features if they are available, but providing fallbacks for the rest of them (at least until they catch up).
Pushing for a subsystem to become the new standard on GNU/Linux even though it is unusable on any other unix system causes fragmentation. And I can see how, for example, a redhat might not have any problems with that (and why should they?), but some of us have different motives, and feel compelled to speak up against the "We're the most popular, why should we care about the others?" mentality. The short term gain might not be worth the long term drawbacks.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 0:46 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Please read on this weeks LWN.net's feature page the article »The return of the Unix wars?« and notice that it doesn't cover the big elephant in the room, concerning fragmentation: Not fragmentation within Linux, but fragmentation within the Open Source Un*x variants. Yes, the Unix wars are back and LP is their war lord. LP's work strives to go ahead in a bold fashion and he thinks we are sufficiently strong to ignore other Unix systems, that we may go bold forward to our own island of functionality.
Well, how's your Linux market share today? Do you think it's sufficient to be so self confident, or do you think you should play nice with the other folks from your family? Some of us seems to think that we can eventually shun our stinking brethren *BSD users (and other Unix users), and that we'll be doing good for it. Will that be the case?
And this comes from the community that hails Linus for his insistence on backward compatibility on kernel ABIs. If it comes to user land, they ignore his insights.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 6:58 UTC (Fri) by anselm (subscriber, #2796) [Link] And this comes from the community that hails Linus for his insistence on backward compatibility on kernel ABIs. If it comes to user land, they ignore his insights. System V init doesn't really have much of an ABI to be compatible with. AFAICT systemd does make an effort to support SysV init's init scripts, which from a practical point of view probably makes most sense because it allows third-party system services to be run under systemd even if they don't come with a systemd unit definition file. Or do you mean we shouldn't use something like systemd on Linux because BSD and Solaris don't support advanced Linux features that systemd exploits, such as cgroups, and because there is no systemd (or workalike) for these systems? IMHO that would be silly. It's not as if those platforms are bending over backwards to ensure all their newfangled features don't break compatibility to Linux.
Shuttleworth: Quality has a new name Posted Apr 30, 2012 1:15 UTC (Mon) by jschrod (subscriber, #1646) [Link]
> System V init doesn't really have much of an ABI to be compatible with.
Ahem. Please read http://lwn.net/Articles/490177/, by an author named, well, anselm. Perhaps he'll understand what's about; I can fully subscribe to his views expressed in that post. :-)
In fact, the System V init ABI is simple: If /etc/init.d/start/$service {start,stop,status,restart,reloac} worked with init.d, it should work with systemd as well.
Since the systemd proponents dismiss init.d scripts as ineffective and not-working, and strive for substitution by systemd definition files in all cases, I won't accept the existance of »deprecated« init.d scripts as »systemd supports it«. Discussions on mailing lists of Fedora, opensuse-factory, et.al. clearly shows that this is not what is supposed to be »real systemd support«.
But then I notice that there are intrinsic assumptions of systemd that are not always fulfilled. E.g., on opensuse-factory I followed quite some flamewars where developers asked how previous features should be realized now. The most prominent examples were (a) how to shut down all running virtual machines when no watchdog process is there (systemd ties a service to a running process it can supervize), and (b) how to state the status of a system like AppArmor when there's no daemon to ask for the status. HylaFax service description wasn't convertible either; I don't remember the reason any more, though. All the time, the answer the developers got was: Thou Shall Not Want To Do That. I.e., the answer they got was: That's not a service as defined by systemd and thus it's not a valid request. We Define What's Right And You Are Wrong(tm).
As another example from the openSUSE community: When systemd was introduced in 12.1, they broke packages like Postfix. Well, shit happens when you introduce new things, no biggie -- one should think. But: systemd introduced the breakage and what was the reaction of those who caused the problem? It was: it's Postfix's problem, it should adapt to the New And Only Way; it's not systemd's fault and Postfix should fix it. Sit back and contrast this to the Linux kernel way: If somebody introduces a change in a fundamental service, it's his or her responsibility to fix all problems that's caused by the change; he can't tell the others »that's the New Way(tm), You Have To Do The Work to change«. Such patches would be flamed to hell by Linus, and rightly so. And that's the behaviour I would like to see in user land, too.
We're thoroughly missing a Linus for Linux plumber's land. Last year, it was all ConsoleKit etc, that was en vogue. Now it's obsolete, decided by the very same developer that introduced camel case *Kit daemones to Unix. Witness the change of udev's role and HAL's demise over the last few years -- this ain't a stable environment any more to develop for. Oh yes -- will standalone udev still exist next year, or will it be abandoned? The developers actions, blog posts, and comments on their blogs don't necessarily inspire trust.
And btw,
> do you mean we shouldn't use something like systemd on Linux because BSD
I don't think we should not use cgroups. But if patches come along to make cgroups optional, upstream should go forward and accept them. Instead they ridicule non-Linux developers -- or even Linux developers, as shown by Lennart's last blog post about Ubuntu. systemd upstream is as bad as OpenSSH upstream -- and that's something to write, I wouldn't have thought I would compare someone to Theo de Raadt without meaning an insult. (I don't know if you ever met Theo in person. It's not a nice affair.)
For me, the most sad point is: I actually agree with Kay and Lennart et.al. that SysV init is not done well and should be replaced. The architecture of systemd is sound and much better. init.d dependencies is one of the first things one has to patch in most installations. systemd unit descriptions are really better and can be adapted more easily. But: The developer's attitude does not inspire trust. That's like running software from Dan Bernstein, which I would never do in a professional environment. And trust is all that's about, isn't it? (I'm referring to Dennis' Turing Award article, in case that ain't clear.)
I hope this clarifies some of my thoughts.
Joachim
PS: Are you Anselm from Darmstadt? If yes, I met with Metin last week. Cheerio. :-)
Shuttleworth: Quality has a new name Posted Apr 30, 2012 15:53 UTC (Mon) by anselm (subscriber, #2796) [Link] For me, the most sad point is: I actually agree with Kay and Lennart et.al. that SysV init is not done well and should be replaced. The architecture of systemd is sound and much better. I think we're all on the same side here … But: The developer's attitude does not inspire trust. That's like running software from Dan Bernstein, which I would never do in a professional environment. And trust is all that's about, isn't it? True. It would certainly be good if Lennart Poettering was less like Dan Bernstein and more like Wietse Venema ;^) PS: Are you Anselm from Darmstadt? Yep, that's me ;^)
Shuttleworth: Quality has a new name Posted May 2, 2012 14:08 UTC (Wed) by dgm (subscriber, #49227) [Link] And trust is all that's about, isn't it? (I'm referring to Dennis' Turing Award article, in case that ain't clear.)I think you mean Ken Thomson's article.
Shuttleworth: Quality has a new name Posted May 2, 2012 15:09 UTC (Wed) by jschrod (subscriber, #1646) [Link]
You are right, of course.
Dennis' and Ken's work have been so intertwined for me, that this lapsus may happen... ;-) They got the award together in 1983, and I always considered that article the real Turing lecture for Unix, not the other one about Bell Labs' research politics. Even ACM lists that article on Dennis' short annotated bibliography: http://amturing.acm.org/bib/ritchie_1506389.cfm
(I had the pleasure to have a dinner with them, many years ago. It was a great evening that I still remember well.)
Shuttleworth: Quality has a new name Posted Apr 24, 2012 20:51 UTC (Tue) by ovitters (subscriber, #27950) [Link]
I don't see how Linux centric is a problem for systemd. Note that his other software is not Linux specific AFAIK. In general, I don't see Linux centric as being seen as a problem.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 15:55 UTC (Thu) by dan_a (subscriber, #5325) [Link]
It's not a problem per-se, but it is incompatible with complaining about fragmentation IF the product being complained about works across a number of operating systems. (In my opinion, of course.)
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:23 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Shuttleworth is being a total idiot in this case.
s/in this case//
I honestly can't think of anything sensible Shuttleworth has ever done for OSS.
This guy needs a serious beating with a cluebat. He isn't just completely and utterly worthless for the OSS community, he's downright harmful.
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:41 UTC (Tue) by Zack (guest, #37335) [Link]
>I honestly can't think of anything sensible Shuttleworth has ever done for OSS.
Ship-it!
In spite of all of Canonical's flaws, and their touchy-go-y behaviour with proprietary software, ship-it! was a major success and really made inroads for distributing Free Software.
I don't know if they still provide that service, but at that time it was a wonderful (if costly) initiative that raised the tide for all distributions.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 0:09 UTC (Wed) by chithanh (guest, #52801) [Link]
Though I dislike many aspects of Ubuntu and would not install it on my computer, I don't let myself be blinded by that.
Ubuntu understands very well what it takes to make a Linux distribution palatable for the general public. He has brought Free/Open Source Software to more people than all other distros combined. Stats were published by Phoronix/OpenBenchmarking this week.
Concerning your remark about encouraging the use of proprietary software:
That Mr. Shuttleworth commends Mac OS X just showing that he gives credit where credit is due. Though I agree with other commenters that aiming for OS X is aiming way to low.
Unfree soiftware in Linux distributions? Posted Apr 25, 2012 1:37 UTC (Wed) by vonbrand (subscriber, #4458) [Link] At least, Fedora has a strict policy what can (and can't) be shipped as part of Fedora. It just isn't true that it offers a "mix of free and propietary software by default," much less "no questions asked."
Unfree soiftware in Linux distributions? Posted Apr 25, 2012 10:27 UTC (Wed) by chithanh (guest, #52801) [Link]
Fedora contains sourceless and restrictively licensed firmware in a default installation. This is despite their "If it is proprietary, it cannot be included in Fedora." claim (from your link, even).
Unfree soiftware in Linux distributions? Posted Apr 25, 2012 16:32 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Firmware is really the only real exception to this rule and it is well documented in the packaging guidelines. I have now added a reference to the above page.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 2:16 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>- He deliberately keeps[...] incompatible[...]
>- He works on completely useless stuff[...] >- He supports crap[...] >- He develops and encourages the use of proprietary software
That is quite reminiscient of the “90s vintage villain” Microsoft Corp.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 9:39 UTC (Thu) by daniels (subscriber, #16193) [Link]
Yeah, complete with comprehensive reality denial, and refusal to acknowledge that he could ever have done anything good. I'm surprised they aren't calling Mark Shuttleworth 'M$' at this stage.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 15:59 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
When I see the first person use that moniker, would you like me to badger them to cite you for introducing it into the meme pool? Credit were credit is due... I think you just accidentally started a new meme.
-jef
Shuttleworth: Quality has a new name Posted Apr 26, 2012 16:06 UTC (Thu) by jengelh (subscriber, #33263) [Link]
I think I may have postulated it on LWN earlier already: Displacing Microsoft [as desired in LP bug#1] is only possible by becoming like Microsoft.
The SI voice says: Proposal to use ₥s as a distinctive symbol, since M$ is obviously already used.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 12:09 UTC (Fri) by branden (subscriber, #7029) [Link]
I ain't installing a new input method or learning a new Unicode code point just to type "₥s" (and you're fortunate I am not too lazy to cut-and-paste from your post).
Try again!
Shuttleworth: Quality has a new name Posted Apr 27, 2012 16:03 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
If you have a Compose key (I use Shift+RtAlt), just do <Compose></><m>. Most of the combined characters "make sense" in how to create them.
As a reference:
setxkbmap -option lv3:ralt_switch_multikey
Shuttleworth: Quality has a new name Posted Apr 25, 2012 7:35 UTC (Wed) by ovitters (subscriber, #27950) [Link] Shuttleworth has created an entire distribution, done things in a different way, great focus on user experience, got loads more people to use Linux, etc. He has different ideas on how to do things and the ability to execute it. It could either not work out (in which case there are enough resources to do things differently), or he's successful. He isn't just completely and utterly worthless for the OSS community, he's downright harmful. You're turning your disagreement in the way he does things in a personal attack. Not nice.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 7:43 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Shuttleworth has created an entire distribution,
No he didn't, he essentially ripped off debian's work.
> done things in a different way,
> great focus on user experience,
> You're turning your disagreement in the way he does things in a personal attack.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 8:15 UTC (Wed) by spaetz (subscriber, #32870) [Link]
Hello HelloWorld, I find many of your posts to be offensive and contain personal attacks. Could you state your criticism in less emotional tone, please?
>> Shuttleworth has created an entire distribution,
>> done things in a different way,
>> great focus on user experience,
To be honest, I think Ubuntu deserves some credit (as does RedHat/Fedora/Ubuntu) for reinvigorating the race to a "polished" desktop. I believe many Fedora/RedHat technologies have helped to achieve that. But by experimenting with overarching visions of how to get a polished desktop rather than niche thinking (eg the non-free driver jockey thingie which helps to determine which non-free drivers might be required to enable your wlan, has helped me many times when installing Linux on friends computer, where I had to give up with pure Debian).
>> You're turning your disagreement in the way he does things in a personal attack.
So because IBM also happily sells you proprietary solutions, you remove all IBM-contributed patches to the kernel before using it? I commend you for that. The Ubuntu one client and interface is Open Source, the backend is not. I presume you don't use Amazon, Google, Twitter, or LWN.net because they also develop evil closed source server side backends. Sorry, I prefer open web services to closed ones (that is why my cloud is a webdav server), but condeming Ubuntu as evil because they have a cloud service they like to push, sounds a bit overstretched to me.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 12:03 UTC (Wed) by pboddie (subscriber, #50784) [Link] To be honest, I think Ubuntu deserves some credit (as does RedHat/Fedora/Ubuntu) for reinvigorating the race to a "polished" desktop. True, but for many years, Ubuntu was merely providing GNOME and KDE with some customisation (not all of it positively received) in a more timely fashion than Debian. In other words, the underlying offerings were pretty good already, and Ubuntu was just a convenient packaging of them with enough infrastructure and brand identity to make that packaging persuasive. Now, however, the Ubuntu developers have moved into new territory, and although I can see the point of them doing that, I'm not convinced that they've shown enough stamina to deliver a complete experience living up to what they have been promising. So, digging beneath the surface of Unity's tablet-like shell paradigm, there are still the confused settings panels reminiscent in places of old-style Kubuntu and even Windows. All that cruft should be tidied up and the system made more reliable so that you don't really have to look at it unless you really have to. Sorry, I prefer open web services to closed ones (that is why my cloud is a webdav server), but condeming Ubuntu as evil because they have a cloud service they like to push, sounds a bit overstretched to me. Can you migrate from it? Can you substitute something else in its place? Those are the pertinent questions.
Shuttleworth: Quality has a new name Posted Apr 26, 2012 19:52 UTC (Thu) by JanC_ (guest, #34940) [Link]
> Can you migrate from it? Can you substitute something else
> in its place? Those are the pertinent questions.
I think the answer to that is somewhat complicated, as UbuntuOne has many parts...
Shuttleworth: Quality has a new name Posted Apr 25, 2012 14:53 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Hello HelloWorld, I find many of your posts to be offensive and contain personal attacks. Could you state your criticism in less emotional tone, please?
Dude, attacking Shuttleworth was the whole point of my posting, so of *course* it contains personal attacks.
> But by experimenting with overarching visions of how to get a polished desktop rather than niche thinking
> So because IBM also happily sells you proprietary solutions, you remove all IBM-contributed patches to the kernel before using it? I commend you for that. The Ubuntu one client and interface is Open Source, the backend is not. I presume you don't use Amazon, Google, Twitter, or LWN.net because they also develop evil closed source server side backends. Sorry, I prefer open web services to closed ones (that is why my cloud is a webdav server), but condeming Ubuntu as evil because they have a cloud service they like to push, sounds a bit overstretched to me.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:00 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> Dude, attacking Shuttleworth was the whole point of my posting, so of *course* it contains personal attacks.
Thanks for the confirmation. This grants you a spot in my "personal attacks" filter.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:12 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Oh, how convenient for you! Now you suddenly don't have to deal with my reasons for attacking him any longer!
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:49 UTC (Wed) by ean5533 (subscriber, #69480) [Link]
I'm going to make the naive assumption that you really don't understand what's going on. Spaetz isn't filtering you out so that he can ignore your comments and happily live in his own world (as you imply). He's filtering you out because you just confirmed that you think ad hominem reasoning is a valid way to argue. It is not.
You may have valid points, and you may have valid reasons to back them, but if people have to dig through your faulty arguments in order to find the good ones then it is hard to trust anything you say. At some point it becomes easier to just ignore you completely than to waste time trying to sort through the cruft. If you'd like to be taken more seriously, please take the time to make sure your arguments are all relevant and that you don't drift into personal attacks that contribute nothing to your point.
If you find yourself tempted to respond by calling me an idiot, please know that your response is already heading down the wrong path.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:02 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> I'm going to make the naive assumption that you really don't understand what's going on. Spaetz isn't filtering you out so that he can ignore your comments and happily live in his own world (as you imply). He's filtering you out because you just confirmed that you think ad hominem reasoning is a valid way to argue. It is not.
Oh yeah, right. So when someone speaks like a moron, behaves like a moron and at least appears to have the ideas of a moron, calling that person a moron is not a valid way to argue?
> You may have valid points, and you may have valid reasons to back them, but if people have to dig through your faulty arguments in order to find the good ones then it is hard to trust anything you say.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:07 UTC (Wed) by corbet (editor, #1) [Link] Calling people morons is not how we'd like people to argue on LWN, no. Save that for the schoolyard, please.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 18:04 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Calling people morons is not how we'd like people to argue on LWN,
Well, good thing I didn't do that then.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:13 UTC (Wed) by mpr22 (subscriber, #60784) [Link] calling that person a moron is not a valid way to argue? Precisely so. Instead, explain why the idea is stupid. Tread warily, though, lest you fall foul of the "arguing with idiots" effect.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:15 UTC (Wed) by ean5533 (subscriber, #69480) [Link]
Your original post listed several things that you believe Mark is doing wrong. Presumably the point of your argument is that Mark is detrimental to the Linux community, but you haven't explained why; you've only listed a bunch of things that you, personally, do not like. (Never mind that you provided no citations, and actually criticized someone who asked you for citations. Also never mind that you seem to believe every technical decision ever made by Canonical was made personally by Mark himself). Even if we ignore the flaws in your reasoning, and just accept your argument that Mark is detrimental to the Linux community, there is still zero justification for calling Mark an idiot, a moron, or someone who "needs a serious beating with a cluebat".
I am finished talking with you. Your negative attitude is caustic.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 18:24 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Your original post listed several things that you believe Mark is doing wrong. Presumably the point of your argument is that Mark is detrimental to the Linux community, but you haven't explained why;
Yes, precisely. I didn't explain it because it's obvious. For example there's a general agreement that improvements to software like the kernel, GTK+ or X.org should preferably be done upstream, and not in the distros. So why should I write down the reasons for that again when dozens of people have done that before me? And it's the same for all the other point's I've made.
> Never mind that you provided no citations, and actually criticized someone who asked you for citations.
> Also never mind that you seem to believe every technical decision ever made by Canonical was made personally by Mark himself.
So no, I don't see any serious flaws in my reasoning. And let me say it again: I'm not trying to write an academic paper here. I'm just giving *my personal opinion* about Shuttleworth, which is what comments are for.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 19:06 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> or example there's a general agreement that improvements to software like the kernel, GTK+ or X.org should preferably be done upstream, and not in the distros.
if you are going to start throwing rocks I'll point out that RedHat has probably the worst track record of any distro in terms of maintaining local patches to the kernel. They are far better than they were in the past (at one point the divergance was so large that there were major apps that would run only on the RedHat kernel), but they still maintain a fair number of them (as does almost every disto)
In fact, by this criteria, the least evil distro is Slackware (and even Slackware has a few local patches to the software it ships)
Your absolutist "Since they aren't perfect, they are evil" attitude is not productive. If you are trying to convince other people to agree with you, then insulting them doesn't help either, and if you aren't trying to convince people, what are you trying to do?
Shuttleworth: Quality has a new name Posted Apr 29, 2012 21:26 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
"if you are going to start throwing rocks I'll point out that RedHat has probably the worst track record of any distro in terms of maintaining local patches to the kernel"
That isn't the same thing. Red Hat usually does all kernel work upstream and backports it to maintain compatibility for the enterprise releases. For Fedora, there isn't any history of major local patches that weren't upstream quickly because of the shorter release cycle. When people complain about vendor X not doing work upstream it is usually because that vendor hasn't made any efforts to push it upstream.
Shuttleworth: Quality has a new name Posted Apr 29, 2012 22:12 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
Red Hat currently does much of it's kernel work upstream, but this has not always been the case. they have gotten much better in the last couple of years.
Shuttleworth: Quality has a new name Posted Apr 29, 2012 22:22 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Feel free to be more specific. I would argue that what has changed is the 2.6 kernel development process.
Shuttleworth: Quality has a new name Posted Apr 29, 2012 23:37 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
the 2.6 development process was changed to encourage Red Hat (and the other distributions) to cooperate more and work more upstream, and I think it's been a wonderful success in doing so.
I just see people giving Red Hat a free pass on anything that it does (or has ever done) while condemning Canonical and Ubuntu for doing similar things (and in my eyes, doing them to a less damaging degree)
Shuttleworth: Quality has a new name Posted Apr 29, 2012 23:50 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
"the 2.6 development process was changed to encourage Red Hat"
Citations needed. https://lwn.net/Articles/94386/ shows Alan Cox pushing for a six month release process and Andrew Morton suggesting the current process. Also I note, you didn't provide any specifics on which kernel features weren't pushed upstream by Red Hat earlier in the 2.4 kernel process.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
This is a technical forum.
It's acceptable to attack someone's code.
It's acceptable to attack someone's decisions.
It's acceptable to attack someone's reasoning.
It's acceptable to attack someone's track record.
It's acceptable to questions someone's mindset.
It's NOT acceptable to attack someone for who they are. This includes your opinion of their intelligence, their Gender, their race, how they dress, etc.
It's NOT acceptable to say that you wish a group of people would die.
One thing that you should keep in mind, is that there is no one perfect solution that solves every problem in existence. Everything involves trade-offs, and the importance of different aspects that are being traded off against each other is very subjective. What you consider critically important may not be so critical to someone else. And at the same time, what someone else considers critically important may not seem so critical to you.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:54 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Validity.... is probably not the right word.
I would argue that calling someone a moron is... ineffective... if your goal is to influence or to persuade people to reconsider their position.
It's one of those things that falls into a class of emotive rhetoric. Emotive rhetoric (both positive and negative) is pretty much only useful for rabble rousing. Anytime you are speaking to people who already agree (or disagree) strongly with the general arguments you are making and you want to people to stop thinking and to start reacting emotional about something. You know propaganda.
If however the goal is to get people to think, then you'll avoid as much emotive language and rhetoric as you possibly can. I would hope that everyone's goal here... including yours... is to get other readers thinking rationally..instead of reacting emotionally.
And of course rational discourse is made entirely more difficult if you start writing (bah I want to say put pen to paper..but sadly this is becoming a lost phrase) in an emotional state. Because of the written medium, you have to anticipate that any emotional leakage you put into your own writing will be negatively amplified in the reaction. The less emotional rhetoric you can put into the writing, the better chance you stand of getting a reasonable response in return.
But if your goal was basically to just cause trouble....you nailed it.
-jef
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:41 UTC (Wed) by nye (guest, #51576) [Link]
>He's filtering you out because you just confirmed that you think ad hominem reasoning is a valid way to argue.
Please go and learn what 'ad hominem' means.
Saying "your argument is wrong because you smell" is ad hominem.
Despite the prevailing LWN opinion, 'ad hominem' is a phrase which actually *has a meaning*. It can't simply be applied to any personal attack.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 16:50 UTC (Wed) by ean5533 (subscriber, #69480) [Link]
I understand that "ad hominem" typically refers to counter-arguing with irrelevant personal attacks. However, I believe it is also valid in this case. HelloWorld was (presumably) trying to make the point that Mark Shuttleworth's business decisions negatively impact the community. One way that HelloWorld justified his point was by calling Mark an idiot. Calling Mark an idiot doesn't explain why his decisions are bad, it's just an irrelevant personal attack.
Regardless, I realize that my usage of that term is non-standard is best and that it was probably the wrong term to use.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 22:47 UTC (Wed) by pboddie (subscriber, #50784) [Link] HelloWorld was (presumably) trying to make the point that Mark Shuttleworth's business decisions negatively impact the community. I think the point was made clearly enough. One way that HelloWorld justified his point was by calling Mark an idiot. Actually, the qualification was removed from someone else's assertion that Shuttleworth was being an idiot in a particular situation. Calling Mark an idiot doesn't explain why his decisions are bad, it's just an irrelevant personal attack. It would be if there were no other observations, but it looks to me like the presumed name-calling is merely a conclusion about the guy after considering those observations. Of course, one could come to a different conclusion - "Mark Shuttleworth is a stubborn visionary", for example - but that would also be based on the observations, not a random statement for the sake of argument. I don't think Shuttleworth is an idiot, nor do I think that statements claiming that Shuttleworth has done nothing sensible for open source software or that he is "worthless for the OSS community" have any credibility, but it is true to say that some of Canonical's moves have been very divisive. "Never attribute to malice that which is adequately explained by stupidity." Maybe that adage is being applied here, and we've all seen the other interpretation in other discussions, but some would argue that it isn't relevant as each of the observations can be refuted in some way. If so, claims of "ad hominem" are not the way to go about doing so.
Shuttleworth: Quality has a new name Posted Apr 29, 2012 20:56 UTC (Sun) by man_ls (subscriber, #15091) [Link] This grants you a spot in my "personal attacks" filter.Amen. I needed to cull these articles with 200+ messages anyway...
Shuttleworth: Quality has a new name Posted Apr 25, 2012 21:33 UTC (Wed) by misc (subscriber, #73730) [Link]
Well to be complete, there was Launchpad ( but this was published, even if the community didn't adapt it to run somewhere else than Ubuntu ), there is Landscape ( and it took them a rather long time to figure that people would like to have it on the other side of the firewall, and that's still not free software ), and there is the android ubuntu integration stuff ( that would become free some day, IIRC, so that may not be fair to count that as non free from canonical ).
The case of ubuntu one is rather interesting, because while there could be support for another server ( there is code for that, and I think U1 support local peer without server ), there was no one motivated enough for that, neither from community nor Canonical.
Launchpad Posted Apr 25, 2012 22:52 UTC (Wed) by pboddie (subscriber, #50784) [Link]
What I would find interesting to discuss is whether Canonical's bets on services like Launchpad have really paid off for them or for the community. There are quite a few projects using Launchpad, but at the same time, there are a lot of projects using services like Bitbucket, GitHub, Gitorious, Google Code, SourceForge, not to mention running their own services using a selection of Free Software solutions.
Would it have been better for Canonical to focus on the distribution or other things? Or is there strategic value in stuff like Launchpad that makes it worth the investment?
Launchpad Posted Apr 26, 2012 0:55 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Understanding which projects are actively using launchpad is a bit complicated because of the way launchpad is positioned as both upstream project hosting and distribution build system sausage factory. Its deliberately designed to blur the line and make it appear as if project development for thousands and thousands of projects is actually happening there. Just because a project is listed in launchpad doesn't mean its being used outside the context of Ubuntu package building.
For example... Networkmanager has a launchpad project listing...it has bzr trees....it has bugs... and none of it is upstream networkmanager project development. Its _all_ distribution specific packaging work...no different really than Fedora's git and bugzilla that feeds into Fedora packaging. But end of the day NetworkManager upstream development uses the freedesktop and gnome development infrastructure for git and bug reporting. Does NetworkManager as a project use launchpad? Hard to argue that it does. Does Ubuntu as a downstream distributor which leverages the work done in the NetworkManager project make use of launchpad...yes..clearly.
Or take Openstack. Openstack is using launchpad blueprints and bugs but is doing the code development primarily with git facilitated by gerrit using launchpad single-sign-on. I mean holy crap...that's so convoluted...all to avoid using bzr and use git instead. Clearly launchpad does provide some very unique capabilities in the blueprints and bug modules..and that magic that is single sign on. Basically all the not really code management bzr stuff. Is OpenStack using launchpad? Yes..clearly. But not in a way you would expect. As soon as github fired up equivalent services like blueprints and a bug report tool....you think openstack would move to using github's version of those services?
All that is to say that it is quite hard to understand how much "upstream" usage there is of launchpad versus how much strictly Ubuntu integration usage there is in launchpad. Obviously launchpad as infrastructure to grind the sausage that is Ubuntu is quite critical...by design...but that's downstream integration choices...not upstream development choices.
http://blog.launchpad.net/cool-new-stuff/setting-up-comme...
And remember that a lot of Canonical's projects started out as private projects with OEM partners inside the launchpad infrastructure. So the business model aroud the private partnership stuff did make sense at one point...back in the day when HP and Canonical were working hard on Mi (poor Mi) launchpad sort of made sense for private collaboration in that sense but that was a while ago now...before git one the distribute tool war.
-jef
Launchpad Posted Apr 26, 2012 10:30 UTC (Thu) by cas (subscriber, #52554) [Link]
github already has a bug reporting tool (i prefer it to launchpad's), and it's reasonably well integrated with git pull requests so is quite useful for devs as well as end-users. afaik, they don't have launchpad's blueprints or roadmap feature yet.
Launchpad Posted Apr 26, 2012 12:03 UTC (Thu) by pboddie (subscriber, #50784) [Link]
A notable downside to GitHub is that it's a proprietary service, although I imagine it's possible to migrate away from it, and I suppose that with Launchpad you could at least potentially deploy your own instance. But then again, I'm not really aware of any other deployments of Launchpad, whereas lots of people use stuff like Trac, Redmine, combinations of other tools.
I just wonder whether all the effort put into Launchpad, Bazaar, the needless tying together of the two, was strategically worth it.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 9:45 UTC (Wed) by ovitters (subscriber, #27950) [Link] This is a fact, not an opinion.Having an opinion and believing strongly in it doesn't make it a fact. The rest of your post doesn't provide much content and furthermore, it seems you're focussed on saying "I am right!" in a trollish way instead of having a discussion.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 14:56 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> The rest of your post doesn't provide much content
Oh, it does, it seems you didn't understand it though. Fortunately, that is not my problem. To quote Linus Torvalds: "Happily, I don't _need_ to convince you".
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:05 UTC (Wed) by ovitters (subscriber, #27950) [Link]
You're no Linus :P
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:12 UTC (Wed) by HelloWorld (guest, #56129) [Link]
I'm actually happy about that.
Shuttleworth: Quality has a new name Posted Apr 27, 2012 0:52 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Ah, sorry, I didn't get the message that we shall not listen to you. my fault.
*PLONK*
Shuttleworth: Quality has a new name Posted Apr 26, 2012 10:21 UTC (Thu) by cas (subscriber, #52554) [Link]
speaking as a DD since 1994 or so, debian has *always* been meant to be a base for other distributions as well as a distribution itself.
ubuntu has not "ripped off" debian's work any more than any distro has "ripped off" the FSF's work or any other free software project's work. ubuntu used debian's work in a way that it was always intended to be used. good luck to them.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:28 UTC (Wed) by jond (subscriber, #37669) [Link]
You attribute an awful lot to "him" personally here! I don't think a constructive counter-argument could be made until you've provided some citations for those claims.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 15:31 UTC (Wed) by HelloWorld (guest, #56129) [Link]
There's this wonderful thing called a search engine. You should try it some day.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 0:18 UTC (Wed) by kklimonda (subscriber, #60089) [Link]
upstart actually supports socket activation http://manpages.ubuntu.com/manpages/natty/man7/socket-eve...
Shuttleworth: Quality has a new name Posted Apr 25, 2012 7:51 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
This kind of Upstart socket activation is pointless and misses the point entirely. It is not useful to parallelize boot-up, only for doing on-demand activation of services. But the on-demand activation is really not that interesting, the parallized boot-up however is.
I have pointed that out a couple of time to the Upstart developers, but that didn't help. They entirely miss the point of socket activation with their bridge, and just confuse everybody with this half-assed implementation.
Or to say this with different words: Upstart tries to map socket activation into an "event" (since for Upstart everything is about "events"), however sockets are not events, they are established for a long time, and need to be passed to services even without an event actually being triggered.
Let me stress that: Upstart does *NOT* support socket activation in the way how it would actually be useful.
Lennart
Shuttleworth: Quality has a new name Posted Apr 24, 2012 22:47 UTC (Tue) by paravoid (subscriber, #32869) [Link]
Technical arguments aside, the irony is that Lennart's trollish behavior, i.e. his style of writing, his stretched-out arguments (like the distribution statistics or the hilarious init systems comparison that he once put on his page) and his agenda to force people to choose his project over alternatives (like the merger of udev and systemd codebases) is actually producing the exact opposite result of the intended.
It's pushing people away from systemd. Even if upstart didn't exist, people would probably *write* one, just to avoid shitty upstreams. It has happened before to a lesser extent with projects like ion3 and cdrecord.
The difference this time is that RedHat actively supports the project and controls a big part of the Linux ecosystem, so this has turned out to a corporation/vendor battle :(
Shuttleworth: Quality has a new name Posted Apr 24, 2012 23:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>It's pushing people away from systemd. Even if upstart didn't exist, people would probably *write* one, just to avoid shitty upstreams. It has happened before to a lesser extent with projects like ion3 and cdrecord.
Given that almost all major Linux distributions are supporting (or going to support) systemd, Lennart's style appears to work just fine.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 0:36 UTC (Wed) by paravoid (subscriber, #32869) [Link]
That's what Lennart seems to suggest as one of the arguments and is part of the problematic behaviors I was referring to in the parent.
Fedora is of course using systemd and RHEL will follow of course. openSUSE also apparently switched.
Ubuntu isn't going to switch and Debian hasn't made a decision yet.
Gentoo and Archlinux are experimenting with it in the "unsupported" and "extra" repositories respectively. Mageia will switch in its next release. I'm not sure if I'd count those three in the "major distributions" anyway.
(source: Wikipedia)
Yes, you could say that the picture above is "almost all major distributions", for some variation of "almost all" and some variation of "major", but then you'd sound a lot like Lennart (or a politician).
Shuttleworth: Quality has a new name Posted Apr 25, 2012 4:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, Ubuntu, SUSE, RedHat (CentOS, Fedora) and Debian are the main distributions. Everything else is negligible.
Out of these three, only Ubuntu is not committed to systemd.
You might also note, that Debian isn't really committed to upstart also. They support the bad old SysV scripts as well.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 8:24 UTC (Wed) by paravoid (subscriber, #32869) [Link]
Wow, that's an interesting way of counting...
For the sake of simplifying your argument, let's keep your definition of a major distribution (fwiw, I wouldn't count openSUSE).
So, out of "Ubuntu, SUSE, RedHat (CentOS, Fedora) and Debian", the set of distros that have chosen systemd as their new generation init system is "SUSE and RedHat (CentOS, Fedora)".
That's a fact. How can this be interpreted as "almost all major Linux distributions"? If it can, then by the same definition can also be interpreted as "almost none of the major Linux distributions" :)
init in Debian Posted Apr 25, 2012 12:58 UTC (Wed) by rleigh (subscriber, #14622) [Link]
> You might also note, that Debian isn't really committed to upstart also.
> They support the bad old SysV scripts as well.
Work is going on to enable sysvinit to run upstart jobs, which will enable packages to start providing upstart jobs in place of/in addition to init scripts. I'm not sure it's the best plan, but I'll accept it rather than stand in the way of preventing the adoption of better init systems. It's already in sysvinit git; it's not enabled yet due to requiring some additional changes.
However, it turns out that systemd does a much better job of sysvinit compatibility than upstart, which will make it much easier for Debian to transition to systemd rather than upstart. There's no need to replace the sysvinit scripts.
I've been doing a lot of work on sysvinit/initscripts to make it much easier to transition between sysvinit and systemd, as well as to support some of the features offered by systemd. While Debian will be using sysvinit for wheezy, switching is certainly something that could be considered for the following stable release.
A big black mark against systemd is the upstream attitude to non-Linux ports. If it wasn't so awful, we might have been in a position to push for its adoption in wheezy. As it is, that was untenable. While systemd uses Linux-specific features heavily, just having it /work/ on non-Linux, albeit without all the features being available, would be desirable. The attitude of not even being willing to consider patches for non-Linux platforms is a non-starter. Support for non-Linux platforms is also useful for portability to other versions of Linux which don't have all the specific features systemd requires--there's no need to paint ourselves into a corner of incompatibility through mandatory use of Linux-specific features.
Regards,
init in Debian Posted Apr 25, 2012 13:02 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Openssh is OpenBSD specific, with a separate team responsible for producing a portable fork. It seems a little odd to criticise systemd for doing much the same thing.
init in Debian Posted Apr 25, 2012 13:22 UTC (Wed) by rleigh (subscriber, #14622) [Link]
Why? They are both exceptions to the rule, and both are deserving of criticism here. Not actively working on portability is one thing, but being unwilling to consider patches from others to make it portable is quite another.
init in Debian Posted Apr 25, 2012 13:27 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Portability comes at a cost, and it's a completely rational choice for the people who maintain a project to be unwilling to accept that cost. Maintaining a separate portable branch seems to be a perfectly reasonable compromise.
init in Debian Posted Apr 25, 2012 13:46 UTC (Wed) by rleigh (subscriber, #14622) [Link]
While portability certainly does have a cost, it is a cost most projects are willing to pay. It's not usually that great--we're not talking about anything other than POSIX portability, after all. From what I can tell, this mainly centres around making cgroups optional. That's useful to have even on Linux. Being unwilling to accept patches from other people who are willing to do the porting work is entirely counter-productive.
There's also a significant cost placed on porters by being forced to work out of the main tree. This also needs consideration.
init in Debian Posted Apr 25, 2012 13:54 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The work the porters have to do is work that the maintainers would have to do otherwise. Requiring that the trees be separate is merely a way of ensuring that the work is done by the people who benefit, not the people who don't care.
init in Debian Posted Apr 25, 2012 14:37 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
I said this before, and I am saying this again. That we as upstream don't care about portability patches to other kernels is a fake problem for you. Porting systemd is not really feasible, because we want our stuff simple, and clean, and small and hence use the Linux APIs directly instead of creating a huge abstraction for them. And that's your actual problem! You can't even get to the point where you could submit a portability patch, that we then could refuse to merge!
And even if you could write a portability patch, then in times of git it would be really easy to maintain it even out-of-tree.
Anyway, summary is: your problem is the technical unfeasibility of a port to freebsd, it's not our political dislike for such a patch and the maintainance burden.
If debian one day would like to go for systemd but at the same time still wants to go on with kfreebsd, then it has to pay the price for it, and just ship both init scripts and unit files in the packages. In fact we made this nice and easy by transparently overriding sysv scripts with native files if both exist.
Lennart
init in Debian Posted Apr 25, 2012 15:30 UTC (Wed) by Zack (guest, #37335) [Link] > because we want our stuff simple, and clean, and small and hence use the Linux APIs directly
$apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
Please note how the above cow is distinctly *not* spherical.
init in Debian Posted Apr 25, 2012 15:43 UTC (Wed) by dgm (subscriber, #49227) [Link]
If Systemd is not really portable, have you considered making it as easy as possible to create compatible work-alikes?. It's perfectly possible that the BSDs will eventually try to do something similar. Being completely compatible would be a huge boon for both (and would remove a big hurdle in the path to Debian).
init in Debian Posted Apr 25, 2012 15:54 UTC (Wed) by dgm (subscriber, #49227) [Link]
I know, I'm retarded, because they already thought of that and It didn't cross my mind to check it beforehand: http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Sorry for the noise.
init in Debian Posted Apr 25, 2012 15:58 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Well, there is the interface stability promise, which seems at least somewhat helpful in this regard.
init in Debian Posted Apr 25, 2012 21:20 UTC (Wed) by slashdot (guest, #22014) [Link]
Stop saying this, it's just totally stupid, and hurts systemd adoption for no reason.
It's pretty obvious that it is possible to create a systemd compatible init for any OS, whether by porting the existing systemd or writing a new implementation, since nothing important is fundamentally tied to Linux.
There's also no point in rejecting a well-written non-intrusive portability patch (where "non-intrusive" means that it mostly consists of new files implementing Linux APIs for $OS, with minimal changes to systemd only where absolutely necessary).
Instead, please try to push it in Debian at all costs (possibly including doing a FreeBSD port yourself), since once Debian adopts it, the morons at Ubuntu will be forced to adopt it too, and sysvinit and upstart will finally die forever.
init in Debian Posted Apr 25, 2012 22:05 UTC (Wed) by mpr22 (subscriber, #60784) [Link] The inescapable process grouping is important (it seems to me the second most attractive feature after the whole "simple cases are much simpler" effect from the declarative config). Does any kernel other than Linux provide a comparable feature with close-enough semantics? Are the maintainers of any kernel other than Linux contemplating providing such a feature?
init in Debian Posted Apr 25, 2012 23:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
<idea category="crazy">
On FreeBSD, the system could just set up a jail for each service. Mount filesystems as nullfs (for bonus points, be smart about ro and rw directory mounting[1]). It would need some changes so that the jail has the same IP and network view as the main system, but that might be minor compared to what a full cgroups implementation would be like.
[1]The .service file could even have this information and then systemd could set up top-level filters for open; FreeBSD would get it for "free" under the jails with selective mounts while Linux would need syscall filtering or automatic LXC creation.
init in Debian Posted Apr 25, 2012 23:32 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm. You might check the recent systemd.
It does filesystem confinement just fine (using cgroups), along with secure per-app /tmp.
init in Debian Posted Apr 26, 2012 2:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Ah, didn't know that.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 5:14 UTC (Wed) by scientes (guest, #83068) [Link]
If this[1] project gets finished we will be able to write all our startup scripts as systemd units, which can then be converted into sysvinit scripts and run on sysvinit or upstart, thereby freeing us from these long-winded flamewars, while still providing the speed benefits that systemd brings for those that use it.
http://wiki.debian.org/SummerOfCode2012/StudentApplicatio...
systemd to Sys V init converter Posted Apr 27, 2012 20:57 UTC (Fri) by MrWim (subscriber, #47432) [Link]
Fascinating. I wonder how they will derive the dependencies that socket activation takes care of but are not explicit in the service files.
Shuttleworth: Quality has a new name Posted Apr 25, 2012 5:33 UTC (Wed) by cmccabe (guest, #60281) [Link]
I see this as another reason not to use Ubuntu.
Startup time Posted Apr 25, 2012 7:43 UTC (Wed) by Felix.Braun (subscriber, #3032) [Link]
I don't mean to add more oil into an already busy flame fest. It's just that I am surprised nobody seems to share my experience.
I have tried Fedora because I actually liked systemd's design principles. However, I was never able to make fedora boot as fast as my Ubuntu systems. I admit that I haven't tried digging very much deeper than disabling a couple of targets that I don't need on my system. But, on the other hand, no such tweaking was necessary with Ubuntu.
If my experience was representative at all, preserving faster startup times seems to be enough reason to hold on to upstart.
There is a lot of heated debate in this thread about backwards compatibility, UNIX philosophy, hackability and whatnot. But at least on my setup booting Ubunutu (12.04) is about 20s faster than booting Fedora (16). For me that is reason enough to prefer Ubuntu.
How do upstart and systemd compare performace-wise in your setups?
Startup time Posted Apr 25, 2012 8:43 UTC (Wed) by luya (subscriber, #50741) [Link]
Fedora 16 still has some legacy from sysVinit hence slow boot. It would be hardly surprise Ubuntu upstart is heavily optimized than the generic systemd. Some Fedora users were able to obtain faster bootup with systemd on this topic:
http://forums.fedoraforum.org/showthread.php?t=276520
Startup time Posted Apr 25, 2012 8:51 UTC (Wed) by ovitters (subscriber, #27950) [Link]
That wasn't given as a reason in the announcement. If you follow Google Plus (Lennart; has comments from Scott) you can see that there are various technical reasons (speed, a few others) for the decision... but that is not the impression which I got from this announcement.
Boot speed is a very valid reason. Also, seems that there is some confusion if a initrd is needed or not (affects booting speed for chrome os).
It is good to know the technical reasons as hopefully then those reasons can be worked upon / fixed / wontfixed in systemd.
Up to seeing the technical comments the impression was that it was a bit arbitrary: don't focus on kernel, but focus on the init system (both are to me important, but uninteresting low level stuff... it should just work :P).
Startup time Posted Apr 26, 2012 21:50 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
There's no evidence that systemd is incapable of handling the ChromeOS situation that Scott refers to. Scott is being overly vague about the ChromeOS filesystem layout in his comments as it pertains to the necessity of using an initrd. ChromeOS uses a novel and very unique arrangement for its file system and partitioning which is not a one-to-one mapping base filesytem elements. So whatever the common understanding is with regard to filesystem and partitioning for the typical distribution situations...does not automatically apply to what Scott is talking about obtusely. And Scott hasn't really put enough details into the public discussion to make it clear what ChromeOS is doing exactly.
Let's be clear.... whether or not you need an initrd comes down to your filesytem layout and where you store executables and libraries and configs needed during the early boot process. If you can construct your layout in such a way that everything systemd needs to mount the rest of the system exists in the root partition you can most likely avoid an initrd and thus avoid the boot up cost associated with an initrd.
If we want to talk about relative performance... then that discussion must be driven by agreed on testing methodology and the resulting data.
-jef
Startup time Posted Apr 26, 2012 22:04 UTC (Thu) by ovitters (subscriber, #27950) [Link]
I meant more in view of the likely speed of upstart vs systemd in Ubuntu 12.10.
Background: Mageia 2 will use systemd, but because of still allowing to fall back to sysvinit, a full switch takes a while and it takes a while to really optimize things, the boot speed of "systemd" Mageia 2 might often be slower than sysvinit Mageia 1. In Mageia 3 systemd will probably outperform Mageia 2 and 1 easily.. but until that time systemd will often be seen as slow.
I saw that Ubuntu has often given loads of attention to boot speed. Though systemd might be capable of the same speed or better, achieving a full switch + same boot speed in just 6 months (12.10) + avoid bugs: I can understand the hesitance. In an email on ubuntu-devel it stated that upstart took 5 releases to get right.
Startup time Posted Apr 26, 2012 22:17 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Be aware that Scott was specifically referring to ChromeOS not Ubuntu.
I'm pretty sure the issues Scott is worried about do not apply to Ubuntu. I'm pretty sure Ubuntu uses an initrd by default and pays whatever penalty there is for that.
I would absolutely LOVE to see a comparison of boot performance on Ubuntu for a fully native systemd init versus a fully native upstart init (no sysvinit scripts). I think that would be a very useful thing to have in hand prior to the UDS discussion about the future of upstart in Ubuntu. There is a reason why noone is actually claiming performance benefits from upstart on Ubuntu. Because the comparison simply has not been done. We do not know..even for a simple reference desktop boot. What if systemd is faster right now..even after Ubuntu put effort into optimizing services for upstart's approach?
Upstart doesn't have an equivalent concept to systemd's lazy socket initialization which allows for high parallization of services, and I'm very interested to see how the different approaches actually compare once you pull sysvinit scripts out entirely. I actually expect Debian to provide this analysis at some point, as that community is having a real debate about the decision. Ubuntu, being Canonical led, lives with the decision being handed down. The proponents for either in Debian are going to have to make the case with public discussion. Canonical... not so much.
-jef
Startup time Posted Apr 25, 2012 11:55 UTC (Wed) by ebiederm (subscriber, #35028) [Link]
I haven't timed it any great detail but my fastest setup is debian with it's dependency based boot using make.
Debian seems to be light weight and simple and just work compared to the rest.
|
|||||||||||||