Linked by Thom Holwerda on Fri 30th Apr 2010 18:41 UTC, submitted by diegocg
Linux 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."
Order by: Score:
launchd
by foobaz on Fri 30th Apr 2010 19:44 UTC
foobaz
Member since:
2009-12-05

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...

Reply Score: 3

RE: launchd
by Rahul on Fri 30th Apr 2010 20:00 UTC in reply to "launchd"
Rahul Member since:
2005-07-06

The article does answer that.

Reply Score: 4

RE[2]: launchd
by foobaz on Fri 30th Apr 2010 20:39 UTC in reply to "RE: launchd"
foobaz Member since:
2009-12-05

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.

Reply Score: 3

RE[3]: launchd
by Rahul on Fri 30th Apr 2010 20:46 UTC in reply to "RE[2]: launchd"
Rahul Member since:
2005-07-06

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 :-)

Reply Score: 1

RE[3]: launchd
by Zifre on Fri 30th Apr 2010 21:12 UTC in reply to "RE[2]: launchd"
Zifre Member since:
2009-10-04

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.

He also says that launchd is a bit Mac specific.

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.

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.

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.

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.

Reply Score: 2

RE[3]: launchd
by vivainio on Fri 30th Apr 2010 22:18 UTC in reply to "RE[2]: launchd"
vivainio Member since:
2008-12-26


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.


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.

Reply Score: 3

RE[4]: launchd
by darknexus on Sat 1st May 2010 06:08 UTC in reply to "RE[3]: launchd"
darknexus Member since:
2008-07-15

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.

Reply Score: 2

Poedring
by darknexus on Sat 1st May 2010 06:12 UTC
darknexus
Member since:
2008-07-15

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?

Reply Score: 8

RE: Poedring
by vivainio on Sat 1st May 2010 07:26 UTC in reply to "Poedring"
vivainio Member since:
2008-12-26

Poedring, go away!


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 ;-).

Pulseaudio anyone? Sure it works pretty well now, but how many years of user testing did it take to get there?


Too many. And I'm not sure it's there even now (in the sense that audio doesn't "just work" in KDE).

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 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.

Reply Score: 3

RE[2]: Poedring
by darknexus on Sat 1st May 2010 09:26 UTC in reply to "RE: Poedring"
darknexus Member since:
2008-07-15

Pulseaudio anyone? Sure it works pretty well now, but how many years of user testing did it take to get there?


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.

Reply Score: 2

RE[3]: Poedring
by Rahul on Sat 1st May 2010 09:59 UTC in reply to "RE[2]: Poedring"
Rahul Member since:
2005-07-06

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.

Reply Score: 2

RE: Poedring
by Soulbender on Sat 1st May 2010 08:49 UTC in reply to "Poedring"
Soulbender Member since:
2005-08-18

So with "every time" you mean that it has happened exactly one time before?

Reply Score: 3

RE: Poedring
by DirtyHarry on Sat 1st May 2010 17:22 UTC in reply to "Poedring"
DirtyHarry Member since:
2006-01-31

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.

Reply Score: 3

RE: Poedring
by obi_oni on Sun 2nd May 2010 06:13 UTC in reply to "Poedring"
obi_oni Member since:
2006-02-15

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.

Reply Score: 3

RE[2]: Poedring
by darknexus on Sun 2nd May 2010 09:35 UTC in reply to "RE: Poedring"
darknexus Member since:
2008-07-15

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.

Reply Score: 6

RE[3]: Poedring
by obi_oni on Wed 5th May 2010 23:58 UTC in reply to "RE[2]: Poedring"
obi_oni Member since:
2006-02-15

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.

Reply Score: 1

RE[2]: Poedring
by segedunum on Sun 2nd May 2010 22:23 UTC in reply to "RE: Poedring"
segedunum Member since:
2005-07-06

Well now. Audio on Linux was already a real mess before Lennart created Pulseaudio.

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.

Doing ssh -X and having mplayer play audio and video over the network.

No one gives a f--k unless sound reliably comes out of peoples' speakers every time. Really.

Edited 2010-05-02 22:25 UTC

Reply Score: 4

RE[3]: Poedring
by boldingd on Mon 3rd May 2010 21:45 UTC in reply to "RE[2]: Poedring"
boldingd Member since:
2009-02-19

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.

Reply Score: 2

RE[4]: Poedring
by darknexus on Mon 3rd May 2010 21:58 UTC in reply to "RE[3]: Poedring"
darknexus Member since:
2008-07-15

Across several machines and distributions, I haven't noticed any significant latency with PulseAudio in some time.


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.

Reply Score: 2

RE[2]: Poedring
by phoenix on Mon 3rd May 2010 04:10 UTC in reply to "RE: Poedring"
phoenix Member since:
2005-07-11

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?

Reply Score: 2

RE[3]: Poedring
by siride on Mon 3rd May 2010 14:07 UTC in reply to "RE[2]: Poedring"
siride Member since:
2006-01-02

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?

Reply Score: 2

RE[4]: Poedring
by darknexus on Mon 3rd May 2010 16:35 UTC in reply to "RE[3]: Poedring"
darknexus Member since:
2008-07-15

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.

Reply Score: 2

Upstart
by aaronb on Sun 2nd May 2010 16:03 UTC
aaronb
Member since:
2005-07-06

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!

Reply Score: 2

RE: Upstart
by darknexus on Sun 2nd May 2010 16:25 UTC in reply to "Upstart"
darknexus Member since:
2008-07-15

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.

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.

Reply Score: 2

RE: Upstart
by Zifre on Sun 2nd May 2010 23:42 UTC in reply to "Upstart"
Zifre Member since:
2009-10-04

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.

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.

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!

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.

Reply Score: 2

Comment by defdog99
by defdog99 on Mon 3rd May 2010 13:42 UTC
defdog99
Member since:
2006-09-06

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.

Reply Score: 1

RE: Comment by defdog99
by siride on Mon 3rd May 2010 14:06 UTC in reply to "Comment by defdog99"
siride Member since:
2006-01-02

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.

Reply Score: 2

Comment by defdog99
by defdog99 on Mon 3rd May 2010 14:48 UTC
defdog99
Member since:
2006-09-06

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.

Reply Score: 1

blu ray to mpeg
by angelabarbara2010 on Tue 4th May 2010 08:05 UTC
angelabarbara2010
Member since:
2010-05-04

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].

Reply Score: 1