Submitted by Via LWN: “Lennart Poettering has put up a lengthy post describing the ‘systemd’ project, which is creating a new init system. The whole thing is an interesting discussion of how system initialization should work. Upstart maintainer Scott James Remnant has posted a response to the announcement.”
Why not use launchd? It was written by Apple for OSX, but is licensed under the Apache license. It is far more sophisticated than init, replacing cron, inetd, and other old crusty daemons, doing a better job in most cases. It uses textfiles for configuration like a good UNIX citizen. I’m honestly surprised it hasn’t garnered more attention in the Linux/BSD community. Some info:
http://developer.apple.com/macosx/launchd.html
http://en.wikipedia.org/wiki/Launchd
http://developer.apple.com/mac/library/documentation/Darwin/Referen…
The article does answer that.
The article points out a few shortcomings in launchd, but admits it does most of what he wants just fine. His only concrete objections are (1) not all existing daemons would be compatible with launchd, and (2) launchd is not flexible enough to do everything he can conceive.
I believe it would be wiser to use a working, release-quality codebase than to write something from scratch. If more backwards compatibility is needed, it would be much simpler to add this functionality to launchd – there is nothing in its architecture to prevent this. And to answer his second objection, sure, launchd is not perfect, but it’s much, much better than init/cron/inetd/xinetd/whatever.
Plus, if Linux adopted launchd, daemons could be written to be compatible with both Linux and OS X, and developers from both communities could contribute to the further development of launchd. Both OSs would benefit from sharing an open standard.
Well talk in cheap and the blog does talks about the advantage of being platform specific. If you want to talk to the author and get to know more details, the blog post is open for comments 🙂
He also says that launchd is a bit Mac specific.
If systemd had not been written yet, maybe it would have been easier to adapt launchd. However, systemd already works reasonably well, and it might take less work to complete systemd than to adapt launchd to Linux.
I agree. However, the daemon requirements for systemd and launchd are very similar, and it should take little or no work to make daemons work on both systems.
To modify launchd, they would either have to fork it or co-operate with Apple. It may be that Linux-specific modifications are not something they want in Apple codebase.
Yes, launchd at the moment is heavily dependent on OS X frameworks. Even though it’s the core system process, it still makes heavy use of OS X APIs and libraries, and porting it to Linux would be quite the task.
Poedring, go away! Seriously, every time we use something that works, Poedring comes out with something else to totally fcuk our systems up for years while he makes users beta test it, all the time encouraging distributors to adopt a system that’s not ready for launch and somehow managing to foist it on everyone. Pulseaudio anyone? Sure it works pretty well now, but how many years of user testing did it take to get there? Maybe if there was more concentration on the desktop side of things and less on re-inventing what is already there and while old it does still work perfectly, we’d have OS X-like integration of the frameworks in GNOME and a better experience all around? What’s with this NIH, Poedring?
It’s Poettering. I think the problem is that we don’t have enough guys like this; too many in Linux community are content with “if it’s not broken, don’t fix it”, which is fine for today but sabotages our glorious tomorrow ;-).
Too many. And I’m not sure it’s there even now (in the sense that audio doesn’t “just work” in KDE).
It’s not a zero-sum game; while Lennart and his cronies are messing with lower level of the stack, others can go on developing the Gnome desktop.
Too many. And I’m not sure it’s there even now (in the sense that audio doesn’t “just work” in KDE). [/q]
To be fair, that sounds like a KDE problem to me. I can use it just fine with GNOME, XFCE, and LXDE though it took far too long to get to this point considering how gung ho everyone was to rushing it into the mainstream desktop distros.
Fedora 13 has PulseAudio integration with KDE
http://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration
It has been merged upstream and is part of KDE 4.4 release.
So with “every time” you mean that it has happened exactly one time before?
That sounds a little bit harsh don’t you think?
Lennart Poettering is a smart guy with a vision. Sure, pulseaudio has had it’s bad moments, but it’s getting there.
And you forget Avahi. Avahi is a very, very good implementation of Zeroconf/Bonjour. If it wasn’t for Avahi we didnt’ have a good implementation on linux.
I found his post about systemd very interesting. It sound to me like a very well thoughtout plan.
Well now. Audio on Linux was already a real mess before Lennart created Pulseaudio. And there were a lot of things that were simply impossible. Like switching your app’s audio on the fly to hardware you just plugged in. Proper bluetooth headset support. Doing ssh -X and having mplayer play audio and video over the network. All things I use regularly (yes even remote AV – my old laptop doesn’t have the cpu for h264 video, but plenty of bandwith), all stuff that I couldn’t do before.
So maybe it took a while to get here, and Pulseaudio had problems while it was being tested by consecutively wider groups of users with more varied hardware and software combinations.
But we’re in a much better place now than before Pulseaudio was here, and Lennart did all this work and just kept improving it while taking a boatload of flak from users. I’m not sure I wouldn’t have taken my marbles and gone home if I had been in his position – he’s got my respect.
Actually, all of what you mentioned was possible before Pulseaudio… guess how? OSS4! But oh no, we couldn’t do that, NIH and pride of course so we had to think of something incompatible with every other *NIX out there, with higher latency, years of instability, and software incompatibility. Everything already worked with OSS 4, as the API has been stable for years. Nothing at first, and I do mean nothing, worked with Pulseaudio properly and many things *still* don’t.
ALSA is a mess, absolutely. But Pulseaudio doesn’t fix that, it just sort of helps gloss over ALSA’s issues. Even now Pulseaudio doesn’t work properly with some hardware, try it with an emu10k1 based card like the SB Live or Audigy2 (still a lot of those around, they’re good cards). Some of the few cards that actually have an awesome ALSA driver, and Pulseaudio plays horribly with them.
Linux audio needed a cleaning up. That is for certain. But Poettering didn’t clean it up, he just buried the mess down deeper beneath yet another abstraction layer. Guess what? Now it’s even messier than it once was.
OSS4? So… you’re advocating doing floating point in kernel space? Because that’s what’s implied with in-kernel mixing and floating point audio formats.
ALSA might have a difficult API – but from what I understand it’s just good at exposing the hardware (features) that are there.
And how does OSS4 deal with user-space audio drivers like for Firewire Audio, or Bluetooth A2DP? How should it do in-kernel mixing for those?
Pulseaudio pushes the stack more – it deals with dynamic latency requests and power management and lots of other things. Things up and down the stack often made wrong assumptions, and got away with it because no software ever pushed it hard. If anything, pulseaudio forced them to confront this, and improve the quality across the board (similar to how NetworkManager forced the wireless network drivers to improve).
What you’re advocating is ripping out ALSA and pushing OSS4 in the kernel upstream, right? And then you’d hope to adapt the layers above it so they have similar features than what we have now. All the while hoping that when OSS4 is pushed harder, no evolution or redesign is needed to support certain features.
You don’t think this process would cause at least as much or – more likely – even more pain as what we’ve been through with Pulseaudio?
I don’t believe so.
Not exactly a ringing endorsement. Pulse ended up f–king it up even more, and there will be many applications that will simply not work with it. Ever. They will work with OSS however because that has proper OSS -> ALSA and ALSA -> OSS support and has done for a long time.
Not to mention the unbelievable latency that Pulse has for many popular desktop applications that will never go away.
No one gives a f–k unless sound reliably comes out of peoples’ speakers every time. Really.
Edited 2010-05-02 22:25 UTC
Across several machines and distributions, I haven’t noticed any significant latency with PulseAudio in some time. And its pretty much always had significantly less latency than ESD, where the delay often was noticable.
Sound “just works” — it just comes out of my PC speakers — both with my Sidux Linux desktop and my Fedora 13 laptop, both with Pulse. Pulse is a huge improvement over ESD, which was itself a huge improvement over bare ALSA. IMHO, anyway.
I freely admit that I’m not an audiophile, but for my casual needs, Pulse has worked pretty well.
Most of Pulseaudio’s latency issues remaining are in the area of recording, not playing audio. A quick test you can perform is to use a Pulseaudio-aware SIP client, such as Empathy in GNOME 2.30 or SFLphone. Make sure, if necessary, that the client is set up to use Pulseaudio (not necessary in Empathy). Call any SIP test number you want. Do this once on a machine running Pulse, and once on a machine without it (running any OS you choose). The latency issues will become quite clear then. SIP and other VOIP software are useable, but there’s a more noticeable delay with Pulseaudio in play unfortunately.
All of the problems in Linux audio are in ALSA.
However, instead of fixing ALSA, another layer was added on top.
How does adding yet another layer on top of a crappy foundation make things better?
I’m going to be ignorant today and ask what the problems are with ALSA? It’s always worked fine for me, but all I do is listen to music or videos. I’ve never done any audio recording work. Is that where all the problems are?
Well, on the programming side though users won’t care, ALSA”s API is ridiculously verbose and complex. OSS is much simpler and actually much more portable as all the standard *NIX oses use a version of the OSS API.
On the user side though, the main problem involves Dmix which is the software mixing layer. It doesn’t handle resampling properly so unless your card does you can get interesting results. For example, say you’re listening to music and then you pull open a Youtube page while forgetting to shut your music off. If your audio hardware doesn’t handle resampling gracefully (and many new cards are so dumb they let everything be done software side) one of two things will happen. Either your music will be degraded, typically forcing you to shut down your music player and start it back up, or the lower khz audio (such as most on Youtube) will be severely distorted. Dmix has no resampling beyond the very basic since the kernel devs don’t want it implemented. Pulseaudio actually does solve this by properly doing the resampling and mixing before the ALSA driver actually gets it. It’s still clunky though, this should be done in the actual libasound library if the kernel devs don’t want it in the drivers directly. OSS4 has had this crap sorted for years, and obviously Windows and OS X have as well.
The other troubles involve low latency audio editing, this is where you often need to install jack. The ALSA drivers don’t always stop audio exactly when you tell them to, it’s a few ms later. It’s not a big deal to users (you can’t even notice it really), but when doing audio editing a few ms means the difference between a smooth transition and a nasty click or other artifact.
I think it would be better the focus on Upstart. It has already matured a little and the transition to upstart on Ubuntu IMHO was painless.
Pulseaudio was a painful transition that I would not like to repeat with the boot process. However, since Ubuntu 10.04, Pulseaudio is fine in my experience. Even Wine now has skip free audio!
Sure was. I won’t forget the time several years back when I first tried Ubuntu and wanted to change something in /etc/inittab… and got quite a shock to see it wasn’t there. Everything up to that point had behaved as expected, so to find it wasn’t init but upstart was surprising.
The trouble with Pulseaudio, even though it now works for probably 90% of users (including me), is that it doesn’t actually correct the mess plaguing Linux audio. The half-slapped together mess that is ALSA is still there and can still break, and is still nonstandard from every other *nix. The ALSA API is a mess (very few programs target Pulse directly like they should), volume control is a mess being split between Pulseaudio’s volume and the actual mixer controls of your audio card making it rather awkward to set up your mic and capture with a lot of cards, recording still has latency issues which can affect voip call quality. It seems like they were focused at first on features and later on quality. I’d have preferred snappy recording to the ability to move my streams around, especially given how common voip is and how very recently most voip software even became useable with Pulseaudio at all. The mess needs to be eliminated, not hidden under layers.
This is proof that changing init systems does not have to be as painful as changing audio systems. Systemd definitely has a superior design to Upstart, so I think it would be reasonable to switch to Systemd within a few years. Almost no one would ever notice.
I don’t like PulseAudio’s design at all, but it the implementation has been getting much better. Personally, I haven’t had any issues since Ubuntu 9.04. I think the real problem was that distros shipped it too fast, not that PuleAudio is a piece of junk.
Please make sure people can hand edit /etc/inittab!!
Not the stuff AIX makes you do with chitab/mkitab commands. Accidently editing /etc/inittab with vi on some AIX boxes forces you to reboot (at least thats what my admins say the solution is) because the OS and the inittab get out of sync. Yuck.
Who uses inittab anymore and why? Every sysvinit-based Linux system I’ve used uses more advanced mechanisms than inittab to handle services (Gentoo’s OpenRC system I find to be particularly nice). inittab is to be left alone and good riddance, I say.
Why inittab? My work has linux, SCO 5, HP, AIX, Solaris, and more. They all work with inittab (well except AIX who gets lost if you dont do it a certain way).
Set your deamon to respawn.. and boom, its running even across reboots and sig-11s.
Blu-ray is a very popular format at now,especially you want to convert them to hd movies.Do you want to [url=http://www.bluray-rippers.com/blu-ray-to-mpeg.html] convert blu-ray to mpeg[/url],
and don’t know [url=http://www.bluray-rippers.com/blu-ray-to-mpeg.html]how to convert blu-ray to mpeg[/url],please don’t worry.I want to share an article with you that [url=http://www.bluray-rippers.com/blu-ray-to-mpeg.html]how to convert blu-ray to mpeg[/url].