Interview with Lennart Poettering (LinuxFR.org)
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."
Posted Jul 6, 2011 4:02 UTC (Wed)
by tonyblackwell (guest, #43641)
[Link]
Posted Jul 6, 2011 10:22 UTC (Wed)
by trasz (guest, #45786)
[Link] (44 responses)
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.
Posted Jul 6, 2011 11:02 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
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?
Posted Jul 6, 2011 11:09 UTC (Wed)
by trasz (guest, #45786)
[Link] (4 responses)
I have no idea how the situation looks like with V4L, or any video, for that regard.
Posted Jul 6, 2011 14:45 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (3 responses)
Preemption contributes to latency. That's usually a problem, not a solution.
Posted Jul 6, 2011 14:49 UTC (Wed)
by bronson (subscriber, #4806)
[Link]
Posted Jul 6, 2011 18:25 UTC (Wed)
by trasz (guest, #45786)
[Link] (1 responses)
Posted Jul 6, 2011 20:49 UTC (Wed)
by bronson (subscriber, #4806)
[Link]
The bit about preemption is a reply to your statement:
> And the kernel is preemptible, so it wouldn't matter much anyway
Posted Jul 6, 2011 11:03 UTC (Wed)
by alankila (guest, #47141)
[Link] (2 responses)
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.
Posted Jul 6, 2011 11:20 UTC (Wed)
by trasz (guest, #45786)
[Link] (1 responses)
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.
Posted Jul 6, 2011 13:00 UTC (Wed)
by alankila (guest, #47141)
[Link]
Posted Jul 6, 2011 11:30 UTC (Wed)
by Los__D (guest, #15263)
[Link]
Posted Jul 6, 2011 12:19 UTC (Wed)
by helge.bahmann (subscriber, #56804)
[Link] (26 responses)
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...
Posted Jul 6, 2011 13:07 UTC (Wed)
by trasz (guest, #45786)
[Link] (25 responses)
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.
Posted Jul 6, 2011 14:27 UTC (Wed)
by alan (guest, #4018)
[Link] (2 responses)
Posted Jul 6, 2011 15:01 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (1 responses)
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!
Posted Jul 6, 2011 15:22 UTC (Wed)
by drag (guest, #31333)
[Link]
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.
Posted Jul 6, 2011 14:34 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (8 responses)
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."
Posted Jul 6, 2011 17:44 UTC (Wed)
by jrigg (guest, #30848)
[Link]
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.
Posted Jul 6, 2011 18:28 UTC (Wed)
by trasz (guest, #45786)
[Link]
Posted Jul 6, 2011 20:09 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (5 responses)
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.
Posted Jul 6, 2011 21:32 UTC (Wed)
by jrigg (guest, #30848)
[Link] (4 responses)
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.
Posted Jul 6, 2011 22:32 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
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.
Posted Jul 6, 2011 22:45 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
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.
Posted Jul 6, 2011 22:53 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Jul 7, 2011 19:32 UTC (Thu)
by jrigg (guest, #30848)
[Link]
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).
Posted Jul 6, 2011 15:17 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (3 responses)
Posted Jul 6, 2011 22:08 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Perhaps just the documentation snd_uaudio(4) is out of date.
Posted Jul 7, 2011 5:24 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (1 responses)
The USB flakiness is the reason I stopped using FreeBSD, a few years ago.
Posted Jul 16, 2011 4:58 UTC (Sat)
by x0ra (guest, #76826)
[Link]
From my pov, the biggest show stopper in FreeBSD is how binary ports are managed (whenever they are).
Posted Jul 6, 2011 15:57 UTC (Wed)
by Karellen (subscriber, #67644)
[Link] (1 responses)
Ah - so *that's* why FreeBSD is so much more popular on the desktop!
Posted Jul 6, 2011 18:30 UTC (Wed)
by trasz (guest, #45786)
[Link]
Posted Jul 6, 2011 16:30 UTC (Wed)
by helge.bahmann (subscriber, #56804)
[Link] (6 responses)
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?
Posted Jul 6, 2011 17:19 UTC (Wed)
by alankila (guest, #47141)
[Link] (2 responses)
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.
Posted Jul 8, 2011 0:52 UTC (Fri)
by HenrikH (subscriber, #31152)
[Link] (1 responses)
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.
Posted Jul 11, 2011 10:05 UTC (Mon)
by alankila (guest, #47141)
[Link]
Posted Jul 6, 2011 18:46 UTC (Wed)
by trasz (guest, #45786)
[Link] (2 responses)
Posted Jul 6, 2011 22:57 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jul 7, 2011 7:06 UTC (Thu)
by helge.bahmann (subscriber, #56804)
[Link]
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).
Posted Jul 6, 2011 17:13 UTC (Wed)
by cortana (subscriber, #24596)
[Link]
Posted Jul 6, 2011 17:39 UTC (Wed)
by cladisch (✭ supporter ✭, #50193)
[Link] (2 responses)
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.
Posted Jul 6, 2011 18:23 UTC (Wed)
by trasz (guest, #45786)
[Link] (1 responses)
Posted Jul 6, 2011 20:50 UTC (Wed)
by cladisch (✭ supporter ✭, #50193)
[Link]
Posted Jul 9, 2011 11:35 UTC (Sat)
by Pawlerson (guest, #74136)
[Link]
Posted Feb 22, 2023 9:44 UTC (Wed)
by JeffBai (guest, #103577)
[Link] (1 responses)
Posted Feb 22, 2023 20:36 UTC (Wed)
by MrWim (subscriber, #47432)
[Link]
1999 FreeBSD switched to oss
12 years later: trasz comments online about oss
12 years after that: you reply to trasz’ comment
Posted Jul 6, 2011 10:25 UTC (Wed)
by trasz (guest, #45786)
[Link]
Posted Jul 6, 2011 13:29 UTC (Wed)
by nevets (subscriber, #11875)
[Link] (30 responses)
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.
Posted Jul 6, 2011 13:46 UTC (Wed)
by nix (subscriber, #2304)
[Link] (26 responses)
Posted Jul 6, 2011 14:31 UTC (Wed)
by alan (guest, #4018)
[Link]
Posted Jul 6, 2011 14:42 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (24 responses)
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.
Posted Jul 6, 2011 15:58 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Jul 6, 2011 16:08 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (16 responses)
Posted Jul 6, 2011 16:18 UTC (Wed)
by nevets (subscriber, #11875)
[Link] (14 responses)
Posted Jul 6, 2011 17:25 UTC (Wed)
by tuna (guest, #44480)
[Link] (1 responses)
Posted Jul 6, 2011 17:33 UTC (Wed)
by nevets (subscriber, #11875)
[Link]
Posted Jul 6, 2011 17:49 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (11 responses)
Posted Jul 6, 2011 17:51 UTC (Wed)
by dlang (guest, #313)
[Link] (10 responses)
Posted Jul 6, 2011 18:34 UTC (Wed)
by SEJeff (guest, #51588)
[Link] (2 responses)
Posted Jul 6, 2011 19:02 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Jul 6, 2011 22:38 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link]
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?
Posted Jul 6, 2011 19:30 UTC (Wed)
by michich (guest, #17902)
[Link]
Posted Jul 6, 2011 20:31 UTC (Wed)
by tuna (guest, #44480)
[Link] (5 responses)
Posted Jul 6, 2011 20:33 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
especially if it's only requirement is that the kernel configure them, but that they don't actually do anything.
Posted Jul 6, 2011 20:46 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Jul 6, 2011 20:53 UTC (Wed)
by nevets (subscriber, #11875)
[Link] (2 responses)
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.
Posted Jul 7, 2011 10:20 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Jul 7, 2011 11:56 UTC (Thu)
by michich (guest, #17902)
[Link]
Posted Jul 7, 2011 9:07 UTC (Thu)
by Karellen (subscriber, #67644)
[Link]
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.
Posted Jul 6, 2011 18:50 UTC (Wed)
by trasz (guest, #45786)
[Link] (4 responses)
Posted Jul 6, 2011 19:12 UTC (Wed)
by nevets (subscriber, #11875)
[Link] (3 responses)
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.
Posted Jul 6, 2011 19:54 UTC (Wed)
by dmarti (subscriber, #11625)
[Link] (2 responses)
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.
Posted Jul 7, 2011 5:02 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
Posted Jul 7, 2011 11:52 UTC (Thu)
by nevets (subscriber, #11875)
[Link]
Posted Jul 7, 2011 13:26 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
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.
Posted Jul 9, 2011 11:43 UTC (Sat)
by Pawlerson (guest, #74136)
[Link] (2 responses)
Posted Jul 16, 2011 13:14 UTC (Sat)
by paravoid (subscriber, #32869)
[Link] (1 responses)
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".
Posted Jul 17, 2011 16:59 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link]
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...
Quality at LWN
Interview with Lennart Poettering (LinuxFR.org)
BSD
BSD
BSD
BSD
BSD
BSD
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Just to make up some FUDInterview with Lennart Poettering (LinuxFR.org)
There, fixed it for you.
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
> precisely because of these "useless configuration options."
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
JACK
2. Copy 128 frames from recording buffer into JACK buffers 128 samples long
3. Execute the entire JACK graph for these 128 frames
4. Copy 128 frames of output from JACK into ALSA
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
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.
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Interview with Lennart Poettering (LinuxFR.org)
Poisonous people
Poisonous people