Systemd 199 Has Its Own D-Bus Client Library

[ceage]

Correct me if I'm wrong but to my understanding PulseAudio uses alsa-lib to interact with the kernel. However ALSA doesn't do mixing in the kernel so in any case you need to add additional mixer on top of it (you also need one for networked audio, audio processing and such that PulseAudio also does). Peope who refer to "plain ALSA" probably mean the mixer shipped with alsa-plugins called dmix.

Strictly speaking, the ALSA related modules from libpulse use a tiny part of alsalib (the daemon itself doesn't), but that's only because alsa-lib is the way to do basic stuff like device enumeration and querying the kernel about the (sound) hardware capabilities, and because PA knows it's not alone in the world (and won't be for some time). It doesn't use the heavyweight stuff from alsalib (e.g. the whole plugin system).

Anyway, from a typical app developer's perspective it was wrong from the beginning to write against alsa-lib. It's no surprise that people kept doing it though, considering how the whole Linux ecosystem works. It wasn't their fault that there was no better standard way. Just as it's not Lennart's fault that all the other sound servers failed at becoming standard. Because a general purpose operating system really needs such a mechanism. I think users should be happy about the fact that PulseAudio seems to be a good enough design (bugs aside) to become the standard for doing sound on Linux

[ninez]

There is more to Jack than the Daemon (jackd), smartass. It is part of the Kernel, because there is active support for its user-space-implementation. It is as if you were stating udev wasn't part of the Kernel only because it is just the user-space tool to manage the /dev-FS (which is explicitly right, but implicitly wrong).
This stands in sharp contrast to PulseAudio, which is not endorsed by the Kernel; that makes me feel warm inside .

First off, presumptuous *asshole* -> i wasn't being a smartass ~ just stating a fact. Jack is a user-space application.
Sure, some changes were made to ALSA to improve support (which is no surprise since it's alsa's job to handle sound on the linux platform @ the lower levels), but that still does not change the fact that Jack is a user-space application.

EDIT: You can come back and claim it is in the kernel - when i have to compile a jack kernel module, k? - until then, you are wrong, plain and simple.

[cjcox]

Q: What's your view on systemd? [...]

Linus Torvalds: I actually like a lot of what systemd does. My personal biggest issue with systemd is: the people involved seem to think that change is good for it's own sake. I've seen Lennart Poettering, for example, talking about how something is bad because it's something that has been done for thirty years, and old is by definition bad. Which makes no sense at all to me because I'm saying if it's been working for thirty years, it's clearly doing something right. This is my standpoint while some of the systemd people have the exact opposite, which is saying ``If it's been working that way for thirty years, it's about time we changed it.'' That mentality makes me very nervous. They seem to sometimes make changes for the sake of changes and worry less about what people are used to. That's probably why systemd has generated so much negative feedback, because it takes people out of their comfort zones and doesn't feel bad about that at all. At the same time I think, a lot of what it does is interesting. So I'm a bit nervous about the development model and willingness to break things, which I think is a huge mistake, but I do think that it's showing a lot of promise.

http://bambuser.com/v/3084584

Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

[duby229]

LP has already said that was his primary focus. What did he call it? I think he called it "Vertical Integration"

[GreatEmerald]

Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

But it worked out fine in the end, did it not?

Also, no, I don't follow. What do closed-source solutions have to do with all that?

[Teho]

But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for.

What exactly are you referring to?

Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

What things were ignored? What promises were made? What things can't be done well with systemd? What worse hacks are you referring to? What is wrong with the sysvinit script compatibility mode?

There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though.

What kind of stability problems is systemd having? What large companies are you referring to?

It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

What do you mean? What closed solutions? What closed source software? How is systemd responssible for them?

Try to give some examples. Your posts is so vague that it doesn't really tell anything to anybody.

[liam]

Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

Oh, yes, I'm SURE RH isn't looking at systemd for use in enterprise settings
For instance, I'm sure they haven't been doing this for sometime.

[Ericg]

Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

Huh? What Teho said. Systemd started because launchd wasn't under a GPL-compatible license (Apple relicensed it a few months later from the Apple license to the MIT or Apache license) and the only reason launchd was being looked at was because Lennart believed it was wrong to push the hard tasks, such as dependency resolution and parallelization to the clients (services) in init.

What promises were made?

"Scope creep" in comparison to its original goal of "a new, better, init." Sure. But the systemd devs were very clear and open about the fact that they moved from an "init system" as their goal, to more of a suite of tools to cover the groundwork of a linux distro.

Large companies with knives waiting for systemd to stabilzie? Huh? I dont follow you on that at all o.O

What closed solutions are you talking about as well...? Systemd is under the LGPL or GPL

[Teho]

Systemd started because launchd wasn't under a GPL-compatible license (Apple relicensed it a few months later from the Apple license to the MIT or Apache license)...

I think you are confusing systemd and Upstart.

The Ubuntu Linux distribution considered using launchd in 2006. However, launchd was rejected as an option because it was released under the Apple Public Source License ? which at the time was described as an "inescapable licence problem".[5] Ubuntu instead developed and switched to Upstart, its own service management tool.
In August 2006, Apple relicensed launchd under the Apache License, Version 2.0 in an effort to make adoption by other open source developers easier.[6] However, most common open source operating systems use systemd or continue with init instead.

-Wikipedia

[Ericg]

I think you are confusing systemd and Upstart.



-Wikipedia

Whoops, thanks for the correction Teho. I was thinking of: http://0pointer.de/blog/projects/systemd.html where LP talked about being inspired by launchd, not using it.