Weekly Edition
Return to the Development page
| |||||||||||||
Interview with Lennart Poettering (LinuxFR.org)
LinuxFR talks
with Lennart Poettering about his work on Avahi, PulseAudio, and systemd. "You should never forget that in the whole industry there are about 3.5 people paid full-time for doing generic maintainance work of the Linux audio stack (which I consider consisting primarily of ALSA and PulseAudio and a few things around it). With this little manpower I can only say that what has been achieved is pretty good. While we still can't fully match competing audio stacks like CoreAudio, we are a lot closer than we ever were. I do hope that the folks who kept constantly complaining would be a lot more appreciative if they understood that."
(Log in to post comments)
Quality at LWN Posted Jul 6, 2011 4:02 UTC (Wed) by tonyblackwell (subscriber, #43641) [Link]
What a pleasure to read a literate, eloquent and informative discussion. Guess I'm spoilt rotten that it happens to be in my native language as well, which means Lennart's fluency comes across well. Having stumbled across fragments of flame wars mentioned, this is so much better and makes it worth getting up at 5am to read LWN! Thanks Lennart for taking the time to craft such a welcome start to the day.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 10:22 UTC (Wed) by trasz (guest, #45786) [Link]
Just to clarify some FUD: things like USB audio work perfectly well with OSS. Things like mixing and resampling work actually better in FreeBSD OSS than with Linux ALSA, since the latter can't even handle multiple audio streams transparently unless hardware supports it, or unless one uses some userland cludge, not to mention e.g. transparent resampling or parametric equalizer. Supporting UPnP, which Lennart has mentioned, is not the job for kernel.
In short - BSDs don't use ALSA, because it adds lots of bloat without much added functionality. The only reason to use it would be backwards compatibility with Linux, and that actually could happen some day, unless everyone migrates to PulseAudio and stops using ALSA directly.
BSD Posted Jul 6, 2011 11:02 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
The "transparency" you're proclaiming in FreeBSD OSS is achieved by running this tricky CPU-intensive code in Ring 0 even though it doesn't need any special privileges. This is the Wrong Thing so it's prohibited in Linux.
V4L went through this same thing, but sanity prevailed, and today programs use a userspace library to do any conversions or tweaks needed to get data they can understand from cameras which may natively emit a variety of unusual image formats. Do the BSDs still have thousands of lines of buggy YUV to RGB conversion code in their kernels in order that you don't need such a library to read RGB data from a YUV webcam?
BSD Posted Jul 6, 2011 11:09 UTC (Wed) by trasz (guest, #45786) [Link]
It's not that CPU-intensive. On a typical hardware I doubt it's even measurable. And the kernel is preemptible, so it wouldn't matter much anyway. And, if you don't like it, you can disable it. Point is, functionally, there are very few things ALSA does better than OSS, despite lots of added complexity.
I have no idea how the situation looks like with V4L, or any video, for that regard.
BSD Posted Jul 6, 2011 14:45 UTC (Wed) by bronson (subscriber, #4806) [Link]
256 point sync is barely measurable?? Wow, what hardware do you have?
Preemption contributes to latency. That's usually a problem, not a solution.
BSD Posted Jul 6, 2011 14:49 UTC (Wed) by bronson (subscriber, #4806) [Link]
I don't mean to ignite a preemption discussion. My point is only that "just fix it with preemption" is oversimplified and probably won't work.
BSD Posted Jul 6, 2011 18:25 UTC (Wed) by trasz (guest, #45786) [Link]
Could you explain what's the "256 point sync" and how is it related to the preemptiveness of the kernel?
BSD Posted Jul 6, 2011 20:49 UTC (Wed) by bronson (subscriber, #4806) [Link]
oops, I meant sinc of course. Finger habits. Decent quality sinc takes a good chunk of your CPU.
The bit about preemption is a reply to your statement:
> And the kernel is preemptible, so it wouldn't matter much anyway
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 11:03 UTC (Wed) by alankila (subscriber, #47141) [Link]
Eh. ALSA has been doing software mixing, resampling, and equalizing for something like half a decade at least, but I guess it doesn't do it in the kernel and therefore somehow doesn't count. I don't see anything wrong with using a library instead of some /dev node, technically, to handle audio. Most people probably would say that the library approach is the more flexible one.
And PulseAudio itself can't actually replace ALSA any time soon. At least I am not aware of any plans to absorb ALSA's current hardware handling functionality into PulseAudio itself. The beauty, of course, is that it doesn't matter. People could just write PulseAudio applications and leave the hardware handling for it.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 11:20 UTC (Wed) by trasz (guest, #45786) [Link]
Sure it does, but I've seen numerous problems with that in the past. I guess it might be all gone now.
As for replacing ALSA - what I meant was, adding ALSA support in other systems for backward compatibility with Linux only makes sense as long as the software you want to provide compatibility layer to actually uses ALSA directly instead of PulseAudio. With software using PA, one does not the ALSA compatibility layer.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 13:00 UTC (Wed) by alankila (subscriber, #47141) [Link]
Ah. Thanks for clarification -- bad reading from my part.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 11:30 UTC (Wed) by Los__D (guest, #15263) [Link] Just to make up some FUDThere, fixed it for you.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 12:19 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
> Things like mixing and resampling work actually better in FreeBSD OSS [...]
For some definitions of "better" as the OSS interface forces it to do this in the kernel, while the interfaces provided by ALSA/PA allow to delegate this touser-space.
Looking closer an resampling... what resampling strategy do you want to use -- sample duplication/dropping? linear (or higher order polynomial) interpolation? band-limited sinc filter, IIR or FIR? what interface do you support to choose and make quality/latency trade-off? can you account the cpu time used in doing resampling to the process causing it, or does it get accounted to some anonymous real-time kernel process? if the latter, maybe you need some sort of admission control? what interface do you provide to configure that?
Oh, you can't influence anything of the above with OSS, guess why? Maybe the supposed ALSA/PA bloat has something going for it after all...
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 13:07 UTC (Wed) by trasz (guest, #45786) [Link]
Doing it in the kernel does not cause any problems, as mentioned earlier. In addition, it's easier for the system administrator - one less thing to configure.
As for the resampling - FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further? Since, you know, adding useless features and configuration options just because you can is one of the reasons Linux never caught on the desktop, imho.
Also - note that I'm only talking about ALSA, not the "ALSA/PA" combination; you might want to compare the latter to "OSS/PA", though.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:27 UTC (Wed) by alan (subscriber, #4018) [Link]
about the 'one less thing to configure' part. ALSA/PA works very well out of the box. It works flawlessly with my bluetooth headset, picks up the mic and all. Not much configuration needed, beyond pairing my headset.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:01 UTC (Wed) by bronson (subscriber, #4806) [Link]
Are you able to use the controls on the headphones? No matter what obsolete bluez guide I follow, mine seem to be ignored.
For me, bluetooth audio starts stuttering every few hours. killall -9 pulseaudio fixes it. Other than that, yes, PA makes bluetooth easy. That's no small feat!
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:22 UTC (Wed) by drag (subscriber, #31333) [Link]
The controls work passably well on my headphones. At least last time I checked.
One of my favorite capabilities with PA is the ability to migrate and hotplug audio.
I have USB headset (the USB audio is actually separate from the headphones, which is handy), Bluetooth headset, and onboard audio card. It's great to be able to just plug in my headphones and have it 'just work'. Also migrating audio from one device to another is fantastic.
For desktop audio Alsa/PA blows OSS out of the water. No question about it. Despite some of the ugliness.
As long as OSS exposes the timing information from the audio card back out to the applications then I don't see why OSS/PA wouldn't be any worse. Just as long as FreeBSD/Solaris/whatever has the ability to intercept applications trying to use OSS and pipe it back through PA transparently.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:34 UTC (Wed) by bronson (subscriber, #4806) [Link]
> Doing it in the kernel does not cause any problems
I guess you don't count poor CPU accounting and inability to configure it (especially latency) as problems? SYNC should be good enough for everybody?
Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:44 UTC (Wed) by jrigg (subscriber, #30848) [Link]
> Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
Exactly. I've been using Linux for pro audio work for the last six years, thanks to the configuration options provided by ALSA. Desktop and pro audio requirements are mutually exclusive in many respects. In order to cater to both sets of users a certain amount of configurability is necessary.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:28 UTC (Wed) by trasz (guest, #45786) [Link]
FreeBSD OSS allows one to configure audio latencies. I have no idea what "poor CPU accounting" you're talking about. Are you sure you're not extrapolating problems specific to one implementation onto others?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:09 UTC (Wed) by cmccabe (guest, #60281) [Link]
> Linux is starting to make a dent in the professional audio world
> precisely because of these "useless configuration options."
I thought JACK was the reason why Linux was useful in the professional audio world? JACK doesn't seem to be tied to ALSA, since it has OSS, CoreAudio, and other backends in addition to its ALSA backend.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 21:32 UTC (Wed) by jrigg (subscriber, #30848) [Link]
JACK is an important reason but not the only one. ALSA allows multiple interface cards to be treated as a single multi-channel device (using pcm_multi) for example. JACK will only handle one input device and one output device at a time.
OSS might be able to combine multiple interfaces too, but last time I checked it was too limited in other ways to use with my interface hardware (eg. only 48kHz supported on RME MADI cards, no driver available at all for the PCIe version). OSS seems to lag behind ALSA in support for pro level hardware, in my experience.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:32 UTC (Wed) by drag (subscriber, #31333) [Link]
>JACK will only handle one input device and one output device at a time.
No, I don't think that is true at all. I haven't used Jack in a while, but it seems with it's routing capabilities and qjackctl (to enable easy access to those capabilities) it should have no problem at all handling multiple devices.
In a system with using multiple devices at the same time it may become problematic to try to get low latency and multiple simultanous output working with correct timing. Probably need some mechanism to keep the clocks on your sound cards in sync and such things.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:45 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Yes, pro-hardware is capable of using an external clock. So you pick one reference clock and all your gear keeps time with that.
Most consumer hardware does not offer this capability, you will need to investigate nasty hacks if you want to try to strap three cheap PCI soundcards together as an alternative to buying one six channel pro card.
JACK Posted Jul 6, 2011 22:53 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Oh, I forgot to address the actual point you made. No, JACK only works with one device.
If you have several physical devices which are genuinely sync'd you can just use ALSA to weave them together. If they aren't synchronised bad stuff may happen.
The reason for working with one device is that JACK's graph execution goes like this:
1. Interrupt from hardware indicates that, say, 128 frames are ready
If JACK was willing to work with more than one device, which interrupt does it wait for? What does it do with parts of the graph which require data from more than one input device? Or send data to more than one output device?
Lots of complexity, for a corner case no professional audio people care about (they either have only one device, or their devices can be clock-locked and woven into a single virtual device) and no consumers have the gear to test.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 19:32 UTC (Thu) by jrigg (subscriber, #30848) [Link]
I was referring specifically to combining several interfaces of the same type into a single virtual device, eg. using three 8-channel interfaces as a single 24-channel device, or a couple of 64-channel MADI interfaces as a single 128-channel device.
JACK has no trouble working with multiple devices as long as you only want to use one at a time. It can use different devices for capture and playback, but it can't combine several hardware devices into a single virtual device as I described above. That's what the pcm_multi plugin in ALSA is for (and as you mentioned, hardware clock sync is required).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:17 UTC (Wed) by rsidd (subscriber, #2582) [Link]
You know, FreeBSD has many things going for it, but desktop and multimedia applications aren't among them. Last I checked (I believe it was FreeBSD 7 or 8-CURRENT), you could panic it just by jiggling the USB audio cable inadvertently. In fact you could panic it with pretty much any USB device. I have heard that these panics have been fixed, but haven't checked. If not, it rules out FreeBSD for any serious use: on-board audio is in general not good enough for professional use.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
The documentation linked from FreeBSD's own site makes no mention of having fixed this, it's simply listed as a bug in the manual page for the USB audio driver that there is no way to properly handle this case and a panic results.
Perhaps just the documentation snd_uaudio(4) is out of date.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 5:24 UTC (Thu) by rsidd (subscriber, #2582) [Link]
Indeed, now that I think of it, what was claimed to be fixed was the panic when yanking USB mass storage devices. The uaudio problem may well still be around.
The USB flakiness is the reason I stopped using FreeBSD, a few years ago.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 16, 2011 4:58 UTC (Sat) by x0ra (guest, #76826) [Link]
There is still (as of FreeBSD 8.2) all kind of mess with uaudio(4) and the USB stack, under some condition, you can stall the entire stack (very handy when all input are going though USB), which oblige you to reset the machine...
From my pov, the biggest show stopper in FreeBSD is how binary ports are managed (whenever they are).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:57 UTC (Wed) by Karellen (subscriber, #67644) [Link]
"FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further? Since, you know, adding useless features and configuration options just because you can is one of the reasons Linux never caught on the desktop, imho."
Ah - so *that's* why FreeBSD is so much more popular on the desktop!
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:30 UTC (Wed) by trasz (guest, #45786) [Link]
It doesn't work in that direction, I'm afraid. :-)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:30 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
> Doing it in the kernel does not cause any problems, as mentioned earlier. In addition, it's easier for the system administrator - one less thing to configure
If the system administrator has to turn a sysctl knob to choose an interpolation strategy, then that's one more thing to configure, see below.
> As for the resampling - FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further?
sinc filter with which cut-off characteristic exactly?
Depending on the latency requirements you may want a longer or shorter filter. You want a different filter when e.g. going from 32kHz to 44.1kHz than from 32kHz to 48kHz (you can afford more aliasing in the inaudible spectrum).
Do you think moving on-demand filter construction into the kernel is a good idea?
Since latency requirement is something only the application can specify, you want to choose on a per-application basis, and this partially makes it a policy decision (laptop running on battery with lousy internal speakers -> use cheapest method). How do you manage this policy in the kernel?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:19 UTC (Wed) by alankila (subscriber, #47141) [Link]
As an aside:
It's said that for FIR filters, you can select control of phase, frequency response or latency, but not all simultaneously. Typically, SINC kernels are arranged with the best possible frequency response and linear phase characteristics. However, it's possible to give up on the linear phase property to reduce latency.
Normally SINC is a symmetric filter with mirrored halves around its midpoint, and the large values of the kernel occur at the midpoint. Therefore, at 256 taps it causes a delay of about 128 samples, with about 128 samples of ringing around the midpoint of the action of the filter kernel.
A minimum-phase reconstruction of the same filter can probably reduce the latency to just a few dozen taps, because the large values of the sinc kernel are arranged to happen as early as possible in the filter. The ringing, then, takes the rest of the kernel and has somewhat larger amplitude.
I don't think the human ear is sensitive to phase at all, especially at the highest frequencies, so I'd love if more people at least considered minimum phase filters.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 8, 2011 0:52 UTC (Fri) by HenrikH (guest, #31152) [Link]
>I don't think the human ear is sensitive to phase at all
I might be reading you wrong, but the human ear is very sensitive to phase. For example phase is how the old Dolby Surround provided more channels than speakers.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 11, 2011 10:05 UTC (Mon) by alankila (subscriber, #47141) [Link]
Yes, that's not what I meant. Phase is important when it comes to coherence of several channels, but if you process all channels with a similar transformation, people aren't usually able to notice.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:46 UTC (Wed) by trasz (guest, #45786) [Link]
As I said - under what circumstances would that matter? Keep in mind that we're talking about the part of the kernel that allows for several processes to use the audio device at the same time, assuming lack of userland framework such as PA, not about proffessional audio recording. In other words, it's the infrastructure that allows a process go "ping" while some other plays music, not to master a record.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:57 UTC (Wed) by nix (subscriber, #2304) [Link]
Your claim that nobody will ever use FreeBSD's audio infrastructure for professional audio recording may be correct. It is definitely incorrect with respect to Linux. People *do* use it for professional audio work, they *do* care about these things, and they *do* care about minimization of latency. Wishing that it were otherwise, and that everyone was like you and not an audio geek, will not make audio geeks go away.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 7:06 UTC (Thu) by helge.bahmann (subscriber, #56804) [Link]
> As I said - under what circumstances would that matter?
It matters because it means that you need at least two different audio APIs: "bare" OSS hardwired to talking directly to the kernel representation of the audio hardware, and something with a higher-level abstraction that allows to pass through a sophisticated user-space processing framework.
ALSA gives you an interface that behind your back can do both: talk to bare-metal hardware (if for some reason you want to), or have it transparently rerouted through PA. This means that ALSA provides a useful abstraction, while OSS does not at all. (Compare to e.g. OpenGL direct/indirect rendering, its hardware abstraction and what you gain over using libdrm directly).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:13 UTC (Wed) by cortana (subscriber, #24596) [Link]
I'm no particular fan of ALSA, but I don't understand why you automatically say that code running in user space is a kludge.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:39 UTC (Wed) by cladisch (✭ supporter ✭, #50193) [Link]
> things like USB audio work perfectly well with OSS.
The OSS USB audio driver doesn't do capturing well, and lacks support for many vendor-specific, USB 2.0 and USB Audio 2.0 devices.
As long as OSS does not support power management, MIDI, and embedded devices, it cannot even begin to be considered as a replacement for ALSA.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:23 UTC (Wed) by trasz (guest, #45786) [Link]
Which OSS USB audio driver you are talking about, FreeBSD or the cross-platform OSS4?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:50 UTC (Wed) by cladisch (✭ supporter ✭, #50193) [Link]
Sorry, I was indeed talking about the OSS4 implementation; these points do not apply to FreeBSD's.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 9, 2011 11:35 UTC (Sat) by Pawlerson (guest, #74136) [Link]
No, bsd don't use ALSA, because it's a Linux tech. Btw. I can't even play two streams simultaneously on crap like oss. It's legacy not without the reason. ALSA works perfect with my hardware. In the future bsd will become something like emulator software - you will run native Linux programs on top of Linux's emulation layers.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 10:25 UTC (Wed) by trasz (guest, #45786) [Link]
Also, note that talking about comparing "ALSA/PA vs. OSS" doesn't really make sense - it's "ALSA/PA vs. OSS/PA" or "ALSA vs. OSS".
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 13:29 UTC (Wed) by nevets (subscriber, #11875) [Link] Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that. It's fine if people do toy OSes, everybody loves toys after all. But if Debian thinks it should limit its development by the dreamy interest in toy OSes of some of its developers, then this is their problem. If Debian was my project I'd try to focus on making (or keeping) it professionally relevant, and just forget about kFreeBSD, but I am not a Debian Developer.Just reminds me of a comment I read from some Microsoft developer back in 1998 that called Linux a toy OS, and will never amount to anything significant.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 13:46 UTC (Wed) by nix (subscriber, #2304) [Link]
"Professionally relevant" is a nice term as well. What that generally means is "relevant to managers with no technical skills". Why on earth the whims of nontechnical managers should guide the Debian Project is beyond me.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:31 UTC (Wed) by alan (subscriber, #4018) [Link]
hmm? To me 'professionally relevant' means just that, I don't use it in my profession. And that's fine, I generally don't use the same OS on my servers as I use on my desktop. I don't think he meant to diss kFreeBSD's technical merits, only its usefulness as a server OS.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:42 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Well perhaps at some point Debian faces a cross roads, is it a collection of programs that run on any arbitrary operating system kernel a Debian Developer happens to take a fancy to, or is it a Linux distribution.
I won't predict how that debate would go, there's no guessing with Debian.
I thought Lennart's suggestion (Debian is welcome to make all its packages work equally well with both, that's just lots of extra work for little reward) was remarkably even handed.
The BSD reaction to all this is frustratingly reminiscent of talking to old-school UNIX® people in the mid-1990s. No reason, that they saw, for their beloved system to adopt these new-fangled ideas from that not-even-really compatible Linux upstart. And now where are all those UNIX® systems? Sadly a lot of them are now Windows.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:58 UTC (Wed) by raven667 (subscriber, #5198) [Link]
More of them are RedHat
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:08 UTC (Wed) by iabervon (subscriber, #722) [Link]
Actually, I think the most sensible thing to do would be to come up with a way to make init run systemd service units. One big advantage of systemd's format is that it is amenable to being parsed, rather than just executed with arguments; since it can examine what's supposed to be done, a wrapper using a systemd service unit (as the only service-specific part) ought to be able to work about as well as a custom init script. (The main lack being when there is some service-specific method that works for identifying children, which systemd would not need due to using cgroups, and which would therefore not be included in the unit.)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:18 UTC (Wed) by nevets (subscriber, #11875) [Link]
This cgroups thing is what bothers me the most about systemd. It now makes my system require it. If I want to boot a kernel that does not support cgroups or just an older kernel, now my system wont even work. This alone is the one thing keeping me away from systemd.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:25 UTC (Wed) by tuna (guest, #44480) [Link]
What is it that you are planning to do with systemd?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:33 UTC (Wed) by nevets (subscriber, #11875) [Link]
Install it.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:49 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
So you will be relieved that cgroups aren't hard dependencies anymore. Systemd will complain and breakage can occur, but you can run some older kernels. But why would you like to not enable cgroups?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:51 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
because cgroups have a significant amount of overhead on the system right now, so unless I am doing something that needs cgroups, I don't enable them in the kernels that I compile (even the new ones)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:34 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
Just out of curiosity, can you link to any benchmarks or whatnot on the overhead of cgroups? I'm not saying they don't impact things, but am curious if this has actually be quantified using some synthetic benchmarks or whatnot.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I think there have been a number of discussions recently (on the kernel list and on LWN that have talked about the overhead of cgroups (in part because they are bolted on rather than fully integrated.
I could be remembering things incorrectly.
but in any case, as a standard security best practice, if I don't need a feature I don't enable it. This also makes my systems more reliable as there is less code compiled in.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:38 UTC (Wed) by mezcalero (guest, #45103) [Link]
systemd requires only the grouping part of cgroup, i.e. no controllers. The impact of some controllers might be high, but the basic grouping logic is barely measurable.
The people who complain the loudest tend to mix up cgroups with its controllers. I'd prefer if people could make the distinction there. But hey, if people were well informed they probably wouldn't whine that loud. Educated whining?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:30 UTC (Wed) by michich (subscriber, #17902) [Link]
systemd wants a kernel with CONFIG_CGROUPS=y, but it does not care if you have the cgroups-aware scheduler (CONFIG_GROUP_SCHED) or any of the subsystems or resource controllers (they all have distinct kernel config options). I don't think the overhead from CONFIG_CGROUPS alone is significant.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:31 UTC (Wed) by tuna (guest, #44480) [Link]
Well, systemd needs cgroups :)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:33 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
so that sounds like a reason to not use systemd to me.
especially if it's only requirement is that the kernel configure them, but that they don't actually do anything.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:46 UTC (Wed) by raven667 (subscriber, #5198) [Link]
They do do something, the main thing systemd uses them for, which is to identify which processes are related to one another by name and to differentiate between multiple identical processes which belong to different named services.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:53 UTC (Wed) by nevets (subscriber, #11875) [Link]
And that limits me to what kernels I can boot. As a kernel developer, I may not be the focus of Lennart's users, but it totally eliminates me from ever testing his work. If systemd requires that all my kernels must have CGROUPS enabled, then I can't use it. My job requires that I test various configurations, and !CGROUPS is one of them.
Cgroups are still rather new and hasn't matured yet to be something that I would push as a must have for a distro. There is a lot that I do not agree with Lennart, but its OK as long as I am not forced to use it. I'll stick to Fedora 13 for a long time (and Debian on my own computers).
I'm getting a strong feeling that I will soon be having a custom install on all my boxes (no systemd and no gnome3). Well, I may have one box (or partition) that has systemd for testing why it broke.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 10:20 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
As has been pointed several times, systemd doesn't require cgroups and will still boot just fine without it. It won't have all the features that take advantage of cgroups but that is expected.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 11:56 UTC (Thu) by michich (subscriber, #17902) [Link]
I wouldn't say it runs just fine. It runs crippled. The only reason it does not crash immediately is to allow a kernel developer to see if his modified kernel still boots. Please don't use it for more than that. You would not get a good impression of systemd.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 9:07 UTC (Thu) by Karellen (subscriber, #67644) [Link]
Agreed. I've thought it might be interesting to try to write a systemd-unit-file to init-shell-script "compiler".
Some systemd features won't necessarily be available, and the scripts might only work reliably for well-behaved daemons; but then, those features aren't available in current init scripts, and init scripts only work correctly with well-behaved daemons anyway.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:50 UTC (Wed) by trasz (guest, #45786) [Link]
Note that most of the commercial UNIX systems went away because they were bound to the hardware architectures that went away.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:12 UTC (Wed) by nevets (subscriber, #11875) [Link]
Exactly. The reason Linux and Windows did so well was because they ran on $5,000 server quality PCs, whereas IIRC SunOS ran on a $20,000 workstation, and AIX on a $60,000 workstation. The takeover of Linux and windows was more because of the ability to run on cheaper hardware than being a better OS.
I contracted at IBM Federal Systems when it was sold to Loral, and the first thing we did was dump the AIX systems for Sun, because of the price. Not because Sun was better than AIX. I personally thought AIX was better than Sun, but not worth that much of a price difference.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:54 UTC (Wed) by dmarti (subscriber, #11625) [Link]
There were lots of "PC Unix" OS products out there, with hardware requirements pretty close to those of decent Linux servers.
http://www.catb.org/~esr/faqs/clone-unix-guide.txt
Most of them sank without a splash pretty quickly once you could get stable, supported Linux.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 5:02 UTC (Thu) by martinfick (subscriber, #4455) [Link]
One of those was even called Solaris. :)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 11:52 UTC (Thu) by nevets (subscriber, #11875) [Link]
I remember them trying out SCO's PC Unix, but it had lots of issues, and could not handle what was needed. Eventually, they switched most of the Unix boxes over to Windows (not Linux).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 13:26 UTC (Thu) by pabs (subscriber, #43278) [Link]
Personally I'd like to see Debian GNU/Any happen one day:
http://hadrons.org/~guillem/debian/ports/gnu-any/debian-g...
One architecture, install and set of packages, reboot into any kernel you prefer and glibc will handle it for you. Obviously there will be things that bypass glibc or hard-code sysfs paths so it wouldn't be perfect, but it would be interesting.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 9, 2011 11:43 UTC (Sat) by Pawlerson (guest, #74136) [Link]
BSD was before Linux, so your comparison is flawed. BSD is really a toy in many areas compared to Linux.
Poisonous people Posted Jul 16, 2011 13:14 UTC (Sat) by paravoid (subscriber, #32869) [Link]
I'm really amazed at reading about the "poisonous people" that Lennart has to go through.
A nice advice on not having to deal with them is avoid speaking like a troll and saying things like "toy OS", "try to hack with only Linux in mind" and marketing-level comparisons of SysV init, upstart & systemd with claims such as "Interfacing via D-Bus: No".
Poisonous people Posted Jul 17, 2011 16:59 UTC (Sun) by jospoortvliet (subscriber, #33164) [Link]
haha
yes, I was surprised by that comment too. He shouldn't complain about flamewars as he attracts them like crap attracts flies :D
I surely don't mind his communication style and think it's both fun and useful but it obviously attracts flamewars...
|
|||||||||||||