Systemd and Fedora 14
Systemd, 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:
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:
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:
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.
Posted Aug 25, 2010 20:53 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (2 responses)
Posted Aug 25, 2010 21:09 UTC (Wed)
by fuhchee (guest, #40059)
[Link]
There are not actually many flames out there these days; more's the pity. A creative flame is a sight to behold.
Posted Aug 25, 2010 21:47 UTC (Wed)
by AlexHudson (guest, #41828)
[Link]
Posted Aug 25, 2010 20:56 UTC (Wed)
by busterb (subscriber, #560)
[Link] (7 responses)
Posted Aug 25, 2010 21:00 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (2 responses)
Was there an article explaining why systemd exists, rather than improving upstream projects like upstart or launchd, fixing their perceived deficiencies?
Posted Aug 25, 2010 21:14 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
-jef Posted Aug 25, 2010 22:27 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
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.
Posted Aug 26, 2010 7:12 UTC (Thu)
by pontus (guest, #3701)
[Link] (2 responses)
Posted Aug 26, 2010 7:32 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Aug 26, 2010 7:43 UTC (Thu)
by liljencrantz (guest, #28458)
[Link]
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.
Posted Aug 25, 2010 20:58 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (1 responses)
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.
Posted Sep 5, 2010 16:15 UTC (Sun)
by AdamW (subscriber, #48457)
[Link]
Posted Aug 25, 2010 23:03 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (13 responses)
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.
Posted Aug 26, 2010 4:12 UTC (Thu)
by njs (subscriber, #40338)
[Link] (8 responses)
> 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!)
Posted Aug 26, 2010 9:49 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (7 responses)
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.
Posted Aug 26, 2010 10:41 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (6 responses)
I have one intuition about those numbers (for the record: "not many" and "probably even fewer"). You may well have another.
Posted Aug 26, 2010 13:45 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (5 responses)
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.
Posted Aug 26, 2010 15:13 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (4 responses)
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.
Posted Aug 26, 2010 20:04 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
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.
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.
Posted Aug 28, 2010 0:12 UTC (Sat)
by Blaisorblade (guest, #25465)
[Link] (1 responses)
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/
Posted Sep 2, 2010 8:29 UTC (Thu)
by renox (guest, #23785)
[Link]
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.
Posted Aug 26, 2010 4:27 UTC (Thu)
by charris (guest, #13263)
[Link] (3 responses)
Posted Aug 26, 2010 8:42 UTC (Thu)
by elanthis (guest, #6227)
[Link] (2 responses)
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.
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.
Posted Aug 27, 2010 17:48 UTC (Fri)
by sorpigal (guest, #36106)
[Link]
Posted Aug 26, 2010 0:24 UTC (Thu)
by professor (subscriber, #63325)
[Link]
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.
Posted Aug 26, 2010 1:42 UTC (Thu)
by ncm (guest, #165)
[Link] (4 responses)
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.
Posted Aug 26, 2010 4:16 UTC (Thu)
by njs (subscriber, #40338)
[Link]
Posted Aug 26, 2010 7:50 UTC (Thu)
by ncm (guest, #165)
[Link] (1 responses)
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?
Posted Aug 26, 2010 8:01 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
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.
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.
Posted Aug 26, 2010 5:14 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (54 responses)
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.
Posted Aug 26, 2010 5:57 UTC (Thu)
by tajyrink (subscriber, #2750)
[Link]
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).
Posted Aug 26, 2010 6:00 UTC (Thu)
by Hknr (guest, #67789)
[Link] (32 responses)
Posted Aug 26, 2010 7:37 UTC (Thu)
by mbaldessari (guest, #36769)
[Link] (17 responses)
Posted Aug 26, 2010 7:57 UTC (Thu)
by Hknr (guest, #67789)
[Link] (16 responses)
Posted Aug 26, 2010 11:11 UTC (Thu)
by Los__D (guest, #15263)
[Link] (15 responses)
Posted Aug 26, 2010 11:26 UTC (Thu)
by Hknr (guest, #67789)
[Link] (8 responses)
Posted Aug 26, 2010 11:35 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Aug 26, 2010 12:52 UTC (Thu)
by nicooo (guest, #69134)
[Link]
Systemd gets it right by using ini instead of the xml that everything else hosted on freedesktop.org seems to use.
Posted Aug 26, 2010 12:18 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (3 responses)
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:
Posted Aug 27, 2010 1:20 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
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.
Posted Sep 6, 2010 16:41 UTC (Mon)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Sep 6, 2010 17:10 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Aug 26, 2010 21:20 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
I googled for a stanza to force everything through PulseAudio (first hit: pulseaudio.org's Perfect Setup page) and left it at that.
Posted Aug 26, 2010 21:39 UTC (Thu)
by sfeam (subscriber, #2841)
[Link]
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.
Posted Aug 26, 2010 13:02 UTC (Thu)
by sebas (guest, #51660)
[Link] (5 responses)
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.
Posted Aug 26, 2010 13:31 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Aug 26, 2010 14:00 UTC (Thu)
by sebas (guest, #51660)
[Link] (1 responses)
Posted Aug 26, 2010 14:29 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 27, 2010 17:12 UTC (Fri)
by Trelane (subscriber, #56877)
[Link]
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.)
Posted Aug 27, 2010 9:46 UTC (Fri)
by buchanmilne (guest, #42315)
[Link]
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).
Posted Aug 26, 2010 7:41 UTC (Thu)
by xav (guest, #18536)
[Link] (5 responses)
But I'm not using Fedora, so I probably didn't have to endure the painful beta versions.
Posted Aug 26, 2010 11:54 UTC (Thu)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted Aug 26, 2010 12:16 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
echo "flat-volumes = no" >> /etc/pulse/daemon.conf
Relogin. Although this is often a hardware specific bug in ALSA and should be reported.
Posted Aug 26, 2010 21:30 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
(Do these things get any testing at all? How does Windows do it, and why can't we use the same technique?)
Posted Aug 26, 2010 21:39 UTC (Thu)
by Trelane (subscriber, #56877)
[Link]
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:
Posted Aug 26, 2010 7:48 UTC (Thu)
by niner (subscriber, #26151)
[Link] (7 responses)
Posted Aug 26, 2010 16:47 UTC (Thu)
by leoc (guest, #39773)
[Link] (6 responses)
Posted Aug 26, 2010 17:42 UTC (Thu)
by sfeam (subscriber, #2841)
[Link] (4 responses)
Posted Aug 26, 2010 23:47 UTC (Thu)
by bangert (subscriber, #28342)
[Link] (3 responses)
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.
Posted Aug 27, 2010 0:40 UTC (Fri)
by sfeam (subscriber, #2841)
[Link] (2 responses)
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.
Posted Aug 27, 2010 9:26 UTC (Fri)
by bangert (subscriber, #28342)
[Link] (1 responses)
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 ;-)
Posted Sep 3, 2010 18:21 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Aug 26, 2010 21:24 UTC (Thu)
by ofeeley (guest, #36105)
[Link]
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.
Posted Aug 26, 2010 6:36 UTC (Thu)
by michich (guest, #17902)
[Link]
systemd comes with quite a good amount of manpages.
Posted Aug 26, 2010 10:20 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
Posted Aug 26, 2010 21:33 UTC (Thu)
by nix (subscriber, #2304)
[Link]
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.
Posted Aug 27, 2010 20:37 UTC (Fri)
by alankila (guest, #47141)
[Link] (1 responses)
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.
Posted Aug 31, 2010 14:59 UTC (Tue)
by aquasync (guest, #26654)
[Link]
Posted Aug 26, 2010 13:09 UTC (Thu)
by corbet (editor, #1)
[Link] (14 responses)
(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...)
Posted Aug 26, 2010 14:33 UTC (Thu)
by mmcgrath (guest, #44906)
[Link] (11 responses)
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-...
Posted Aug 26, 2010 21:57 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
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.
Posted Aug 27, 2010 9:31 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (9 responses)
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.
Posted Aug 27, 2010 10:46 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (8 responses)
... 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.
Posted Aug 27, 2010 12:59 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 27, 2010 13:20 UTC (Fri)
by mmcgrath (guest, #44906)
[Link] (6 responses)
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.
Posted Aug 27, 2010 13:30 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted Aug 27, 2010 13:48 UTC (Fri)
by mmcgrath (guest, #44906)
[Link] (3 responses)
Posted Aug 27, 2010 13:51 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Aug 27, 2010 14:00 UTC (Fri)
by mmcgrath (guest, #44906)
[Link] (1 responses)
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'.
Posted Aug 27, 2010 14:10 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Aug 29, 2010 7:31 UTC (Sun)
by cmccabe (guest, #60281)
[Link]
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.
Posted Sep 2, 2010 3:22 UTC (Thu)
by filteredperception (guest, #5692)
[Link] (1 responses)
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.
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.
Posted Aug 26, 2010 9:12 UTC (Thu)
by nelljerram (subscriber, #12005)
[Link] (18 responses)
(Based on no evidence at all apart from this, I sense a guy who quite enjoys decisions that cause little bits of arbitrary aggravation...)
Posted Aug 26, 2010 9:26 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (11 responses)
http://lists.fedoraproject.org/pipermail/desktop/2010-Aug...
Posted Aug 26, 2010 9:56 UTC (Thu)
by nelljerram (subscriber, #12005)
[Link] (10 responses)
The point about enjoying the decision is probably unfair though, so I take that back.
Posted Aug 26, 2010 10:08 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (8 responses)
Posted Aug 26, 2010 10:36 UTC (Thu)
by nelljerram (subscriber, #12005)
[Link] (7 responses)
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?
Posted Aug 26, 2010 11:16 UTC (Thu)
by Los__D (guest, #15263)
[Link] (6 responses)
On many systems, /sbin is not in the regular user paths.
Posted Aug 26, 2010 18:02 UTC (Thu)
by RobSeace (subscriber, #4435)
[Link] (5 responses)
Posted Aug 26, 2010 18:09 UTC (Thu)
by Los__D (guest, #15263)
[Link] (4 responses)
This is (will be) for both the system and the users, so both /sbin and /bin are equally valid, IMHO.
Posted Aug 27, 2010 19:51 UTC (Fri)
by cdmiller (guest, #2813)
[Link]
Sorry couldn't help myself with all the flaming and angst :)
Posted Sep 2, 2010 9:35 UTC (Thu)
by Randakar (guest, #27808)
[Link] (2 responses)
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?
Posted Sep 2, 2010 12:05 UTC (Thu)
by robbe (guest, #16131)
[Link]
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.
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.
Posted Aug 26, 2010 10:09 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link]
Posted Aug 26, 2010 13:23 UTC (Thu)
by csigler (subscriber, #1224)
[Link] (5 responses)
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
Posted Aug 26, 2010 20:54 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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...
Posted Sep 3, 2010 18:05 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Aug 26, 2010 21:36 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Aug 27, 2010 7:53 UTC (Fri)
by Darkmere (subscriber, #53695)
[Link] (1 responses)
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?
Posted Sep 3, 2010 18:09 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Aug 26, 2010 10:00 UTC (Thu)
by etienne (guest, #25256)
[Link] (15 responses)
Posted Aug 26, 2010 10:09 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
http://0pointer.de/blog/projects/systemd.html
In particular, the situation seems rather reverse of what you claim.
Posted Aug 26, 2010 14:11 UTC (Thu)
by etienne (guest, #25256)
[Link] (4 responses)
Posted Aug 26, 2010 14:23 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Aug 26, 2010 15:11 UTC (Thu)
by etienne (guest, #25256)
[Link] (2 responses)
Posted Aug 26, 2010 15:16 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Aug 27, 2010 9:23 UTC (Fri)
by Kamilion (guest, #42576)
[Link]
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. ;)
Posted Aug 26, 2010 10:17 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (8 responses)
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.
Posted Aug 27, 2010 9:12 UTC (Fri)
by Kamilion (guest, #42576)
[Link] (7 responses)
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.
Posted Aug 27, 2010 15:02 UTC (Fri)
by gidoca (subscriber, #62438)
[Link] (1 responses)
Posted Aug 30, 2010 15:11 UTC (Mon)
by salimma (subscriber, #34460)
[Link]
Posted Sep 5, 2010 16:24 UTC (Sun)
by AdamW (subscriber, #48457)
[Link] (4 responses)
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. :>)
Posted Sep 6, 2010 6:19 UTC (Mon)
by Darkmere (subscriber, #53695)
[Link] (3 responses)
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.
Posted Sep 6, 2010 7:04 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Sep 6, 2010 8:15 UTC (Mon)
by Darkmere (subscriber, #53695)
[Link] (1 responses)
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.
Posted Sep 7, 2010 15:08 UTC (Tue)
by foom (subscriber, #14868)
[Link]
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.
Posted Aug 26, 2010 18:48 UTC (Thu)
by Banis (guest, #59011)
[Link] (2 responses)
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.
Posted Aug 26, 2010 20:36 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
(e.g. with respect to some existing "10 year old option", as you mention).
Posted Aug 27, 2010 1:28 UTC (Fri)
by drag (guest, #31333)
[Link]
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.
Posted Aug 26, 2010 23:11 UTC (Thu)
by cyd (guest, #4153)
[Link] (2 responses)
Posted Aug 27, 2010 8:50 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Aug 27, 2010 10:23 UTC (Fri)
by nirbheek (subscriber, #54111)
[Link]
Posted Aug 27, 2010 1:45 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
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.
Posted Aug 27, 2010 20:11 UTC (Fri)
by cdmiller (guest, #2813)
[Link]
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?
Posted Sep 4, 2010 11:32 UTC (Sat)
by gmatht (subscriber, #58961)
[Link]
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.
Posted Sep 5, 2010 10:48 UTC (Sun)
by WolfWings (subscriber, #56790)
[Link] (1 responses)
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.
Posted Sep 5, 2010 14:05 UTC (Sun)
by foom (subscriber, #14868)
[Link]
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.
Posted Sep 5, 2010 16:21 UTC (Sun)
by AdamW (subscriber, #48457)
[Link] (1 responses)
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.
Posted Sep 5, 2010 23:47 UTC (Sun)
by corbet (editor, #1)
[Link]
What am I missing?
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
read this for background
read this for background
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd test day
Systemd test day
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Of course, I mean that first systemd should have a alpha-beta-stable set of releases, and then a distribution should test integration (over more than 6 months). Which means that Lennart's thinking in this mail [1] is broken.
I mean, yes, it's optional in the current Fedora, but it's not yet ready. Finish it, declare it bug-free, ship it as optional, and then watch testers report tons of bugs - because those testers are simply more masochistic machos with crazy configurations that you have to support.
I'm more concerned about concerns expressed in the article, like "Poettering has something of a reputation for waving away bugs as features" or the handling of noauto - I see the technical point in changing its handling, but I very much see that 99% of the users using noauto use it for good reasons which can go beyond boot-up time, and do so consciously, so changing the interpretation of noauto really questions the sanity of the developer. (Readers of The Art of Unix Programming from Raymond will also notice that choosing for users is very much against the Unix spirit in general, for the reasons I just discussed).
[2] http://lwn.net/Articles/401921/
Systemd and Fedora 14
> That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Fedora's mission is this: "The Fedora Project is out front for you, leading the advancement of free, open software and content."
Now Ubuntu's early use of PulseAudio, the KDE4.0 mess, etc, on the other hand *sigh*..
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
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
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
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
Some questions that do 3d6 fire damage
is exactly the way we like it in Linux land.
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
* USB headphones with microphones
* USB sound card
* Bluetooth heaphones
* use your microphone
* use audio input with more then one application
* Use X11 applications over a network that have audio
* use a USB docking station for your laptop
* use your bluetooth headset
* Be able to switch your bluetooth headset between stereo sound and telephone modes
* configure your laptop's audio output (on the fly) between:
- off
- stereo audio with input
- 4 speaker surround sound
- stereo audio with digital output
- digital output with digital input
* Play your game's audio out through the speakers and then chat with people on your usb headset
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
And on that Perfect Setup page you will find the following advice:
Some questions that do 3d6 fire damage
with pulse, it's silent; without sound works
with pulse, it's silent; without sound works
with pulse, it's silent; without sound works
with pulse, it's silent; without sound works
with pulse, it's silent; without sound works
with pulse, it's silent; without sound works
Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.
My experience is as simple as: Without pulse it works, with pulse it doesn't
No, 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
Anyway, for me pulse solved problems and didn't cause any.
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
This is why vendors have to provide drivers for Windows so that stuff "Just Works"--someone worked around the bugs in software for Windows.Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
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.
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
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
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
Some questions that do 3d6 fire damage
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?
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
I would say that "work, just" is more accurate than "just work".
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
Please...(again)...
> 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)...
Please...(again)...
To pick up on one tiny detail:
Systemd and Fedora 14
as Poettering points out: "note the /sbin vs. /bin!"
Why? systemd is a system daemon, so it should be in /sbin, shouldn't it?
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
> be in /sbin, shouldn't it?
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
- 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
Systemd and Fedora 14
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
Systemd and Fedora 14
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
Systemd and Fedora 14
Y'know, because rfkill handles that now. Part of the mac80211 consolidation.
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
http://0pointer.de/public/systemd-man/systemd.service.html
http://0pointer.de/public/systemd-man/systemd.unit.html
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Some things, in text, inevitably look like an undercooked attempt at snarking whether meant entirely sincerely or entirely snarkily.
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
Systemd more robust?
Systemd - What does it really provide?
Systemd - What does it really provide?
Systemd and Fedora 14
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.
Installing both