Tumbleweed backs off on systemd for now
| From: | Greg KH <gregkh-AT-suse.de> | |
| To: | opensuse-factory-AT-opensuse.org | |
| Subject: | systemd is being removed from Tumbleweed | |
| Date: | Mon, 19 Sep 2011 05:43:18 -0700 | |
| Message-ID: | <20110919124318.GA9013@suse.de> |
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
Posted Sep 20, 2011 14:52 UTC (Tue)
by cjcox (guest, #60378)
[Link] (41 responses)
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.
Posted Sep 20, 2011 15:02 UTC (Tue)
by quintesse (guest, #14569)
[Link] (6 responses)
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 ;)
Posted Sep 21, 2011 6:50 UTC (Wed)
by dsommers (subscriber, #55274)
[Link]
Unless that H is for Honest ...
Posted Sep 21, 2011 8:38 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (4 responses)
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.
Posted Sep 21, 2011 11:06 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (2 responses)
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...
Posted Sep 21, 2011 13:08 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
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.
Posted Sep 21, 2011 14:33 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
> and the system it tries to replace, even with all his warts, is solid and well understood.
Posted Sep 20, 2011 15:04 UTC (Tue)
by Alterego (guest, #55989)
[Link] (2 responses)
But "people" are often reluctant to change, and hide behind various pseudo-excuses, this may be the most difficult part for systemd.
Posted Sep 20, 2011 17:05 UTC (Tue)
by imitev (guest, #60045)
[Link] (1 responses)
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
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.
Posted Sep 20, 2011 16:15 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (12 responses)
Posted Sep 20, 2011 16:17 UTC (Tue)
by corbet (editor, #1)
[Link] (11 responses)
Thanks.
Posted Sep 20, 2011 16:26 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (10 responses)
Posted Sep 20, 2011 16:29 UTC (Tue)
by rvfh (guest, #31018)
[Link]
Posted Sep 20, 2011 16:29 UTC (Tue)
by corbet (editor, #1)
[Link] (8 responses)
Posted Sep 20, 2011 16:43 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (7 responses)
Posted Sep 20, 2011 16:55 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Sep 20, 2011 17:10 UTC (Tue)
by JamesErik (subscriber, #17417)
[Link]
Posted Sep 20, 2011 17:35 UTC (Tue)
by welinder (guest, #4699)
[Link] (4 responses)
Posted Sep 20, 2011 17:45 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Sep 20, 2011 18:13 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Sep 20, 2011 20:29 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Sep 21, 2011 7:31 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Sep 20, 2011 16:21 UTC (Tue)
by dashesy (guest, #74652)
[Link] (9 responses)
Posted Sep 20, 2011 16:52 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (8 responses)
There is an observable downside in terms of system performance with the use of many virtual filesystem mounts like tmpfs and cgroup mounts?
-jef
Posted Sep 20, 2011 17:15 UTC (Tue)
by imitev (guest, #60045)
[Link] (7 responses)
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...
Posted Sep 20, 2011 17:43 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
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
Posted Sep 20, 2011 17:44 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (4 responses)
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.
Posted Sep 20, 2011 19:19 UTC (Tue)
by imitev (guest, #60045)
[Link] (2 responses)
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...]
Posted Sep 20, 2011 19:27 UTC (Tue)
by imitev (guest, #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)
Posted Sep 21, 2011 15:32 UTC (Wed)
by tzafrir (subscriber, #11501)
[Link]
Posted Sep 22, 2011 3:13 UTC (Thu)
by jcm (subscriber, #18262)
[Link]
Posted Sep 20, 2011 19:16 UTC (Tue)
by juergbi (subscriber, #76126)
[Link]
Posted Sep 20, 2011 16:28 UTC (Tue)
by rvfh (guest, #31018)
[Link]
> [...] the overall design is bad IMHO.
Posted Sep 20, 2011 18:28 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (6 responses)
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.
Posted Sep 21, 2011 11:25 UTC (Wed)
by whitemice (guest, #3748)
[Link] (5 responses)
> 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.
Posted Sep 22, 2011 6:33 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (4 responses)
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.
Posted Sep 23, 2011 18:21 UTC (Fri)
by nevets (subscriber, #11875)
[Link] (3 responses)
Two years ago, my desktop sound worked out of the box. Today? Not so much.
Posted Sep 23, 2011 18:37 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
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
Posted Sep 23, 2011 21:58 UTC (Fri)
by nevets (subscriber, #11875)
[Link] (1 responses)
Posted Sep 23, 2011 22:35 UTC (Fri)
by sfeam (subscriber, #2841)
[Link]
Posted Sep 20, 2011 16:52 UTC (Tue)
by jonabbey (guest, #2736)
[Link]
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.
Posted Sep 20, 2011 18:33 UTC (Tue)
by cjcox (guest, #60378)
[Link] (16 responses)
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).
Posted Sep 20, 2011 19:11 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (7 responses)
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.
Posted Sep 20, 2011 20:09 UTC (Tue)
by jonabbey (guest, #2736)
[Link]
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.
Posted Sep 21, 2011 9:05 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (3 responses)
I'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.
Posted Sep 21, 2011 13:32 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Sep 21, 2011 17:22 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted Sep 21, 2011 17:44 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted Sep 21, 2011 14:27 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Sep 22, 2011 2:05 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
/me runs for cover...
Posted Sep 20, 2011 19:24 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link]
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.
Posted Sep 20, 2011 23:04 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link]
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.
Posted Sep 21, 2011 1:00 UTC (Wed)
by cowsandmilk (guest, #55475)
[Link] (1 responses)
Posted Sep 21, 2011 11:28 UTC (Wed)
by whitemice (guest, #3748)
[Link]
+1
Reasonable decision made; nothing to see here, move along.
Posted Sep 21, 2011 7:17 UTC (Wed)
by quintesse (guest, #14569)
[Link] (3 responses)
Weird, in my book they spell "successful project".
Posted Sep 21, 2011 8:58 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
Posted Sep 21, 2011 9:30 UTC (Wed)
by quintesse (guest, #14569)
[Link]
Posted Sep 21, 2011 15:47 UTC (Wed)
by martinfick (subscriber, #4455)
[Link]
Posted Sep 20, 2011 20:17 UTC (Tue)
by jmayer (guest, #595)
[Link]
Posted Sep 22, 2011 11:46 UTC (Thu)
by herodiade (guest, #52755)
[Link] (3 responses)
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?
Posted Sep 22, 2011 16:11 UTC (Thu)
by maderik (guest, #28840)
[Link] (2 responses)
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.
Posted Sep 22, 2011 17:52 UTC (Thu)
by herodiade (guest, #52755)
[Link] (1 responses)
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.
Posted Sep 23, 2011 10:49 UTC (Fri)
by zuki (subscriber, #41808)
[Link]
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.
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
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".
Yeah right, except that it isn't.
Quoting from http://lwn.net/Comments/459725/ :
> 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.
Systemd is fine on Fedora 15
Systemd is fine on Fedora 15
Systemd is fine on Fedora 15
Tumbleweed backs off on systemd for now
Then please either do so or shut the fuck up trolling.
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...?
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
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
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
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
That "#1" might be a hint.
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
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
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
f15: 38
Tumbleweed backs off on systemd for now
http://readlist.com/lists/vger.kernel.org/linux-kernel/25...
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
And then: hmm, no match, did I make a mistake with the regex ? In which case it's safer to use grep -v '\(/sys\|systemd\|tmpfs\|mqueue\|hugetlbfs\)' but you'll agree it's not so convenient when you forgot to set it as an alias or you're too lazy to hack/deploy a little filtering script.
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
You _do_ realise that it is going into 12.1 don' t you? And thus it is being _temporarily_ removed from Tumbleweed.
Would you care to explain what makes you say that?
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
> 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.
Tumbleweed backs off on systemd for now
Two years ago? Not so much.
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
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.
pulseaudio digression [Tumbleweed backs off on systemd for now]
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Please enumerate what things were possible with sysvinit and can't be done today. Then explain when you would use each of them
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
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
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
My concern is that systemd does require a contemporary kernel
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
> 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
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Tumbleweed backs off on systemd for now
Is that due to a constraint on kernel version/features or safe "upgradibility"?
I'm not sure if this change in OpenSUSE is related to those constraints on kernel versions ?
http://cgit.freedesktop.org/systemd/commit/?id=a63599edcc... :
- Linux kernel >= 2.6.30 (with devtmpfs, cgroups; optional but strongly recommended: autofs4, ipv6)
+ Linux kernel >= 2.6.39 (with devtmpfs, cgroups; optional but strongly recommended: autofs4, ipv6)
Is that due to a constraint on kernel version/features or safe "upgradibility"?
Is that due to a constraint on kernel version/features or safe "upgradibility"?
> In all cases, being able to boot the previous kernel helps a lot, Is that due to a constraint on kernel version/features or safe "upgradibility"?
> since my distro doesn't permit "un-upgrading" userland (is that possible on some other distros ?).