Weekly Edition
Return to the Distributions pageRecent Features
| |||||||||||||||||||
Tumbleweed backs off on systemd for now
Due to a number of interdependancies on packages that are not ready for Tumbleweed, and other interactions with the system that are causing problems for some users, I'm going to remove systemd from Tumbleweed today to allow the developers to spend more time on getting it stable for Factory and 12.1 instead of having to chase down problems that are specific to Tumbleweed only. So if you have installed systemd in Tumbleweed, I suggest you now remove it with a simple: zypper rm systemd thanks, greg k-h (Log in to post comments)
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 14:52 UTC (Tue) by cjcox (guest, #60378) [Link]
One of the wisest moves in history.
Systemd is an unscoped project. It is growing and continues to grow impacting kernel and system daemon processes. The first round of systemd based platforms should be very difficult. IMHO, systemd programmers are making a lot of assumptions and while they are starting to see a glimpse of the complexity of things, I think we're quite far away from something stable.
I'm not saying that some of the ideas behind systemd aren't good, but the overall design is bad IMHO. This could have been done better. Looks more like a fun classroom project... might get an 'A' on the project, but I fear for anyone that implements it at this juncture.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 15:02 UTC (Tue) by quintesse (subscriber, #14569) [Link]
Don't you think you're exaggerating a bit? I think you can at least leave the H out of you're IMHOs ;)
I think it's exactly the other way around, the overall design is brilliant but we'll probably see in the future that some of the decisions might not have been the best, but we'll never know without actually using it. That's why I use Fedora, I say "just bring it on!".
Of course I'm one of those persons who hasn't had any problem with Pulse Audio for ages now and think it's actually quite good so I might not feel the need to rile against another Poettering project ;)
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 6:50 UTC (Wed) by dsommers (subscriber, #55274) [Link]
> I think you can at least leave the H out of you're IMHOs ;)
Unless that H is for Honest ...
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 8:38 UTC (Wed) by dgm (subscriber, #49227) [Link]
> Of course I'm one of those persons who hasn't had any problem with Pulse Audio for ages now and think it's actually quite good so I might not feel the need to rile against another Poettering project ;)
I'm certain that systemd will also get there, eventually. The problem is that it's not there yet, and the system it tries to replace, even with all his warts, is solid and well understood. And let's not forget that we are talking about a critical part of the system.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 11:06 UTC (Wed) by neilbrown (subscriber, #359) [Link]
One thing that bugs me about systemd is that it is presented as all-or-nothing. flag-day changes are always painful and should be avoided when possible and minimised when essential.
So I would much rather that in the first instance, systemd was 'just another daemon' like inetd and it was given some simple services to manage. Then people could become familiar with it without the risk of paralyzing their machine.
Then services could be gradually migrated across until eventually the only thing that the sysvinit started was systemd.
Then a mini-flag day when we discard sysvinit and run systemd as pid-1.
Incremental development has a long tradition of working well in Linux circles...
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 13:08 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
In Fedora 14, systemd was optional. In Fedora 15, it was the default with a smaller number of services converted. In Fedora 16, a lot more will be and so on. This is incremental progress
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 16:31 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] And my impression is that one of the design goals of systemd is to maintain significant backward compatibility with SysVinit. For example, it can use existing init scripts to manage services rather than its native configuration files. It can take advantage of cgroups for process management, but it's capable of working on systems without cgroup support. And so forth. You don't get the full power of the new system when you run it using the backward compatibility features, but it does work.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 14:33 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> I'm certain that systemd will also get there, eventually. The problem is that it's not there yet,
This is, again, just meaningless FUD. If you see an actual problem with systemd, then explain what it is, instead of nebulously asserting that it's "not there yet".
> and the system it tries to replace, even with all his warts, is solid and well understood.
Systemd is fine on Fedora 15 Posted Sep 20, 2011 15:04 UTC (Tue) by Alterego (subscriber, #55989) [Link]
The only was that i needed to "learn" howto start/stop a service with it. This took approximately 10 seconds :)
But "people" are often reluctant to change, and hide behind various pseudo-excuses, this may be the most difficult part for systemd.
Systemd is fine on Fedora 15 Posted Sep 20, 2011 17:05 UTC (Tue) by imitev (subscriber, #60045) [Link]
same here, except it took 60 seconds :)
would have been nice though to have a hint to the systemd command when using the "old" way - "service blah start" or "/etc/init.d/blah stop" - until it becomes an habit using only systemd's syntax
Systemd is fine on Fedora 15 Posted Sep 20, 2011 18:55 UTC (Tue) by vonbrand (subscriber, #4458) [Link] It took me some 60 seconds to grasp it, and a week or so to train the fingers. But a few months later I'm still not completely confortable with some of the unit names.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:15 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> I'm not saying that some of the ideas behind systemd aren't good, but the overall design is bad IMHO. This could have been done better.
Then please either do so or shut the fuck up trolling.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:17 UTC (Tue) by corbet (editor, #1) [Link] Trolling or not, this kind of response is far from helpful. Next time, can we try, say, a polite request for information on how the design could have been done better...?Thanks.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:26 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Next time, can we try, say, a polite request for information on how the design could have been done better...?
What for? If he had such information, he should have provided it in the first place. The fact that he didn't shows that all he wants to do is bitch about systemd, so why should I bother with cordiality?
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:29 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Because you are on LWN, that's all :-)
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:29 UTC (Tue) by corbet (editor, #1) [Link] Because the LWN comment form asks you to be polite and respectful. Things really do work better if we all try to do that. In this case, if the original poster has no information to provide, it will become clear soon enough.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:43 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Great, tell the OP about it! Because calling a project badly designed without giving any reason whatsoever (and thus leaving its authors without any chance to refute anything) is neither polite nor respectful in my world. And yet, you're complaining about me...
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:55 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
If you can't be polite when replying and feel the urge to swear, you might as well as take a break and do something else and calm down.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:10 UTC (Tue) by JamesErik (subscriber, #17417) [Link]
I would say that, rather than "complaining", several of us are pointing out tactfully that we value and expect *civil* discourse here. It is part of LWN's gestalt that is well worth defending.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:35 UTC (Tue) by welinder (guest, #4699) [Link]
I think you failed to note exactly who complained over you.
That "#1" might be a hint.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:45 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Don't worry, I've noticed who that is. What difference is that supposed to make?
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 18:13 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Corbet doesn't tell people to tone it down often and when he does, pay attention. We have a unusually high level of signal compared to noise in this site and we must maintain this collectively.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 20:29 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> We have a unusually high level of signal compared to noise in this site and we must maintain this collectively.
That's why I told cjcox to produce something more signal-like or at least stop making noise.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 7:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Its not about what you said. The problem is with the way you said it. It was not constructive.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:21 UTC (Tue) by dashesy (subscriber, #74652) [Link]
The design is modern and beautiful and there is still the option for hackers who prefer the comfort of hand-tailored bash scripts. The only downside in my opinion is the numerous mount points it adds.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:52 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Downside in what way exactly?
There is an observable downside in terms of system performance with the use of many virtual filesystem mounts like tmpfs and cgroup mounts?
-jef
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:15 UTC (Tue) by imitev (subscriber, #60045) [Link]
mount | wc -l:
rhel5.7: 10
It's becoming increasingly difficult to understand mount's output, maybe that's what the OP had in mind - although it's not clear (to me) how many mounts are because of systemd only vs. how many are because of new features between rh5/f6 and f15...
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:43 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
This is not strictly an issue with systemd.
This is a a problem that has existed for some linux users all the way back to at least 2005. If you ever wanted to run a linux system with / read only and you wanted correct mount information then you were already doing the /etc/mtab symlink trick.
For reference all the way back to 2005:
So Here we are in 2011, finally having to deal with the fact that the concept of a "mountable" filesystem as understood by the linux kernel has gotten much much more complex over the last several years. And that's just the beginng of the issue. You do low level valid syscalls which interact with the kernel's concept of a mount and the userspace /etc/mtab (as its controlled by the mount tool not by the kernel) goes out of sync.
This is a reality and has been a reality for years and years. Some sysadmins might not have been aware of that problem..but its been there for a long time.
And the userspace tools haven't kept up with that reality and its been known since 2005 that the existing userspace mtab was not suitable as a general solution to keeping up with mount state. systemd just makes this bloody obvious. Shoot the messenger if it makes you feel better, but don't ignore the message. The only way you can keep an accurate record of mounts is to rely on the kernel's representation of mount objects. The old /etc/mtab way does not work reliably.
So now someone gets the task of fixing the userspace tools to deal with trying to find a way to provide multiple ways to view that kernel mount information and try to hide some of the virtual filesystems like tmpfs and cgroups.
-jef
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 17:44 UTC (Tue) by vonbrand (subscriber, #4458) [Link] On Fedora 15 I get 40 lines of output from mount(8), not counting various cgroups it's 29. And many of those are virtual filesystems that give a peek into the kernel's inards, so that depends more on the base kernel version than anything else. In any case, what do you want to read the full output for? It is easy to check just what you need, oblivious to whatever other cruft it might spew at you. I hadn't looked at the full output for ages.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 19:19 UTC (Tue) by imitev (subscriber, #60045) [Link]
>> "In any case, what do you want to read the full output for"
You mean filtering the output ? Reading quickly through a few short lines is easier / takes less time than thinking of a search pattern: oh, what was the fs type again ? where was it mounted ? what are the mount arguments, ...
[Note: as I'm getting used to systemd - which I like - I'll just get used to have 40+ lines of mount output. I'm just outlining it used to be a bit easier before, and that for various reasons people still need to go through mount's output (I often do). As jspaleta points out user space may evolve and maybe distros will begin to ship helper scripts or patched mount...]
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 19:27 UTC (Tue) by imitev (subscriber, #60045) [Link]
>> As jspaleta points out user space may evolve and maybe distros will begin to ship helper scripts or patched mount
replying to myself: /me will have to check new commands when upgrading (thank you juergbi for the pointer to findmnt)
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 15:32 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
Maybe what you actually need is df -T #?
Tumbleweed backs off on systemd for now Posted Sep 22, 2011 3:13 UTC (Thu) by jcm (subscriber, #18262) [Link]
I get "too many lines". Too many lines is defined as more than /proc, a tmpfs or two, and my filesystems. When I have to sift through dozens of lines of useless mounts to get to the crux of what I'm using, then it's too many and it's unusable. Sure, it's not systemd's fault that mount, df, and friends don't make this easier, but it was systemd that changed the world to the point that this became a problem. As part of integration, this stuff should be addressed (and that means other than by adding a GUI for df).
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 19:16 UTC (Tue) by juergbi (subscriber, #76126) [Link]
Have you tried findmnt? Its output is much easier to read.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:28 UTC (Tue) by rvfh (subscriber, #31018) [Link]
> One of the wisest moves in history.
You _do_ realise that it is going into 12.1 don' t you? And thus it is being _temporarily_ removed from Tumbleweed.
> [...] the overall design is bad IMHO.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 18:28 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I personally came at systemd without a preconceived notion that it was wrong or a failure and instead read the design docs and was excited. It also helps that many years ago the team I was with gave up on sysvinit and unmanaged daemons and tried to only run services under daemontools.
I don't understand all this hostility at all, except as the standard resistance to change regardless of the merits of the change. No-one is even using sysvinit anymore for the purposes that it was developed, services have shell scripts that start them and "daemonize" by default rather than adding new daemons to /etc/inittab and letting init monitor/restart the processes. sysvinit failed when run-parts and other tools were developed to work around its inadequacies.
I just don't see how one could come to the impression that this is not a professional and thoughtfully put together project after reading all of the long systemd for administrators blog posts that were highlighted by LWN when they came out. I'm not sure how one can be blind to the inadequacies of the old sysvinit system and not see the benefits of other systems such as Upstart, daemontools, runit, etc. I'm not sure why it's bad to comprehensively deal with user and service session management, i'm not even sure that it's wrong to use modern kernel features to do so.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 11:25 UTC (Wed) by whitemice (guest, #3748) [Link]
I've been a professional UNIX/LINUX System Administrator for ~20 years...
> I personally came at systemd without a preconceived notion that it was
Yep. The claims that systemd is complex and not well understood - in relation to the pile-o-hacks that is the current script based init system?
"Captain! The bogosity field is approaching maximum containment!"
If anyone, and I mean anyone, claims to "understand" the current init system - that person is full of crap. The current system is the nightmare everyone is claiming systemd is; it is buggy, complex, slow, and *extremely* fragile. I know how to *use* and modify the current init system to accomplish common goals - but there is no understanding that thing as there is very little to anything of a "design". It has been built via the uh-oh-we-need-to-deal-with-that-now method. The method it uses to determine initialization order can barely be described as a method.
> I don't understand all this hostility at all,
+1
And on my laptop Pulse Audio works perfectly, and has since almost the beginning. Much like the Beagle search tool a couple of buggy initial releases have been perpetually held against by a small but loud group of users [who generally just like to hate things, IMNSHO]. I predict that systemd will face the same fate - it will be adopted but there will be some initial issues and a segment of users will spend the next decade talking about how much systemd sucks - while everyone else forgets about it because it just-works. And their systems boot so much faster they don't have to watch it roll-by every time they power on.
Tumbleweed backs off on systemd for now Posted Sep 22, 2011 6:33 UTC (Thu) by smurf (subscriber, #17840) [Link]
+1 again.
systemd may not yet be at the stage where it needs to be, but I'm pretty sure it'll get there.
Just like PulseAudio, in fact. Did you ever try to sync to a new Bluetooth headset and play your music through it? With pulse, that stuff just works. Today.
Tumbleweed backs off on systemd for now Posted Sep 23, 2011 18:21 UTC (Fri) by nevets (subscriber, #11875) [Link]
Actually, my desktop can't play sound anymore after I did an upgrade. PulseAudio for some reason just wants to use my USB headset, and ignores the speakers. Every so often I tweak a bunch of things to get it working, but after a reboot, it's gone again.
Two years ago, my desktop sound worked out of the box. Today? Not so much.
Tumbleweed backs off on systemd for now Posted Sep 23, 2011 18:37 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
To be clear, what is the expected default scenario on boot from your perspective?
With the usb headset plugged in you want the sound to be routed to both the speakers and the usb headset as the default configuration?
-jef
Tumbleweed backs off on systemd for now Posted Sep 23, 2011 21:58 UTC (Fri) by nevets (subscriber, #11875) [Link]
I want sound to default to my speakers. I have a single app (twinkle) that should go to the headset. Note, this headset has a mic and is for calling. Twinkle can select which source dependent from other sound apps. I have yet to figure out how to consistently make it default to the speakers.
pulseaudio digression [Tumbleweed backs off on systemd for now] Posted Sep 23, 2011 22:35 UTC (Fri) by sfeam (subscriber, #2841) [Link] I've had similar aggravations ever since pulseaudio appeared. In my case there is no bluetooth involved, but pa randomly loses devices and settings across suspend/resume, shutdown/reboot, and even at less well defined times. I have found no real solution, but for me it mostly worked to get an acceptable state in place and then do "chmod -R a-w ~/.pulse". That obviously has other drawbacks, but at least it stopped losing track of the devices altogether. And the instantaneous settings mostly got pinned as the default state.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 16:52 UTC (Tue) by jonabbey (subscriber, #2736) [Link]
It's true that it takes a bit of doing to move a distribution to systemd. Fedora 15 has had some teething problems with it, including issues of startup sequencing for network (NIS, automounter) services for us.
But they've been dealt with quickly, and things are pretty good right now.
Not bad for a 4 month old distro with such a radically different system init daemon, really.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 18:33 UTC (Tue) by cjcox (guest, #60378) [Link]
Thanks for all of the replies! Really, I think it's a good thing to see that people are using systemd successfully. My statements are based primarily on the traffic on the systemd mail list. As an original advocate for systemd, I'm not making my stand lightly. Systemd's goals are confusing to me. Time will tell if systemd causes problems or not. But based on the amount of change and level of change happening, I'm not convinced that the move is going to be painless. My concern is that systemd does require a contemporary kernel and does require some rewriting of daemons. This might make not using systemd a more difficult option for those not wishing to rock the boat. Not to mention that systemd does not adequately address all the things that were possible with old sysv style init. Their argument: Who who do those things anyway?
With regards to the "new" interface, I think people have been using the service command abstraction long enough without systemd to not be too thrown by that.
What I see is a lot of code, a lot of scope creep, a lot of code changes... and these things usually spell disaster. I would love to be wrong. I was guessing that the noise was getting in the way of GKH and openSUSE folks, but maybe there was another motivation for pulling it out for now.
Another guess on my part is that neither RHEL nor SLES want to release something with quirky behavior. It is my gut that says there will be quirky (bad) behavior.... so I guess I'll just say: Make me wrong... and be done with it.
I appreciate the comments. Systemd (as it stands) still scares me to death. Let's see what happens (I'm sort of glad to see that others don't see systemd as being a potential problem... gives me hope).
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 19:11 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Please enumerate what things were possible with sysvinit and can't be done today. Then explain when you would use each of them As for exploiting new kernel features, why, they are there to be used. Why waste a perfectly good cgroup (or something else) management when it is available? Even sysvinit required some special kernel tweaks (passing runlevels around, at the very least). Daemon rewriting, especially if it means getting rid of repetitive and error-prone drop privileges, daemonize, manage children code, is welcome (like it is a pleasure to be able to write a network service under {,x}inetd instead of directly accessing the 'net). Ditto for getting rid of hundreds of "init library" shell lines, and (again) long, repetitive, error-prone, hard to test shell scripts for managing services.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 20:09 UTC (Tue) by jonabbey (subscriber, #2736) [Link]
This.
It's far better to pull the complexity in towards a well engineered core than to require the complexity to be smeared out across hundreds or thousands of applications.
It'll be a long time before daemon authors can trust that systemd will be there, but I'd rather write to systemd than sysv init.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 9:05 UTC (Wed) by NAR (subscriber, #1313) [Link] Please enumerate what things were possible with sysvinit and can't be done today. Then explain when you would use each of themI'm aware of Poettering's views on portability, nevertheless my requirement is to make an application that works on Solaris and on a specific brand of Linux, so I don't like any extra incompatibility introduced, because that's more work for me. For example currently we use the very same SystemV init script on both Solaris and Linux. Based on my understanding of the systemd documentation we can keep on using the same script, so probably systemd (when it will be introduced at our customers in about 5 years time) won't cause any headaches for us, but I can understand other application developers who might not want to embrace systemd.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 13:32 UTC (Wed) by HelloWorld (guest, #56129) [Link]
So you're saying that you can understand people who don't want to "embrace" systemd, and yet in the same posting you explain why there's absolutely no reason not to? Am I the only one to whom this seems weird?
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 17:22 UTC (Wed) by NAR (subscriber, #1313) [Link]
Probably yes. The systemd documentation does mention some incompatibilities - the fact that they don't seem to bite me doesn't mean it can't bite somebody else.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 17:44 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Those incompatibilities only bite scripts that are broken begin with. If you, say, rely on sysvinit ignoring your broken LSB headers, you deserve to be punished.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 14:27 UTC (Wed) by nix (subscriber, #2304) [Link] Why waste a perfectly good cgroup (or something else) management when it is available?Incoming ballistic Viro expected shortly to explain.
Tumbleweed backs off on systemd for now Posted Sep 22, 2011 2:05 UTC (Thu) by vonbrand (subscriber, #4458) [Link] /me runs for cover...
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 19:24 UTC (Tue) by mezcalero (guest, #45103) [Link]
systemd does not require rewriting daemons. Not at all. No patching required. You can patch your daemons if you wish, to integrate things better with systemd, but that's strictly optional, and usually trivial and far far far from the word "rewriting".
And note that our compatibility with SysV goes quite far, and where it ends we have documented this pretty comprehensively:
http://www.freedesktop.org/wiki/Software/systemd/Incompat...
Please be aware that when we deviate from SysV we generally do that for good reasons, and to make things easy we document the incompatibilities. We really try our best to design a sane system on one hand but to keep the conversion from SysV as hassle-free as possible on the other. Sometimes these goals contradict. Hence there will be hassles, there's no doubt on that, and we'll not lie about that.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 23:04 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] My concern is that systemd does require a contemporary kernel This seems like a nonsensical criticism. Replacing an init system is a far more intrusive change than updating a kernel. Anyone who's willing and able to rip out SysVinit and replace it with systemd should be more than up to the task of updating their kernel to one with the features needed to support it. Which Linux users are interested in updating to systemd but are holding back because they don't want to update to kernels with cgroup support? It's a doubly ridiculous criticism when aimed at a distribution that provides its own kernels along with the rest of the system. If openSUSE or Fedora decides that systemd is a good idea, it's no problem at all for them to ensure their kernels support its features. They're going to be shipping a contemporary kernel whether they include systemd or not, so the need for a contemporary kernel is not a real-world hindrance to adopting it. The only way this criticism makes any sense is if you don't like the kernel features that systemd depends on and want to compile your kernel without them, or you think it should support other Unix-like systems that lack those features. But if you want to make those points you should make them directly.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 1:00 UTC (Wed) by cowsandmilk (guest, #55475) [Link]
While the primary reason cited for pulling it was to allow developers to focus on 12.1 bug reports, gkh also rightly pointed out on the openSUSE list that Tumbleweed is supposed to be openSUSE with stable updates. The systemd in tumbleweed was not stable. So, it shouldn't be there.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 11:28 UTC (Wed) by whitemice (guest, #3748) [Link]
> While the primary reason cited for pulling it was to allow developers to
> focus on 12.1 bug reports, gkh also rightly pointed out on the openSUSE > list that Tumbleweed is supposed to be openSUSE with stable updates. The > systemd in tumbleweed was not stable. So, it shouldn't be there.
+1
Reasonable decision made; nothing to see here, move along.
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 7:17 UTC (Wed) by quintesse (subscriber, #14569) [Link]
"What I see is a lot of code, a lot of scope creep, a lot of code changes... and these things usually spell disaster"
Weird, in my book they spell "successful project".
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 8:58 UTC (Wed) by dgm (subscriber, #49227) [Link]
I mine they spell "unfinished project".
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 9:30 UTC (Wed) by quintesse (subscriber, #14569) [Link]
And since when is a FLOSS project ever finished??
Tumbleweed backs off on systemd for now Posted Sep 21, 2011 15:47 UTC (Wed) by martinfick (subscriber, #4455) [Link]
I think you just described sysvinit.
Tumbleweed backs off on systemd for now Posted Sep 20, 2011 20:17 UTC (Tue) by jmayer (subscriber, #595) [Link]
While the article mentions the fact that there was discussion whether and with which scope to "publish" this information (apart from the ml post that had already occurred) it does not elaborate the reason why it was done. Tumbleweed tries to provide only "stable" packages. Right now one of the big problems that systemd in Tumbleweed seems to experience is the interaction with other packages (surprise). Updating one without the other may lead to inconsistencies or simply trigger bugs. To make it easier for the developers that are working on getting systemd ready for production use for 12.1 (factory right now) removing it from Tumbleweed allows them to focus on one set (or combination) of packages to debug/stabilize instead of two.
Is that due to a constraint on kernel version/features or safe "upgradibility"? Posted Sep 22, 2011 11:46 UTC (Thu) by herodiade (subscriber, #52755) [Link]
While I'm pretty much eager to get systemd as default from my distribution of choice (Debian, but I'm patient ;), and find the project almost perfect as is, having a good dozen of killer features, almost all compromises (including the lack of support for non-linux platforms) reasonable, and admire Lennart sane attitude and zen facing (sometime) unfair criticisms (when not insults), I don't feel at ease with the lack of support for older linux kernels.
This will imply flag days, dangerous upgrades (where you absolutely have to keep kernel and base userland in sync). And we loose the option to run a modern distros with fresh userland but somewhat older kernel (ie. when some driver or component - say xen, openvz, oracle, ... - isn't supported for newer releases), or want a solidly supported system if you encounter a bug after an upgrade and need to switch back to the previous kernel, ...
And I wonder whether upstream account this difficult as I do (ie. like in https://bugzilla.redhat.com/show_bug.cgi?id=628004#c12 , except the specific cause of this reply was addressed at the end of the day).
More specifically, this requirement on recent kernels is dangerously sliding to very recent versions (will upstream decide upon a definitive "minimal kernel release" ?). See for instance
REQUIREMENTS:
Which means, we probably can't run a really reliable/supported systemd on a 2.6.32 kernel as provided by many stable distributions (?).
Do you know if there's a plan (even for the long term) to polish systemd in this respect?
Is that due to a constraint on kernel version/features or safe "upgradibility"? Posted Sep 22, 2011 16:11 UTC (Thu) by maderik (subscriber, #28840) [Link]
I'm not sure I understand: if your system is that "stable" why do you need/want systemd? You seem to be assuming a newer userland that immediately drops support for sysvinit and yet doesn't have other kernel incompatibilities. As for a long term plan to make systemd compatible with older kernels, wouldn't such a goal likely be obsolete by the time it was achieved?
It's possible that this itch will be scratched by someone -- if in the future there are systems that need both systemd advantages and still run older kernels -- but it seems a lot of effort for that use case w/o a good estimate it's importance.
Is that due to a constraint on kernel version/features or safe "upgradibility"? Posted Sep 22, 2011 17:52 UTC (Thu) by herodiade (subscriber, #52755) [Link]
> if your system is that "stable" why do you need/want systemd?
Well, it may not be that "stable" as you guessed ;). But more concretely, I was thinking mostly about all my difficult upgrades experiences, like "oops, I broke the grub entry for the new kernel" or "oops, nvidia hadn't provided anything yet for the new kernel", "oops, my block driver now require a firmware from an external package", ...
In all cases, being able to boot the previous kernel helps a lot, since my distro doesn't permit "un-upgrading" userland (is that possible on some other distros ?).
As to why upgrading, well, for the desktop it seems obvious (new and maintained releases of, say, firefox, are more important than new kernels I think). For the server, in my case, the upgrades are triggered by developers needing recent versions of php and python, not by a new init system; but on the other hand, I don't expect distributions to provide both systemd and systemd-less upgrades with equal robustness.
> You seem to be assuming a newer userland that immediately drops support for sysvinit and yet doesn't have other kernel incompatibilities.
Not at all, but each new incompatibility makes upgrades a bit more dangerous. Not enough to throw away a valuable tool like systemd though.
I got bitten by udev during system upgrades. I should have (according to my distro upgrade guide, but forgot to) upgraded the userland first, then kernel. I guess in that case the kernel may have missed forward compatibility; but what would happen if, at the same time, the new userland (ie. a systemd daemon) required a newer kernel?
> As for a long term plan to make systemd compatible with older kernels, wouldn't such a goal likely be obsolete by the time it was achieved?
Yes probably. But it could be something like "a new systemd release works on kernels released at least X years before the current systemd release" maybe (ie. to support kernels from the previous release of "enterprise" distributions, and permit smooth upgrades ?). Or just "the kernel 3.X has everything needed for a good init system, so even if we won't test olds kernels in the future, we stop moving dependency on features from newer and newer kernels, [minus oversight/bugs that vendors have to find and fix themselves for their needed versions]". Or (more likely ?) it may happen without formal decision, almost magically, when more users will use systemd ;).
But granted, I have no idea about the trade-off for systemd developers, the difficulties to overcome, and I don't know what makes older (yet cgroups-enabled) kernels hard to support.
Is that due to a constraint on kernel version/features or safe "upgradibility"? Posted Sep 23, 2011 10:49 UTC (Fri) by zuki (subscriber, #41808) [Link] > In all cases, being able to boot the previous kernel helps a lot,> since my distro doesn't permit "un-upgrading" userland (is that possible on some other distros ?). According to your previous comment, you are using debian. Check out e.g. 'apt-get install libc6/squeeze -V'. Sometimes it's a bit of manual labour, but downgrading works.
|
|||||||||||||||||||