Weekly Edition
Return to the Front page
| |||||||||||||
Systemd and Fedora 14Systemd, an alternative to Upstart or System V init, has made big strides since it was announced at the end of April. It has been packaged for Fedora and openSUSE, and for users of Fedora Rawhide, it gets installed as the default. There are still bugs to be shaken out, of course, and that work is proceeding, especially in the context of Rawhide. The big question is whether Fedora makes the leap to use systemd as the init system for Fedora 14. When last we looked in on systemd, Lennart Poettering intended to have a package ready for Fedora 14, which has happened, but it was unclear what, exactly, openSUSE's plans were. Since then, Kay Sievers, who worked with Poettering on developing systemd, has created an openSUSE Factory—essentially the equivalent of Fedora's Rawhide—package along with web page of instructions for interested users. But most of the action seems to be going on in Fedora-land. The Rawhide package gets installed in parallel with the existing Upstart daemon, so users can switch back and forth. That's important because of some glitches in the systemd installation that require users who upgrade from earlier Rawhides to manually enable certain services and targets:
# systemctl enable getty@.service prefdm.service getty.target \
rc-local.service remote-fs.target graphical.target
(The last "graphical.target" entry comes from a second message and will resolve the common
"Failed to load configuration for default.target" problem).
The magic incantation to switch between the two is detailed in a fedora-devel posting announcing that systemd was made the default in Rawhide near the end of July. The kernel command line init parameter can be used to choose either systemd (init=/bin/systemd) or Upstart (init=/sbin/upstart); as Poettering points out: "note the /sbin vs. /bin!" There are various other problems being reported on fedora-devel as well, from the network not coming up automatically to shutdown behaving strangely. The fixes are generally straightforward, for the network it is a simple matter of doing: # systemctl enable NetworkManager.service # systemctl start NetworkManager.serviceand the shutdown problem was addressed by Poettering in the systemd git repository within a few days of the report. While he was congratulated for his quick response on the shutdown problem, Poettering's responses on other systemd breakage has caused some consternation among other Fedora developers. In particular, a dubious interpretation of the "noauto" mount option in /etc/fstab caused numerous complaints. Essentially, that option is meant to tell the system that the filesystem should never be mounted except by an explicit action of the user. But the systemd developers decided that "noauto" just means that the boot shouldn't wait for the filesystem to be mounted, but will still proceed to mount them if present at boot time or plugged in later. Poettering has changed systemd so that its "noauto" behavior matches expectations—and the documented semantics—but some of his responses rubbed folks the wrong way. Worse, though, is the concern that Fedora will be making a big mistake by adopting systemd now, instead of making it optional for Fedora 14 and then the default in Fedora 15 if all is well. Matthew Miller voiced his concerns:
[...] When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".
So, my question is serious. If we go ahead with systemd for F14, will we be hit with an onslaught of confusion, trouble, and change? That would be good for testing systemd, but *not awesome* for the distribution or for its users. Or, on the other hand, is it a matter of a few kinks which we can get solved before release? Poettering is characteristically optimistic in response: "Quite frankly I'd draw a completely different conclusion of the current state of affairs: everything is looking pretty great." He goes on to note that any issues reported have been quickly fixed, and that the number of bugs has actually been fairly small:
That all said if you have a look on the number and quality of open bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base system. It's
definitely not a good metric, but I do believe if that even if the
number increases to a healthy level comparable with other core packages
we'd still be fine.
So, [breathe] deeply, and let's all be jolly! He has also started a series of blog posts to help administrators become familiar with systemd and to ease their transition. But his overall approach sometimes come under question. At least partially because of the way he handled PulseAudio complaints, Poettering has something of a reputation for waving away bugs as features, which tends to irk some. Miller puts it this way: "The pattern I see is that each time, you respond initially with (paraphrased) 'It's not broken -- we've made it better!' before implementing the fix." The thread went on for quite a ways, even by fedora-devel standards, but the crux of the issue seems to be that there are worries that major changes that break things are chasing Fedora users away and a switch to systemd may be just that kind of change. There is no hard evidence of that, but it is clearly a fairly widespread—though not universal—belief. To try to escape the flames and assist with moving the decision about using systemd as the default in Fedora 14 to a technical, rather than emotional, basis, Bill Nottingham started a thread about acceptance criteria for systemd: "From [reading] the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified." As might be guessed, the flames didn't completely subside but the focus did shift to technical considerations, with an emphasis on backward compatibility to existing Upstart—and earlier System V init—functionality. There are lots of moving parts that go into making the transition from Upstart (which is mostly run in sysvinit compatibility mode in Fedora currently) to systemd, however, and Poettering is feeling like he is getting saddled with fixing any and all problems, even those that are legitimately outside of systemd. There is a difference between what the Fedora and systemd projects need to do, though. As pointed out by several people, Fedora needs to ensure that the system works well, regardless of where the problem lies. As Nottingham notes, there is a higher burden on the person pushing a major change, but the distribution as a whole needs to get it right:
It's about the integration into the system. Playing a blame game doesn't
help... if the system doesn't work, we can't ship that way. If there are enough
blockers in other packages that prevent a systemd system from functioning to
these sorts of specifications, we cannot ship systemd. Period.
The onus is on the introducer of a large change to make sure that change works in the system. Sure, we can fire up requests for help, we can lean on people to fix their packages, and we've got people who are willing to help. As he surely recognizes, Poettering's best strategy is to fix any bugs found in systemd and any other component where he has time and enough understanding to do so. Enlisting aid for any that he, or other systemd developers, can't address seems appropriate as well. There is no one in Fedora that can wave a magic wand and force developers to work on specific tasks, so some amount of team building may be necessary. There is always a hump to get over between the development and deployment of a new feature, and the hump in this case is larger than many. That said, none of the remaining issues looks so daunting that they cannot possibly be overcome in the next few weeks. The Fedora 14 schedule shows a "Beta Change Deadline" on September 14. On or before that date, there will undoubtedly be a "go or no go" decision made on systemd for Fedora 14. Between now and then, testing systemd, reporting bugs, and perhaps more importantly, pitching in to fix bugs are all things that systemd fans can do to push it forward. Otherwise, we may have to wait until Fedora 15 to really see what systemd can do. (Log in to post comments)
Systemd and Fedora 14 Posted Aug 25, 2010 20:53 UTC (Wed) by mattdm (subscriber, #18) [Link]
This article uses the word "flames" several times. I don't think that's a fair characterization of the discussion, which stayed largely focused on the technical.
Systemd and Fedora 14 Posted Aug 25, 2010 21:09 UTC (Wed) by fuhchee (subscriber, #40059) [Link]
"flame" has unfortunately become a muddled term, where any extended debate is thusly labeled. Back in the good old days, it referred to those moments where the intensity of emotion flashes over and wishes to burn opposing personalities to a crispy little biscuit.
There are not actually many flames out there these days; more's the pity. A creative flame is a sight to behold.
Systemd and Fedora 14 Posted Aug 25, 2010 21:47 UTC (Wed) by AlexHudson (guest, #41828) [Link]
The issues raised were technical but I don't think it's unfair to characterise the discussion as flame-y. It would have been possible to discuss the same issues in a far less heated manner.
Systemd and Fedora 14 Posted Aug 25, 2010 20:56 UTC (Wed) by busterb (subscriber, #560) [Link]
Was there an article explaining why systemd exists, rather than improving upstream projects like upstart or launchd, fixing their perceived deficiencies? I was surprised to see Fedora already included upstart, which makes this confusing still. Is this similar to the way Ubuntu is perceived with it's working with Gnome and its own component replacement projects? Meaning, is this just a product differentiator, or something the world really needs?
read this for background Posted Aug 25, 2010 21:00 UTC (Wed) by mattdm (subscriber, #18) [Link] Was there an article explaining why systemd exists, rather than improving upstream projects like upstart or launchd, fixing their perceived deficiencies? Yes there was, at least from the developers' point of view. See: Rethinking PID 1.
read this for background Posted Aug 25, 2010 21:14 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
And more recently there was a linuxoutlaws podcast (episode 160) with an audio interview with Lennart, while not as detailed as the original article explaining the rationale is still useful to listen to for context.
-jef
Systemd and Fedora 14 Posted Aug 25, 2010 22:27 UTC (Wed) by drag (subscriber, #31333) [Link]
It seems to me to be a cleaner design and takes advantage of existing kernel features to make things smoother.
If I understand things correctly....
Both upstart and system are aiming to provide managed, dependency-based Init.
Upstart = Developer maps out what services they _require_ activated prior to having their software launched.
System = Developers maps out what services they _provide_ prior to having their software launched.
The difference is that with daemon author in System needs only register the sockets they provide. At bootup time Systemd register those sockets with the kernel and then when your sockets are accessed it launches the daemon.
Very much like a inetd, but for system services.
In practice this means that during bootup all the required system services are launched simultaneously. Your daemon's sockets get touched at some point, which launches your daemon, which means your daemon touches the sockets of the services it needs, which launch those daemons... etc etc.
---------------------------
For desktop users it will probably seem much faster then upstart. Since with upstart has to start all system services that the user MIGHT need prior to the user logging in. While with upstart daemons are only started if they actually end up getting used AFTER the user has logged in.
Systemd and Fedora 14 Posted Aug 26, 2010 7:12 UTC (Thu) by pontus (subscriber, #3701) [Link]
From your description it sounds like desktop users will get the Windows-like behaviour where they can log in quickly and the desktop shows, but then the system is unusable for a long time because various services keep spawning in the background...
Systemd and Fedora 14 Posted Aug 26, 2010 7:32 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Socket activation is not going to be used extensively afaik especially if the daemons in question take a long time to initiate. People get all excited about it but other details are more significant.
Systemd and Fedora 14 Posted Aug 26, 2010 7:43 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]
_Might_ happen that way, it depends on what services you're bringing up. With SystemD, all services come up as quickly as possible, so if X, GDM and friends have few dependencies and are quick to start, then the login prompt will often come up long before the slower services are finished starting up.
If I'm not misinformed, Windows is designed to prioritize bringing up the GUI before system services, and there are no such plans that I know of for SystemD, though it would certainly be possible to do so using plain old nice values.
Systemd test day Posted Aug 25, 2010 20:58 UTC (Wed) by mattdm (subscriber, #18) [Link] I'm sure at this point you're all jumping and up and down and saying "Wow, init subsystem replacements are thrilling! And there's nothing I love more than a long, drawn-out technical back-and-forth. But how can I get involved?" Well, there is a Fedora Test Day on September 9th, dedicated to systemd. See this page for details. And joking aside, please help out, because systemd has the potential to be really cool, but we need to know where we stand based on real testing.
Systemd test day Posted Sep 5, 2010 16:15 UTC (Sun) by AdamW (guest, #48457) [Link]
Thanks for the plug, but note the Test Day has now been rescheduled to September 7th - this coming Tuesday - so we can use the results in deciding whether to go ahead with systemd for the beta and final releases. The page is now at https://fedoraproject.org/wiki/Test_Day:2010-09-07_Systemd
Systemd and Fedora 14 Posted Aug 25, 2010 23:03 UTC (Wed) by marcH (guest, #57642) [Link]
> Worse, though, is the concern that Fedora will be making a big mistake by adopting systemd now, instead of making it optional for Fedora 14 and then the default in Fedora 15 if all is well.
Why take chances and go straight from "does not exist" to "used by default", entirely skipping the very useful "optional" step?
systemd looks soooo cool that the world cannot even wait 6 months to have it... as the default?!
Or maybe Fedora is now only interested in becoming a testbed for other, more patient distributions.
Systemd and Fedora 14 Posted Aug 26, 2010 4:12 UTC (Thu) by njs (guest, #40338) [Link]
It's optional right now -- if you want it, you can download a Fedora pre-release for testing. (Even then, it's optional, see the article.) But there's no merit in keeping things optional for long periods "just because" -- if it's good enough to become the default now, then it should, otherwise, it shouldn't, and that's what they're trying to figure out.
> Or maybe Fedora is now only interested in becoming a testbed for other, more patient distributions.
But there's also an argument that this has been true of Fedora for a while. (And it's a fantastically valuable service they provide us all, too!)
Systemd and Fedora 14 Posted Aug 26, 2010 9:49 UTC (Thu) by marcH (guest, #57642) [Link]
> But there's no merit in keeping things optional for long periods
Sorry but a period that does not even include one single full release is not "long" by any reasonable testing standard.
It would be interesting to compare the number of users of pre-releases with full releases. The download stats of any mirror should be able to provide some idea.
Too many developers seem to confuse "release early, release often" with "if it ain't broken, replace it with my brand new stuff anyway". The difference is *testing* (something no one ever wants to do). The latter is a convenient way for too impatient developers to force their admittedly great but *poorly tested* stuff down everyone's throat sooner than later.
I think it is a very reasonable request to ask for a single full release where systemd is available to try, but not just the default.
> > Or maybe Fedora is now only interested in becoming a testbed for other, more patient distributions.
> But there's also an argument that this has been true of Fedora for a while.
Ah, that explains everything then.
Systemd and Fedora 14 Posted Aug 26, 2010 10:41 UTC (Thu) by mpr22 (subscriber, #60784) [Link]
I have one intuition about those numbers (for the record: "not many" and "probably even fewer"). You may well have another.
Systemd and Fedora 14 Posted Aug 26, 2010 13:45 UTC (Thu) by marcH (guest, #57642) [Link]
> How many people who wouldn't try out a prerelease distro to test an experimental system initialization manager would choose the option to use the optional experimental system initialization manager in a released distro [...] ?
Comparing the times respectively required will guide you towards the answer.
> How many of those people would, having found the optional experimental system initialization manager to be buggy in Release N, try it out again in Release N+1?
They would try it again simply because in N+1 it would have become the default. I am not suggesting to drag things forever either; it's all about finding the right balance.
Systemd and Fedora 14 Posted Aug 26, 2010 15:13 UTC (Thu) by vonbrand (subscriber, #4458) [Link] If it is shipped experimental and broken in N, it won't be the default in N + 1. It might even not be in N + 1 at all. End of story. BTW, there are experimental packages of systemd at least for OpenSUSE out, and some other distributions are considering it. To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others). Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time. And that is bad for developer morale (and focus), and probably damages the whole effort.
Systemd and Fedora 14 Posted Aug 26, 2010 20:04 UTC (Thu) by marcH (guest, #57642) [Link]
> If it is shipped experimental and broken in N, it won't be the default in N + 1.
Sorry but I totally miss the logic here.
And the solution to such a sample (and irrelevant?) situation would be to fast-track this supposedly broken piece of software? In other words, to burn the bridges?
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Yes this is all about the balance between the vast majority of Fedora users, happy with a system that already works fine thank you very much, versus a few admittedly brilliant developers overexcited about a new fancy project.
Systemd and Fedora 14 Posted Aug 26, 2010 21:03 UTC (Thu) by vonbrand (subscriber, #4458) [Link] This is not "already works fine, thank you" but "works so-so with massive effort and tweaking, and won't survive the next round of hardware/software updates". Fedora isn't running SysVinit anymore, and upstart is clearly lacking (it is being used only as a SysVinit replacement). A rethink of the whole mess is mandatory (not least because you can't separate system vs user setup anymore for increasingly broader end user control over the machine). This is a concrete proposal to do so, and it mostly works today (with surprisinly little futzing around in daemons), and which has been greeted with enthusiasm by other distros (best example is that it is being considered by them, and experimental packages exist). Will it hurt? Yes. Will it be worth it? I believe so.
Systemd and Fedora 14 Posted Aug 28, 2010 0:12 UTC (Sat) by Blaisorblade (guest, #25465) [Link]
> To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others).
Hey, it's cool, but until the bug stream doesn't slow down, there's no chance that you can include it in a distribution. Not even in one as crappy as Fedora. We've suffered this style ever since RH 9's (IIRC) backport of NPTL.
> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
Yes, at some point there won't be new bugs reported. Then it means you can end the beta-test phase, set up more stress-testing, get more packages to work with it, ship it, and fix the tons of bugs reports.
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Hey, that's crap. If developers can't wait six months to replace the core component of a system, they should be fired. Now. Because they wouldn't be able to deal with much harder problems. I guess it does not matter, because it's just your idea.
Finally, reading one of the original Nottingham's comments linked from the article [2] is enlightening. He's teaching release management to Poettering. Which means that I don't trust him to care for a distribution. Sure, he's a great and brilliant developer, able to think different, but those guys are not good for ensuring stability.
[1] http://lwn.net/Articles/401901/
Systemd and Fedora 14 Posted Sep 2, 2010 8:29 UTC (Thu) by renox (subscriber, #23785) [Link]
>> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
> That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Depends on the distribution!
"Leading the advancement of [cut] software" are nice "marketing" word for "bleeding edge", what is right for a distribution aimed at "non-technical users" or enterprise isn't necessarily right for a "bleeding edge" distribution..
Note that I'm not saying this as a criticism against Fedora, we need "bleeding edge" distributions to make rapid progress, and I applaud them to take (calculated) risks.
Systemd and Fedora 14 Posted Aug 26, 2010 4:27 UTC (Thu) by charris (subscriber, #13263) [Link]
Driving users away is certainly a possibility. I was a pretty exclusive user of Redhat, then Fedora, but three difficult releases in a row - 10, 11, 12 - finally drove me to Ubuntu. Goddard was an improvement but the mouse would hang after a while. Who needs a problem like that these days? I might end up back in Fedora at some point, but after getting Ubuntu set up I just don't have the motivation to make the switch anytime soon.
Systemd and Fedora 14 Posted Aug 26, 2010 8:42 UTC (Thu) by elanthis (guest, #6227) [Link]
In terms of anecdotal stories, Ubuntu releases after the initial Warty were (for me) plagued with an ever increasing number of bugs. I eventually switched to Fedora and haven't looked back.
All the distros are pushing massive changes at a possibly-too-quick state. Ubuntu fostered Upstart on us pretty damn quickly, for instance. The take away is that Linux as an OS still has a long way to go before it's remotely stable or user friendly.
Systemd and Fedora 14 Posted Aug 26, 2010 15:19 UTC (Thu) by vonbrand (subscriber, #4458) [Link] If you want "stable" and "user friendly", go for one of the enterprisey distributions, like RHEL or SLES, or even CentOS. But then don't complain that the software is old and lacking glitz and newest bling.
Systemd and Fedora 14 Posted Aug 27, 2010 17:48 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
Not all distros change quicky. This is where Debian's turtle-like pace shines. It's already too late to put systemd in the next stable and by the time that the one after that comes along systemd will be mature and accepted or well-debunked by faster moving distros.
Systemd and Fedora 14 Posted Aug 26, 2010 0:24 UTC (Thu) by professor (subscriber, #63325) [Link]
I think Systemd is the right way to go.. I do however feel bad for the person(s) that need to implement it because of this flame (yes, i think this is a flame). How would anyone expect anything to happen during the night? The common mentality amongst mankind is to shoot down whatever that comes in _their_ way to a system that already work the way _they_ think is totally fine.
The best thing is for people to start using it and (like some have already mentioned) be able to switch back to the "good old fashion" way when it does not work. The issue with this is however that once something is buggy, people tend to always think is buggy.
Systemd and Fedora 14 Posted Aug 26, 2010 1:42 UTC (Thu) by ncm (subscriber, #165) [Link]
Is there a list anywhere of names like "getty@.service" and "graphical.target"? Are those just files installed by various packages?
I've read or skimmed all the explanatory material and haven't encountered an explanation for the all-fired hurry to make this the universal startup method for all Fedora systems, as opposed to spending one release cycle as an option for the daring. There might be a reason, though, and I'd like to read it here.
Systemd and Fedora 14 Posted Aug 26, 2010 4:16 UTC (Thu) by njs (guest, #40338) [Link]
IIRC one of Lennart's recent blog posts, I believe that yes, each "systemd unit" (is that the right term?) is named after the configuration file that defines it.
Systemd and Fedora 14 Posted Aug 26, 2010 7:50 UTC (Thu) by ncm (subscriber, #165) [Link]
Thanks, nj.
But the question remains, what's the rush? Why does systemd have to be the default in F14 when it hasn't been properly hammered out yet in production? Anybody?
Systemd and Fedora 14 Posted Aug 26, 2010 8:01 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
The decision on whether systemd will be in Fedora 14 has not been made yet. What is in the branch and Rawhide is being done to evaluate the feasibility of it and iron out any potential bugs. There is also a explicit test day
https://fedoraproject.org/wiki/Test_Day:2010-09-09_Systemd
Upstart is even installed along with systemd as a dependency to provide a easy fallback and Fedora will make that decision before final change deadline
http://fedoraproject.org/wiki/Releases/14/Schedule
Bill Nottingham's list was to provide a objective criteria on which to make the decision.
Systemd and Fedora 14 Posted Aug 26, 2010 18:56 UTC (Thu) by mattdm (subscriber, #18) [Link] Is there a list anywhere of names like "getty@.service" and "graphical.target"? Are those just files installed by various packages? systemctl list-units --type=target --all But only a few of those are actually useful to switch to as the equivalent of a runlevel. Stay tuned -- I'm working on making this better. I hope. The idea is that will be a setting that a given target can have marking it as "runlevel-like", and then the systemctl tool can list, set as default, and switch-to those targets. See https://bugzilla.redhat.com/show_bug.cgi?id=627277. Patches, comments, and testing welcome.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 5:14 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]
Dunno, I have a couple of observations....
First off, since Mr. A**hat's last great 'innovation' (solution to a problem few have) has had audio on Fedora broken for several YEARS now and shows no signs of getting fixed any time soon, wouldn't his "What me worry?" attitude be better received if he could have bothered to finish PulseAudio before moving on to breaking an even more fundamental subsystem?
With only a trivial effort one can still find a dozen less popular apps both in and out of the Fedora repos that Pulse breaks. It wasn't too long ago that FlashPlayer was hit or miss. Because Fedora has embraced it so hard removing it breaks most of the desktop so there isn't a solution. Classic no win scenario. All because Fedora realized that forcing users to run Pulse was the only way anyone would ever run it. Seriously, if the core packages still supported ALSA nuking Pulse would be as routine as nuking SE-Linux after the first couple of kaboom! events. No brainer, no benefit to keeping it because it provides zero benefit for 99% of users.
Systemd might just be the greatest thing since sliced bread. I read the article and still can't decide if I like the theory or not. But the number one objection is that it sounds too good to be true in that it will work great... if every last obscure package gets with the program.
Been there and got the T-Shirt, this is Pulseaudio all over again. Since it is useless to a user, if it can be disabled it will so Fedora will either abandon it or force it by dropping upstart and sysvinit.
Every package will still be maintaining support for traditional startup because other distros (and *BSD, OpenSolaris, etc) will be sticking to UNIX ways. Any package where the core devels aren't on Systemd the support for it will either be an afterthought or a contrib package from outside, probably from an @redhat.com address. Not a recipe for the sort of 100% buyin this totally different init scheme requires.
There is one certainty if history is any guide, implementing this thing will cause years of lossage and the only sensible question is whether the pain will balance the gain. Beautiful theories don't exist in a vacuum, lots of real users and admins are going to have to expend a non-trivial amount of effort just relearning. That assumes it works flawlessly. It won't.
Which brings me to the final question, one I have asked relating to all of this New Tech. UNIX is well documented. Will this ship with quality documentation? Because if it doesn't the history of the rest of the New Tech indicates it never will be documented because the professional publishers have stopped trying to keep up with the warp speed replacement and re-replacement of the core tech in Linux. So when it breaks, and it will, figuring out what broke and how to patch it is going to be a nightmare of highly complex and poorly documented software. Say what you will about the wisdom of a nest of shell script but SysV Init can be understood in under an hour by anyone halfway Unix literate.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 5:57 UTC (Thu) by tajyrink (subscriber, #2750) [Link]
Indeed a bit flamy, but it's reasonable. I think the attitude in general is that Pulseaudio isn't broken, everything else is. Will it be the same with systemd? Not really broken, it's just that the applications are...
And yes, I still have worse audio user experience with Pulseaudio than what I had before it. And I'm not even using Adobe Flash, but just watching movies (with pass-through audio via digital coaxial out) and playing some games. I've figured out some workarounds by googling, but not all. For example Frets on Fire I can't play properly on a 64-bit computer without Pulseaudio uninstalled (visual hickups caused by Pulseaudio audio chain strain eyes, yes there is a bug open).
Some questions that do 3d6 fire damage Posted Aug 26, 2010 6:00 UTC (Thu) by Hknr (guest, #67789) [Link]
Amen brother, another project from a man that tries to solve
problems where there aren't any and breaks everything along the way. I wouldn't touch this crap with a ten foot pole.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 7:37 UTC (Thu) by mbaldessari (guest, #36769) [Link]
"another project from a man that tries to solve
problems where there aren't any". This is probably one of the most clueless comments I've read around here. Audio in Linux needed fixing and albeit PulseAudio has had it quirks, it works much better now, and it went a *long* way at improving the ridiculous audio situation we had before.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 7:57 UTC (Thu) by Hknr (guest, #67789) [Link]
Thank you.
I'll give you an example: I use an external USB-DAC that directly feeds into my amplifier. With a little bit of asound.conf tweaking, I get bit-perfect output from my flac music collection (and even crossfeed support when I use my headphones). So why would I want to add a shitlayer on top of that?
Some questions that do 3d6 fire damage Posted Aug 26, 2010 11:11 UTC (Thu) by Los__D (guest, #15263) [Link]
Wow... You "only" need to mess with some obscure configuration file to make stuff work! Everything is perfect then!
Some questions that do 3d6 fire damage Posted Aug 26, 2010 11:26 UTC (Thu) by Hknr (guest, #67789) [Link]
Messing with configuration files to make stuff work
is exactly the way we like it in Linux land.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 11:35 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Speak for yourself. I rather have stuff work without messing around with configuration files in my Linux land. Busy work makes no sense to me.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 12:52 UTC (Thu) by nicooo (guest, #69134) [Link]
With alsa you don't need to edit any files for a regular setup. If you want to do something out of the ordinary, using a config file is easier than some complicated gui.
Systemd gets it right by using ini instead of the xml that everything else hosted on freedesktop.org seems to use.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 12:18 UTC (Thu) by mpr22 (subscriber, #60784) [Link] My attitude to hand-editing configuration files is simple:
The system should provide tools to make most-or-all commonplace configuration actions, and many less commonplace ones, achievable without using a text editor. If using a text editor to configure the system is necessary, at least one of the following statements is true:
Some questions that do 3d6 fire damage Posted Aug 27, 2010 1:20 UTC (Fri) by drag (subscriber, #31333) [Link]
The other main argument is that hardware is now dynamic.
Here is very common hardware:
Notice how they are all dynamic?
So yeah. Alsa, by itself, can work really well if all you want to do is listen to Flac files over a static configuration... but it's shit if you want to do anything more complicated like:
* play more then one sound simultaneously (I'd like to see you program into your asoundrc file a audio mixer that does not suck)
And a bunch of other crap people using other OSes take for granted but is nearly impossible to do in Linux with any sort of sanity and when it does works it only works in extremely static and carefully maintained configuration.
And, no, switching to OSS is not going to help any since OSS, even in the newest versions, is less capable and more of a pain in the ass to configure then Alsa is... OH it uses software mixing by default, unlike ancient versions of Alsa. One problem solved and sixty thousand more to go.
Some questions that do 3d6 fire damage Posted Sep 6, 2010 16:41 UTC (Mon) by nye (guest, #51576) [Link]
I'm sure those things would be lovely, if there was more than 50% chance that the piece of shit would produce any fucking sound at all.
Some questions that do 3d6 fire damage Posted Sep 6, 2010 17:10 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
I am sure there is 98.7 % chance of sound. Much better than ALSA's 76.5% :-)
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:20 UTC (Thu) by nix (subscriber, #2304) [Link]
And just how much documentation is there for asound.conf? Sod all useful that I can find, that's how much. There's even a Lisp interpreter in there somewhere, although I'm not sure where. I suspect I'll have to grovel through the source code to figure out the syntax, and life is just too damn short.
I googled for a stanza to force everything through PulseAudio (first hit: pulseaudio.org's Perfect Setup page) and left it at that.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:39 UTC (Thu) by sfeam (subscriber, #2841) [Link] And on that Perfect Setup page you will find the following advice:KDE 4 uses Phonon as the main audio interface. The Xine backend of Phonon should eventually use PulseAudio automatically, but at the time of writing the pulse plugin for Xine is too unreliable, so it's disabled by default. While waiting for that to get better, Phonon uses Alsa. Therefore, to get Phonon to use PulseAudio, you have to edit your ~/.asoundrc or /etc/asound.conf. However, the normal .asoundrc modifications aren't enough. See #232 (specifically the workaround part). New progress is being made with KDE 4 and Phonon all the time. Please refer to the KDE wiki page for further information and setup instuctions. ... which matches my experience. Getting PA to work with KDE4 is somewhere on the spectrum from painful to impossible. And it doesn't get you away from dealing with the ALSA configuration.
with pulse, it's silent; without sound works Posted Aug 26, 2010 13:02 UTC (Thu) by sebas (subscriber, #51660) [Link]
That is to say that even after a couple of months of fiddling with all kinds of configuration options and pulseaudio stuff, my sound was still hit and miss.
I much prefer spending a couple of minutes fixing an ALSA setup than
Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.
Lennart's answer, when I inquired personally at a conference, was it's the buggy driver's business. The hardware in question was intel's HDA sound chip, likely the most common piece of sound hardware found in today's laptops.
My experience is as simple as: Without pulse it works, with pulse it doesn't. As much as the previous comments sound like flaming, they do match my experience.
If that's any indication of how problems with systemd are being dealt with, I'll rather not install it.
with pulse, it's silent; without sound works Posted Aug 26, 2010 13:31 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
That it's an Intel HDA tells you nothing - the HDA spec is pretty much just a semi-defined bit of glue in front of a codec, and there's literally dozens of different codecs. Some of these are more spec-compliant than others and it's not uncommon for them to require chip-specific quirks. See source/pci/hda to get some idea of just how much complexity there is in what looks like a single chip.
with pulse, it's silent; without sound works Posted Aug 26, 2010 14:00 UTC (Thu) by sebas (subscriber, #51660) [Link]
Ow, I'm convinced it's rather more complex than I am able to understand -- but that probably goes for the vast majority of the users. The gist is that without pulse it works, and with it, it simply doesn't. And that's also what the user will experience -- a very poor multimedia experience.
with pulse, it's silent; without sound works Posted Aug 26, 2010 14:29 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
When you say "The user", you mean "A user with this specific codec". The majority of hda codecs work absolutely perfectly with pulse at this point, and it's usually not too difficult to fix the others. But the fact remains that this is the kernel failing to compensate for broken hardware, and while it may be reasonable to use this as a reason to say that Pulse shouldn't be the default it's unfair to blame the problem on Pulse itself.
with pulse, it's silent; without sound works Posted Aug 27, 2010 17:12 UTC (Fri) by Trelane (subscriber, #56877) [Link]
It should perhaps also be mentioned that "codec" is a specific bit of jargon specific to the HDA spec (available on the intarwebs; this is how I know about these things, although it's been a while and I'd greatly appreciate supplements/corrections where appropriate).
The HDA spec has a tree structure, and one of the nodes is a "codec," referring to a virtualized interface to a block that Does Stuff. This is used to interesting effect with the sound card discussed at http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/, where the HDA protocol itself is used as a transport/formalization of a higher-level protocol used to drive a particularly novel consumer-level sound card.
IIRC. It's been a bit since I read the specs on this card and therefore also the HDA specs to understand Intel HDA as it was being used here. (Sadly, I never got enough hand-holding to get a driver up and running on ALSA and perhaps also lacked the motivation, not actually having hardware to play/test with.)
with pulse, it's silent; without sound works Posted Aug 27, 2010 9:46 UTC (Fri) by buchanmilne (guest, #42315) [Link] Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*. So, now you aren't sure if it is different (newer/older) snd_hda_intel drivers, or PA. On a distribution (Mandriva) which defaulted to PA, but allows very easy switching to straight ALSA, I found (about a year ago) by switching to ALSA that the problems I had with sound input on my laptop were not due to PA but the snd_hda_intel driver needing some tweaks for my hardware (in 2.6.27). Some point releases of 2.6.27 fixed and subsequently broke it again. In more recent kernels (2.6.31 and later) I haven't had these problems (although the mic did sometimes stop working after suspend, unloading and reloading snd_hda_intel fixed it - but I haven't seen this problem on 2.6.33 or later). Immediately after having isolated the problem as being the driver, I switched back to PA, and really don't have any issues (on 4 machines, including my media player which has 5.1 via SPDIF enabled from the XBMC settings).
My experience is as simple as: Without pulse it works, with pulse it doesn'tNo, technically, your experience was "On one distro it didn't work, on the other it did, the one where it didn't work used PA, the one where it worked didn't", with undefined definitions of "it" and "work", and no clear identification of the cause besides association.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 7:41 UTC (Thu) by xav (subscriber, #18536) [Link]
That's strange, because I find that audio cards setup is now a breeze thanks to pulseaudio (one slider for volume, the rest is auto-guessed) whereas before it was a real mess of alsa pseudo-autoconfiguration which never worked anyway, coupled with googling and alsarc tweaking.
Anyway, for me pulse solved problems and didn't cause any.
But I'm not using Fedora, so I probably didn't have to endure the painful beta versions.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 11:54 UTC (Thu) by paulj (subscriber, #341) [Link]
The way volume auto-guessing works in PA is still majorly broken, particularly with multiple applications. I wish PA had an option to *leave my relative, per-app volumes the fsck alone* - but this is apparently a feature. Sigh.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 12:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Flat volumes? That can be turned off
echo "flat-volumes = no" >> /etc/pulse/daemon.conf
Relogin. Although this is often a hardware specific bug in ALSA and should be reported.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:30 UTC (Thu) by nix (subscriber, #2304) [Link]
There are HDA codecs that are so broken that they can't set their *volume*?
(Do these things get any testing at all? How does Windows do it, and why can't we use the same technique?)
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:39 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:56 UTC (Thu) by Trelane (subscriber, #56877) [Link] http://msdn.microsoft.com/en-us/library/ff536251%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ff536191%28v=VS.85%29.aspx It looks like, as with all shoddy Works-Fine-With-Windows hardware, the answer is one or more of:
Some questions that do 3d6 fire damage Posted Aug 26, 2010 7:48 UTC (Thu) by niner (subscriber, #26151) [Link]
Well, I for one am glad that PulseAudio finally moved Linux audio forward from the stone age it has so long been stuck in.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 16:47 UTC (Thu) by leoc (subscriber, #39773) [Link]
Same here. I think the issue with PulseAudio is that of all change: the people who have no problems don't say anything, while the people who do proclaim far and wide that the world is ending.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 17:42 UTC (Thu) by sfeam (subscriber, #2841) [Link]
"Change" is one thing. "Breaking existing setups without providing an escape route" is a bit different. The problem with PulseAudio is not so much that it doesn't work on all systems as that it's so intimately embedded into the desktop that you can't easily disable it on systems where it doesn't work.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 23:47 UTC (Thu) by bangert (subscriber, #28342) [Link]
the solution to a broken pulseaudio is not too turn it off then, but to fix the issue instead. it appears the problem is not pulseaudio but your audio driver, ie. you are barking up the wrong tree...
the reason why pulseaudio cant use your sound hardware is because it does way more than you ever have. this is the good thing and at the same time the reason why your desktop has started to depend on it so much.
Some questions that do 3d6 fire damage Posted Aug 27, 2010 0:40 UTC (Fri) by sfeam (subscriber, #2841) [Link] In my particular case, I believe I am barking up the right tree:-) The issues I have seen with PA do not involve problems with communication between PA and the hardware, they involve communication between PA and specific application programs (and/or several intervening layers like phonon or gstreamer). Earlier versions also had a recurring habit of chewing up gobs of CPU time for no apparent reason, but thankfully that seems to have been fixed.I can comprehend the viewpoint that these (usually older) applications are obsolete and can be replaced by newer equivalents. But this is exactly the viewpoint that worries me, and I'm clearly not the only one. There had better be some compelling advantage to switching to a new component, be it PA or systemd, to justify the disadvantage of breaking the applications people are currently using. I hasten to add that I have no opinion on systemd yet, but certainly PA fails this test. It's all very well to say that PA "does way more", but that "way more" is stuff that I never wanted in the first place. The capability of doing things I don't want does not compensate for doing a bad job at handling the things I use every day. I'll shut up now, because gripes about PulseAudio are relevant to systemd only to the extent they are examples of what can happen when the goals of the developer diverge from the goals of the end user.
Some questions that do 3d6 fire damage Posted Aug 27, 2010 9:26 UTC (Fri) by bangert (subscriber, #28342) [Link]
is this your argument: do you want all of us to remain in the audio stoneage, because you use programs that are even older than that?
this is insane.
you can't require that lennart (or whoever wants to move things forward) stays backwards compatible with each and every use case in existance. with the amount of code being produced every single day, that would make progress impossible. just as new code is written, old code dies.
and, given most of the code we use is open, you are free to update any left behind component, if you so wish.
man, would i love it if somebody would modernize/update xfig ;-)
Some questions that do 3d6 fire damage Posted Sep 3, 2010 18:21 UTC (Fri) by nix (subscriber, #2304) [Link] you can't require that lennart (or whoever wants to move things forward) stays backwards compatible with each and every use case in existance.The scary thing about pulseaudio is that modulo broken hardware, broken kernels (both alas common), or people doing things that just can't be virtualized in userspace (there are a few such with OSS and they break with aoss too, only ALSA's in-kernel OSS emulation helps), pulseaudio really does support almost everything. If there's a network protocol out there used for sound servers in more than a handful of boxes, PA seems to support it, and it's sufficiently modular that adding more is pretty easy.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:24 UTC (Thu) by ofeeley (guest, #36105) [Link]
PulseAudio has been a boon for me too. I found messing around with sound a complete pain for my simple needs which included occasionally plugging in/out a USB headset for VOIP. Works perfectly on 4 disparate desktops thanks to PulseAudio.
I suspect that the people raging about this are those that have a high level of expertise in audio configuration pre-PulseAudio and are understandably miffed that their investment is somewhat wasted now.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 6:36 UTC (Thu) by michich (subscriber, #17902) [Link]
systemd is compatible with SysV initscripts, so there's no need to convert all packages.
systemd comes with quite a good amount of manpages.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 10:20 UTC (Thu) by mezcalero (guest, #45103) [Link]
We have a complete set of man pages.
Some questions that do 3d6 fire damage Posted Aug 26, 2010 21:33 UTC (Thu) by nix (subscriber, #2304) [Link]
Quite so. That's one complaint I cannot make about anything you've written: unlike virtually all GNOMEish and KDEish stuff, it *has manpages* and they are *readable* and *accurate*.
Would that everyone else took the same care. Just because it's desktoppy and largely invisible doesn't mean it doesn't need docs: on the contrary, it means it needs *more*, because everyone uses it, and when it breaks and leaves someone stuck, the person stuck will likely not be a geek, and even if a geek would rather not dig into the docs for the desktop environment just to make $whatever work again dammit.
Some questions that do 3d6 fire damage Posted Aug 27, 2010 20:37 UTC (Fri) by alankila (subscriber, #47141) [Link]
Lennart, I would like to add some audio DSP capabilities to PulseAudio. I might want a bit of input about that -- I tried sending you an email with some rubbish I had made a month or two ago, but you never responded.
I have since implemented this stuff into Android, and it's about to go live in CyanogenMod 6 that is going to be released, like, tonight. I'd like to see this code also on the Linux desktop. For reference, here's the application I built for Android:
http://bel.fi/~alankila/android-dsp/
I'd specifically need a few pointers about the good way to design this. I'm thinking about making a module that can be loaded into PulseAudio and which listens to dbus for configuration, and something like gnome-volume-control or such application could provide the GUI for settings and send these events over the dbus when it starts up. This would be a close equivalent to how I implemented it on Android.
Some questions that do 3d6 fire damage Posted Aug 31, 2010 14:59 UTC (Tue) by aquasync (subscriber, #26654) [Link]
It would be very cool to have a system-wide dsp! Hope something similar makes it in to pulse audio one day.
Please...(again)... Posted Aug 26, 2010 13:09 UTC (Thu) by corbet (editor, #1) [Link] I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat" to somebody who has contributed large amounts of code to our community (or to anybody else, for that matter). Can we agree that would make LWN a more pleasant and focused place for all of us?(FWIW, pulse has worked fine for me for quite some time now. Systemd is also mostly working well now that I've typed the relevant rawhide-only incantations, though I do need to figure out why networking didn't come up on the last boot...)
Please...(again)... Posted Aug 26, 2010 14:33 UTC (Thu) by mmcgrath (subscriber, #44906) [Link]
> I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat"
Surely calling people names isn't good, but I share his frustration. No one in Fedora ever has the "should" conversation. It's always technical discussions. So everything that's done gets in. It's both a strength and weakness of Fedora. This has been posted, I'll post it again because IMHO this is exactly what is going on here.
http://home.comcast.net/~tomhorsley/wisdom/braindump/oss-...
Please...(again)... Posted Aug 26, 2010 21:57 UTC (Thu) by marcH (guest, #57642) [Link]
> This has been posted, I'll post it again because IMHO this is exactly what is going on here.
This is both hilarious and quite accurate. It is only missing the last two stages.
First the Developer becomes slightly bored and not interested in re-implementing all the useful workarounds that the original piece of software featured in order to cope with the real world. Because it is so much better to fix the real world instead!
And then the final stage where the Developer becomes really bored, realizing that he has solved all the interesting problems. He then jumps on his white horse and rides to new pastures, to other crucially important pieces to entirely re-design and re-implement. It is very urgent to free users from these other broken pieces since they have been suffering from them since a few decades now! Average, boring people like you and me will be good enough for the mundane task of maintaining the current project.
Please...(again)... Posted Aug 27, 2010 9:31 UTC (Fri) by cmccabe (guest, #60281) [Link]
That's hilarious. I love the Douglas Adams reference.
Seriously, though, I can understand Lennart's point of view here. With pulseaudio and systemd, he has created code that is better than what came before it. But the problem with straightening out the crooked things is that it causes a lot of short-term pain.
What I've found in the past is that when you make a big change to something, you spend more time handling "transition issues" than you do actually architecting the new solution. Usually you have provide compatibility and "legacy" modes, do extensive testing, and fix a lot of problems that have absolutely nothing to do with anything you've written, but which just happen to crop up when your new solution is place.
As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. There is often a temptation to skip this part-- just like there is a temptation to put off writing good documentation. But you absolutely must not do this, or else you will make a lot of enemies.
The worst part is that if something breaks, you will be the bad guy, no matter whose fault the problem actually is. It could be a bug in the python interpreter that is being exposed by your kernel change-- and you will get the blame. The only response is to be professional about it-- to offer compatibility modes or workarounds, and get to the root cause of the problem. At some point, this is just the fate of all engineers. You never think about the guy who built your highway onramp-- until something bad happens.
Lennart's flippant response about the "noauto" change suggests that he still has to learn how to really do this right. Hopefully he'll get the hang of it. And then we can finish building that hyperspace bypass. After all, the plans *have* been on display for 50 of your earth years.
Please...(again)... Posted Aug 27, 2010 10:46 UTC (Fri) by marcH (guest, #57642) [Link]
> As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. [..] But you absolutely must not do this, or else you will make a lot of enemies.
... especially when you replace something inferior, but core and WORKING. You can take whatever risks you want with brand new features, but regressions? Never, ever. Even if you put an extraordinary amount of effort in implementing the best piece of software ever, people will hate you for the tiniest regressions. And you deserve it. Divas seem to forget too easily that normal people have a day job: make the system JUST WORK whatever it takes and no matter how ugly it is in the end.
PS: yeah I know, I should use RedHat. You can save your post.
Please...(again)... Posted Aug 27, 2010 12:59 UTC (Fri) by mpr22 (subscriber, #60784) [Link] I would say that "work, just" is more accurate than "just work".
Please...(again)... Posted Aug 27, 2010 13:20 UTC (Fri) by mmcgrath (subscriber, #44906) [Link]
> ... especially when you replace something inferior, but core and WORKING.
I would disagree that the current scripts are inferior. People in our field are far to quick to dismiss the value of simplicity. systemd has several more features, I'll certainly admit that. The older / current method was great though. You'd think there was other lower hanging fruit that required attention.
Please...(again)... Posted Aug 27, 2010 13:30 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Obviously, people work on what catches their attention. For a hobbyist project, we can't expect anything more. Why complain about that?
Please...(again)... Posted Aug 27, 2010 13:48 UTC (Fri) by mmcgrath (subscriber, #44906) [Link]
I can't think of a worse way to design a system whole then what you just described. That's why I complain.
Please...(again)... Posted Aug 27, 2010 13:51 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
I don't see what you are talking about. Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in. It might not be some low hanging fruit that you want to tackle but obviously different people have different interests. If you want to tackle a different problem, go ahead and do that.
Please...(again)... Posted Aug 27, 2010 14:00 UTC (Fri) by mmcgrath (subscriber, #44906) [Link]
> Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in.
I agree, and relative quality difference compared to what is available around it has grown wider and wider. The Linux desktop is a wasteland of disjointed features and applications that only sort of work together written by groups that have far more reach then manpower and no central design other then freedom. We've made almost no headway on the desktop in the last _10_ years. We're still sitting at 1%. I'm tired of playing this tune, I need to just accept that.
But now I'm seeing these crazy disjointed desktop bits make their way into core system parts (note: NetworkManager didn't replace network scripts for a reason in RHEL6). So now I worry that where we have made great headway (on the server) is now being put at risk by these silly disjointed 'features'.
Please...(again)... Posted Aug 27, 2010 14:10 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
And what is the proposed solution here? As long as you are not paying people to work on what you want, it is always going to be a distributed set of components with no central design or authority. It is sort of like evolution, messy and inefficient but noone else has proposed a better way to tackle it without throwing away a lot of money on something that might not pay dividends even years later.
Please...(again)... Posted Aug 29, 2010 7:31 UTC (Sun) by cmccabe (guest, #60281) [Link]
> I would disagree that the current scripts are inferior. People in our
> field are far to quick to dismiss the value of simplicity. systemd has > several more features, I'll certainly admit that. The older / current > method was great though. You'd think there was other lower hanging fruit > that required attention.
I don't think systemV init scripts are really simpler. They just push the complexity into other parts of the system.
Since they can't represent dependency information, you either have to have a slow boot time or parallelize things by hand. I have had to manually parallelize sysV scripts before, and it's not fun. The system should know what depends on what.
Since sysV init scripts only happen at boot time, or when someone changes the runlevel, you have to have a separate mechanism to handle the addition of hardware at runtime. Sometimes adding that hardware requires starting a daemon-- for example, when it's bluetooth hardware.
SystemD also subsumes portreserve and xinetd. In theory systemD could also handle restarting daemons, although I don't know if that has been implemented yet.
Please...(again)... Posted Sep 2, 2010 3:22 UTC (Thu) by filteredperception (guest, #5692) [Link]
> I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat" to somebody who has contributed large amounts of code to our community (or to anybody else, for that matter). Can we agree that would make LWN a more pleasant and focused place for all of us?
As someone who succumbed to PA bug rage on bugzilla, I feel a 100+ comment article is a pretty good place to add an extra apology. But you have to understand, that the bug in question, literally involved *painful*, possibly health-damaging audio making its way to my earbuds for the portion of a second it took my brain to rip the things out of my ears. Until that experience, it had never entered my mind that a distro bug was literally a health hazard. In fact, since my bug-rage-rant, I've come to the believe that the intel sound hardware, or perhaps even the sony earbud hardware, are at fault for allowing a software bug to be potentially seriously health damaging. But as many have mentioned, I ran into LP's rather dismissive attitude, which really, in that reactionary timeperiod, rubbed me the wrong way.
I don't even recall how PA was pushed onto fedora, but if there was any way it could have been done, that it could have reduced the number of people whose audio hit __400%__ due to a rhythmbox/pa-flat-volumes bug _instantaneously_, then it really, really, IMHO would have been worth it.
And I have to admit just a little bit of flaring anger at the (ad hominem attack redacted) idea that systemd should be default on in the first release of fedora that it lands in. _Especially_ when it is as easy to leave default off, but turn on as described in this article. I mean, we are talking about such a core piece of the distro infrastructure. Something that decades upon decades of sysadmins have painstakingly all familiarized themselves with. I mean, <seth and amy voice>Really?!?</>, you can't phase it in as default off for one release? <>Really?!?</>.
Honestly I am precisely one of those people being driven away from fedora. I like my bleeding edge stuff, but after suffering the last several releases, I can not tell you how much I look forward to CentOS6, and just saying- go ahead fedora folks, have all the crazy fun you want, just without me, I'll catch up with you in a decade when CentOS7 comes out.
Anyway, I wish systemd the best of luck, and just hope RH facilites COS6 in a timely enough manner that I don't have to touch it for many many years, because it's not solving any problem I knew I had.
Please...(again)... Posted Sep 3, 2010 15:03 UTC (Fri) by mpr22 (subscriber, #60784) [Link] My gut reaction is that some parts of the system are so "core" that if you don't trust a candidate for one of those parts enough to make it the default, you shouldn't even make it a conveniently visible option in anything you're going to call a "release". PID 1 is one of those parts.
Systemd and Fedora 14 Posted Aug 26, 2010 9:12 UTC (Thu) by neiljerram (subscriber, #12005) [Link] To pick up on one tiny detail:as Poettering points out: "note the /sbin vs. /bin!"Why? systemd is a system daemon, so it should be in /sbin, shouldn't it? (Based on no evidence at all apart from this, I sense a guy who quite enjoys decisions that cause little bits of arbitrary aggravation...)
Systemd and Fedora 14 Posted Aug 26, 2010 9:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
systemd is also a user intended to manage user sessions in the future. Hence the path difference
http://lists.fedoraproject.org/pipermail/desktop/2010-Aug...
Systemd and Fedora 14 Posted Aug 26, 2010 9:56 UTC (Thu) by neiljerram (subscriber, #12005) [Link]
FWIW, that doesn't seem to me to be a compelling reason - because the user-level aspect doesn't exist yet; and because when it does exist, no user is ever going to start systemd manually at a command line, hence there's no requirement to be in /bin - so technically I think my point stands.
The point about enjoying the decision is probably unfair though, so I take that back.
Systemd and Fedora 14 Posted Aug 26, 2010 10:08 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I prefer a consistent path rather than one which changes across versions. If the plan is to manage user sessions, I prefer the path be what it is, right from the start. It is a really pain to teach people to relearn new paths and change documentation and so on.
Systemd and Fedora 14 Posted Aug 26, 2010 10:36 UTC (Thu) by neiljerram (subscriber, #12005) [Link]
For me, the more important consistency is with all other system or predominantly-system daemons being in /sbin. Do you have any firm reason for needing systemd to be in /bin?
Putting systemd in /bin is non-intuitive - as is already acknowledged by Lennart's note that I cited.
(When I find myself writing notes like that, I try to consider whether it would be easy to just fix or improve the software, so that the note isn't needed.)
Will it cause problems? Yes. Some people will put init=/sbin/systemd and then won't be able to boot. They may not immediately realize the fix, and they may not have another computer sitting next to them, or a live disc, to be able to discover the solution easily.
What is the benefit of /bin that balances out this pain and makes the pain worthwhile?
Systemd and Fedora 14 Posted Aug 26, 2010 11:16 UTC (Thu) by Los__D (guest, #15263) [Link]
That it is going to be run by regular users as well?
On many systems, /sbin is not in the regular user paths.
Systemd and Fedora 14 Posted Aug 26, 2010 18:02 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
And, what's wrong with throwing a symlink into "/bin"?
Systemd and Fedora 14 Posted Aug 26, 2010 18:09 UTC (Thu) by Los__D (guest, #15263) [Link]
Nothing more than throwing a symlink into /sbin.
This is (will be) for both the system and the users, so both /sbin and /bin are equally valid, IMHO.
Systemd and Fedora 14 Posted Aug 27, 2010 19:51 UTC (Fri) by cdmiller (subscriber, #2813) [Link]
Perhaps it should be renamed Userd.
Sorry couldn't help myself with all the flaming and angst :)
Systemd and Fedora 14 Posted Sep 2, 2010 9:35 UTC (Thu) by Randakar (guest, #27808) [Link]
Actually putting the symlink in /sbin IS worse than putting it in /bin.
/sbin is intended to be the place where crucial system utilities live that always should be available, AFAIK. When this distinction was made in the (distant) past the idea was that /bin could live on a different filesystem from root. /sbin would contain everything one might need before /bin could get mounted.
Putting systemd in /bin breaks that idea rather thoroughly. Why have the distinction between the two places at all if the init system doesn't live in /sbin?
Systemd and Fedora 14 Posted Sep 2, 2010 12:05 UTC (Thu) by robbe (guest, #16131) [Link]
I assume you are confounding that with the /$d vs. /usr/$d (for values of d in {lib, bin, sbin, ...}) distinction. A system is expected to be able to boot into a more-or-less usable mode without /usr.
Except for embedded systems I don't have access to any machine that would be able to boot without /bin. For example, all shells are located there.
Systemd and Fedora 14 Posted Sep 2, 2010 18:42 UTC (Thu) by ABCD (subscriber, #53650) [Link] If /bin is on a separate filesystem from /, then you wouldn't even be able to mount /bin because you wouldn't have a /bin/mount program that could mount it. From a footnote in the latest FHS: Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.
Systemd and Fedora 14 Posted Aug 26, 2010 10:09 UTC (Thu) by mezcalero (guest, #45103) [Link]
Oh, the user-level aspect is there. It's not complete, but it works just fine. Running systemd as a normal user just works. It won't do much, because no services are registered for it, but if you drop in a couple of .service files you can already manage them in the session with systemd just fine.
Systemd and Fedora 14 Posted Aug 26, 2010 13:23 UTC (Thu) by csigler (subscriber, #1224) [Link]
> Why? systemd is a system daemon, so it should
> be in /sbin, shouldn't it?
I'm getting old. A doc I found on FHS from 2004 says /sbin (and other sbin dirs) are for "system binaries," that is, "utilities used for system administration."
However, in the dark ages, the binaries in /sbin and similar were _statically_linked_ binaries (hence sbin). Why static? If something wonky happened to hose your system and you could only boot into a limited/single-user environment dymanic linking might not work, so any binaries needing to load .so files would fail to run. If your crucial system diagnostic and repair programs (like fsck) were dynamically linked, you're SOL.
Nowadays, we just boot from a system installation or utility disk to fix things (if they can be fixed). But there was a time before such CDs, or booting directly from an installation medium. Without those static binaries, you were sunk. Hello reinstallation and recovery from backups -- if you kept regularly updated backups....
Clemmitt
Systemd and Fedora 14 Posted Aug 26, 2010 20:54 UTC (Thu) by vonbrand (subscriber, #4458) [Link] No. /sbin (and /usr/sbin) was for system binaries, decreed Sun way way back. All in /bin and /sbin was statically linked, later it used only libraries in /lib. Remember /usr was where users used to live, and bin was just the "user" with all the nifty, non-essential, stuff in his $HOME...
Systemd and Fedora 14 Posted Sep 3, 2010 18:05 UTC (Fri) by nix (subscriber, #2304) [Link]
What? No, /usr was where the second 20Mb hard disk was added. :)
Systemd and Fedora 14 Posted Aug 26, 2010 21:36 UTC (Thu) by nix (subscriber, #2304) [Link]
As far as I'm concerned, *all* daemons should go somewhere outside $bindir; /usr/libexec, /usr/sbin, somewhere like that, *anywhere* other than /bin or /usr/bin, because those are *in the $PATH*. If a program is meant to be run entirely by another program, *why* is it somewhere where a user can run it by hand easily?
Systemd and Fedora 14 Posted Aug 27, 2010 7:53 UTC (Fri) by Darkmere (subscriber, #53695) [Link]
dhcpd -t
Therefore it is clearly not meant to be ran by only a program, so it needs to live in /sbin not ?+/libexec
named -t too, I seem to recall?
Systemd and Fedora 14 Posted Sep 3, 2010 18:09 UTC (Fri) by nix (subscriber, #2304) [Link]
Uh, nothing I said stated that programs that are meant to be run by sysadmins should *not* reside in sbin/. a->b -/> b->a, y'know.
Systemd and Fedora 14 Posted Aug 26, 2010 10:00 UTC (Thu) by etienne (subscriber, #25256) [Link]
For me, a good startup procedure would be to detect if a subsystem is useable before starting the upper layers. I mean:
- insert the kernel module of that chipset - see if the "stuff" is useable - start upper layers if needed. For instance, if there is no way to output sound because there isn't any loudspeaker/headphones connected, do not bother starting anything related to sound. If there is no LINK-UP on an ethernet port (and no wireless where a password is known), do not bother starting anything related to network like NFSD, Samba... If there isn't any printer, do not bother starting CUPS. I can see how that would work with upstart, but with Systemd it seems that upper layers are started anyway. If you are using your computer in a plane or a high speed train, you will not get an internet connection - that's all.
Systemd and Fedora 14 Posted Aug 26, 2010 10:09 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Perhaps you didn't read
http://0pointer.de/blog/projects/systemd.html
In particular, the situation seems rather reverse of what you claim.
Systemd and Fedora 14 Posted Aug 26, 2010 14:11 UTC (Thu) by etienne (subscriber, #25256) [Link]
What I wanted to say is the difference in the treatment of errors.
Imagine there is a program named "beep" in an initscript to warn the user of a malfunction. That particular PC do not have any way to produce a sound, at least for some time - the USB sound adapter may be connected in few days one I have landed. Shall the "beep()" function fails, or shall the whole initscript be delayed until some USB sound device is connected? Basically, shall systemd create a socket that "beep()" will wait for, or shall "beep()" detect that there is no "sound socket" and either fail or do something else?
Systemd and Fedora 14 Posted Aug 26, 2010 14:23 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
the service file associated can instruct systemd to start it by default or on socket activation. Either is possible.
Systemd and Fedora 14 Posted Aug 26, 2010 15:11 UTC (Thu) by etienne (subscriber, #25256) [Link]
So the distribution default will be to start sound on socket activation, that is the normal setup.
Now, the computer has booted - how to hide that socket for the next 10 minutes, I know that beep() will be called by the next command - and I want beep() to fail? Or, I am in a plane, I want the network OFF so that all applications will start in their "off-line" mode.
Systemd and Fedora 14 Posted Aug 26, 2010 15:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
You disable the particular services. Have you tried systemd at all? I am not sure where the confusion is coming from.
Systemd and Fedora 14 Posted Aug 27, 2010 9:23 UTC (Fri) by Kamilion (subscriber, #42576) [Link]
> Or, I am in a plane, I want the network OFF so that all applications will start in their "off-line" mode.
Um... Flick your hardware RF kill switch to 'wireless off'?
But your implied 'network OFF' is a relatively heavy sledgehammer if you're nitpicking socket activation; what about lo or vbox/vmware networks?
In closing, a nitpick of my own: You insane people using the PC speaker beep in init should be SHOT with a SONIC CANNON. ;)
Systemd and Fedora 14 Posted Aug 26, 2010 10:17 UTC (Thu) by mezcalero (guest, #45103) [Link]
That's a misconception, I actually often use CUPS as an example how things are much better covered by systemd than by upstart, because we can start it via socket, path or device activation and that race-freely, instead of having mandatory on-boot startup.
In fact, on top of that doing device-based activation is a lot nicer in systemd than in upstart, since a device can pull in a service, but the service is then properly delayed until all its dependencies are available. For example, that allows us to start CUPS when the device is plugged in (which will on coldplug happen very early during boot), but delay this until the local file systems are properly mounted. systemd is much much smarter here than Upstart ever was. As soon as you have multiple triggers and multiple requirements of a service systemd can model things much much better than Upstart for any kind of activation. And the best thing is that this kind of synchronization happens completely transparently for all normal services, the user/admin doesn't need to have any particular insight into boot ordering.
Systemd and Fedora 14 Posted Aug 27, 2010 9:12 UTC (Fri) by Kamilion (subscriber, #42576) [Link]
And 'surprisingly', it finally makes the stupid networked LaserJet 2840 in the office usable!
None of our linux desktops have a printer directly connected, they all print via a shared network queue. And one machine is designated as that CUPS queue. Which then sends the print job back out over the network to the printer. Or faxes it. Plus everything going through the queues gets PDF'd, tagged, sorted, and logged.
Testing a F14 box with systemd standing in for the normal CUPS queue machine over the weekend: Holy crap, I didn't have to mess with any configuration past clicking "new printer" then "share printer". CUPS is only running when there's work to be done. Wonderful! Can't wait till systemd trickles down to debian and gets picked up in ubuntu. My 'clever' upstart scripts seem so... ugly and inflexible now.
Oh, and nothing's stopping you from defining a unit that runs a shellscript, if that's what you 'need' to do to get something done. It's just, now there's an easier way than copying somebody's shell template and stumbling through bash tutorials just to get something like nginx and php+fastcgi starting up with any kind of reliability. Then you find something like monit or god, get it working in 5 minutes and slap your forehead wondering why you spent four weeks on a damned init script.
systemd's like that. Forehead-slapping easy.
And hey -- I could never wrap my brain around fundamentally understanding *every* initscript in my /etc; just bouncing between scrolling up and down in /lib/lsb/init-functions and tabbing back to /etc/init.d to figure out the total codepath gives me a headache. I read all the included systemd units, and now I have a total understanding of where everything stands in a couple glances.
Now if only I had a replacement for Process Explorer... gnome-system-monitor doesn't cut it. Least htop's pretty close.
Systemd and Fedora 14 Posted Aug 27, 2010 15:02 UTC (Fri) by gidoca (subscriber, #62438) [Link]
I don't know about other DEs, but on KDE, you don't need to have CUPS running on your local machine to support printing on a remote machine or network printer, given that it supports IPP and Zeroconf. It will automatically detect the remote CUPS instance and show it in the print dialog, without accessing the local print server.
Systemd and Fedora 14 Posted Aug 30, 2010 15:11 UTC (Mon) by salimma (subscriber, #34460) [Link]
I believe Kamilion was describing setting up the remote CUPS instance itself.
Systemd and Fedora 14 Posted Sep 5, 2010 16:24 UTC (Sun) by AdamW (guest, #48457) [Link]
"Oh, and nothing's stopping you from defining a unit that runs a shellscript, if that's what you 'need' to do to get something done."
in fact, we're already doing this in F14. firstboot in F14 uses a 'native' systemd unit file, which actually just sets an environment variable and then runs /etc/init.d/firstboot...(don't ask me to explain why, it's sort of complicated. :>)
Systemd and Fedora 14 Posted Sep 6, 2010 6:19 UTC (Mon) by Darkmere (subscriber, #53695) [Link]
I've played a bit with F14 alpha but have issues running it (related to nouveau drivers and my specific hardware, really) and I wanted to interject a question:
Traditionally, we have had certain things in/out-of order due to non-strict dependency issues though still "needed", for example, starting a (deny all) firewall before network, as well as waiting with samba/ftp-servers until after network-access or filesystems are available.
Such "soft" ordering doesn't appear to be on schedule for systemd, so, how will this work in the end? Fex. I want to restart some daemons that aren't perfectly well behaved if they are to work on files residing on a network drive (has happend quite a few times), previously it's been a case of manually reordering things, in systemd, I'm not quite sure anymore.
Systemd and Fedora 14 Posted Sep 6, 2010 7:04 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
man systemd.service shows Before=foo and After=boo for manual ordering. I think that would work for you but do drop your feedback to systemd developers in case, we can fix this automatically somehow.
Systemd and Fedora 14 Posted Sep 6, 2010 8:15 UTC (Mon) by Darkmere (subscriber, #53695) [Link]
I thought the before/after only worked for start-ordering, not completion?
I don't care if you've started the network service+network filesystem handshake, the services using files in that area may only be started after they are finished, not before.
This sort of interaction happens in reality, mostly you can pass it off like "so fix the service so it notices the new filesystem" but my reality wearing an administrator hat is... different from that.
Systemd and Fedora 14 Posted Sep 7, 2010 15:08 UTC (Tue) by foom (subscriber, #14868) [Link]
From reading some manpages:
http://0pointer.de/public/systemd-man/systemd.service.html http://0pointer.de/public/systemd-man/systemd.unit.html
It sure sounds like they control completion ordering.
"After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, i.e. that the configured unit is fully started up before the listed unit is started"
And, see the description of Type= on the systemd.service page.
Systemd and Fedora 14 Posted Aug 26, 2010 18:48 UTC (Thu) by Banis (guest, #59011) [Link]
This is starting to scare me. I'd been convinced systemd was a good idea before reading the developers response to entirely legitimate bugs. Every single time he said, I just changed a 10 year old option because I wanted to. That's bad. "Do no harm" is a very important part of system administration. After reading what the developer of this thing has to say, he clearly does not understand or care about that.
Nobody will really care what I think, but I would prefer nothing get anywhere near my systems if the developer has this level of attitude problem.
Fedora needs to just stick with upstart.
Systemd and Fedora 14 Posted Aug 26, 2010 20:36 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Can you give a specific example where upstart behaves better than systemd?
(e.g. with respect to some existing "10 year old option", as you mention).
Systemd and Fedora 14 Posted Aug 27, 2010 1:28 UTC (Fri) by drag (subscriber, #31333) [Link]
This is Poettering's style. He is probably right, but probably so are you.
But your right that Systemd needs to depend on more then just him if it's ever going to be acceptable no matter how well the design is.
Systemd and Fedora 14 Posted Aug 26, 2010 23:11 UTC (Thu) by cyd (guest, #4153) [Link]
I, for one, look forward to Systemd doing to my bootup sequence what PulseAudio did to my sound system...
Systemd and Fedora 14 Posted Aug 27, 2010 8:50 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Some things, in text, inevitably look like an undercooked attempt at snarking whether meant entirely sincerely or entirely snarkily.
Systemd and Fedora 14 Posted Aug 27, 2010 10:23 UTC (Fri) by nirbheek (subscriber, #54111) [Link]
It is entirely possible that the ambiguity in that comment in on purpose. Both extremes of the discussion see what they expect/hope to see ;)
Systemd and Fedora 14 Posted Aug 27, 2010 1:45 UTC (Fri) by jonabbey (subscriber, #2736) [Link]
I'm excited by systemd and am hopeful that it is adopted.
I'm also hopeful that the very significant amount of testing and refinement that such a change merits is carefully done. I've seen way too many things break in Fedora due to SELinux policy issues for my liking, even though I am one who likes the goals of SELinux very much.
I don't consider a move to systemd to be nearly as invasive or as potentially problematic as SELinux is, though, and there are already multiple existence proofs of init replacements being integrated cleanly. SMF, launchd, upstart have all shipped without causing much in the way of grief, and they don't promise everything that systemd does.
Which, of course, is all the more reason for test and refinement, but I think I'm willing to serve as a guinea pig for this on my Fedora boxes.
Systemd and Fedora 14 Posted Aug 27, 2010 20:11 UTC (Fri) by cdmiller (subscriber, #2813) [Link]
One question that comes to mind, how easy is it to fix when something is broken? Just went through this with upstart/plymouth startup on upgraded Ubuntu Lucid servers. It was not well documented how to restore boot time messages and logs to chase down boot problems, or set up a text console rather than frame buffer mode.
With systemd starting everything "at once", "as touched", how tough is it to trouble shoot or gracefully error out when something doesn't work or untested configurations crops up?
Systemd more robust? Posted Sep 4, 2010 11:32 UTC (Sat) by gmatht (guest, #58961) [Link]
I just remotely upgraded a desktop machine to Lucid. After rebooting, I couldn't ssh into the machine anymore. I drove round and found that the machine couldn't mount the windows partition anymore. It was waiting on a prompt asking if I wanted to Skip mounting this drive or Manually fix the problem. I was thinking of reporting a bug as it seems to be bad policy to wait indefinitely on non-fatal errors.
However it sounds like a switch to systemd would fix all these sorts of problems. From my understanding, sshd, gdm and everything else that is actually important wouldn't wait for a windows partition to be mounted under systemd.
Systemd - What does it really provide? Posted Sep 5, 2010 10:48 UTC (Sun) by WolfWings (subscriber, #56790) [Link]
From what I understand, primarilly systemd opens up all the sockets/ports/whatever that components need as early as possible, so they can all fire off their crap at the same time and rely on the kernel's networking queues and what-not and blocking read/write calls to pause stuff the minimal amount possible.
Wouldn't the same thing be possible in every case by cleaning up the daemons in question so they simply open their sockets and set them up sooner themselves? I seem to see a lot of stuff that 'preloads' everything before firing off a single socket() call, so yes, you need to load stuff in the right order or things will crash and fall to pieces.
So why not push the fixes to let stuff be started up more in parallel downstream to individual packages, then just make the init daemons able to be told "this daemon fast-starts, never wait for it and assume it started correctly as soon as you run it" more or less? We seem to be abdicating the responsibility of the developers of the component packages for bootup speed, and trying to hide it instead of encouraging/forcing bottlenecking packages to get their act together.
Systemd - What does it really provide? Posted Sep 5, 2010 14:05 UTC (Sun) by foom (subscriber, #14868) [Link]
"this daemon fast-starts, never wait for it and assume it started correctly as soon as you run it"
Because that has a race condition: the other app can still try to access it too soon. "Sooner" is not soon enough, it has to be done *first*. And you can't guarantee that it'll be done first unless you have a manually maintained dependency graph (or linear startup ordering), like you need today.
That is why systemd is such a great idea: it totally removes the need to worry about dependencies most of the time. You just start programs, and if they depend on something else, they block waiting for the something else to get automatically started too, without needing to explicitly mark the dependency.
Systemd and Fedora 14 Posted Sep 5, 2010 16:21 UTC (Sun) by AdamW (guest, #48457) [Link]
A few notes.
One, systemd isn't just default in Rawhide at present, it's default in F14. If you install F14 Alpha, or update an F13 system to F14, you get systemd.
Two, the arrangement whereby systemd and upstart are installed side by side is only temporary and will only last until we make the final decision whether to ship systemd in F14. At that point it'll be changed so only the one we choose will be installed by default, and only one can be installed at any time.
Three, most of the bugs mentioned in this post are fixed now and were only transitory, they only affected you if you happened to update to a version with the bug. They don't affect the Alpha, and they shouldn't affect any installs of the Alpha updated direct to the current systemd release (9-3), or any systems updated straight to current F14 state.
Installing both Posted Sep 5, 2010 23:47 UTC (Sun) by corbet (editor, #1) [Link] Systemd is now working fine for me on Rawhide, but I have to wonder: why wouldn't you at least make it possible to have both systems installed, even if you're determined not to install both by default? This is a big, scary change; having the upstart fallback makes it easy to work around any crippling problems and greatly lowers the risk of the transition. The two can coexist for now; carrying that ability forward for one cycle would seem to make a lot of sense.What am I missing?
|
|||||||||||||