Lennart Poettering: BSD Isn't Relevant Anymore

halfaperson writes "In an interview with LinuxFr.org, Lennart Poettering speaks freely about his creations, PulseAudio, Avahi and systemd among other things. Naturally, what has stirred up most of the discussions online is Lennart's opinions on BSD. Following the recent proposal to make Gnome a Linux-exclusive desktop, Lennart explains that he thinks BSD support is holding back a lot of Free Software development. He says this while also taking a stab at Debian kFreeBSD: 'Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that.'"

Comments

BSD Isn't Relevant Anymore

[Anonymous Coward]

It is official; Lennart Poettering now confirms: *BSD Isn't Relevant Anymore

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be Lennart Poettering to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a cockeyed miracle could save *BSD from its fate at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD Isn't Relevant Anymore

Re:BSD Isn't Relevant Anymore

[Anonymous Coward]

For all practical purposes, *BSD is dead.

Fact: *BSD Isn't Relevant Anymore

I think BSD market share is much higher than 5 years ago. I mean everyone seems to be forgetting to count Macs, iPhones, and iPads, and iPod touches in their numbers. If anything, Windows is becoming irrelevant... Now it is just between BSD and Linux like it should be.

         

Re:BSD Isn't Relevant Anymore

[leenks]

There is nothing to require you to release the source of a BSD derived binary you ship. Apple do it purely out of respect, not obligation. The GPL, however, forces you to release your source (as far as it can be enforced anyway).

Holding back?

[Anonymous Coward]

Innovation is still happening on the OpenBSD and DragonFly fronts.

FreeBSD is all about incorporating other people's software at this point (ZFS, DTrace, LLVM), and hasn't really originated a good idea in a decade. Coincidentally, that is where DragonFly split off. That's what happens when Apple buys the FreeBSD development team...you get a bunch of core developers running FreeBSD in a virtual machine on MacBook Pros. They can't be bothered to get basic functionality like suspend/resume to work, and all new wireless drivers are lifted from OpenBSD.

NetBSD is dead.

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time. Avahi runs fine at least on OpenBSD, and systemd....well there are only about two Linux distributions even using it at this point.

Re:Holding back?

[Anonymous Coward]

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time. Avahi runs fine at least on OpenBSD, and systemd....well there are only about two Linux distributions even using it at this point.

PulseAudio is a useless piece of shit. It's like ALSA with a bunch of stupid complications. How it got to be the standard sound system for so many mainstream distros is a real mystery.

It lends credibility to the idea that Open Source developers don't really want to achieve a mature, working codebase and stick with that unless there are serious problems that really do require moving to something else. There is a perception that it has to be hackish and in perpetual beta to be considered sexy and cool for an Open Source OS. PulseAudio is a big example of why this perception exists.

Just answer me one thing. ALSA has had Dmix for nearly ten years. It has enabled Dmix by default (as in it just automagically works) for about seven years. What glaring need is there for adding a second software layer to a sound system that already does what you need it to do? No, playing sound over the network isn't a good reason. That's what application-level streaming software is for. What does PulseAudio contribute other than needless complexity and several FAQs dedicated to replacing it with ALSA for various distributions that ship with it?

Oh, and in the case of Mandriva, a petition to remove PulseAudio by default since more than 90% of users are disabling it and replacing it with ALSA. Yeah, that's not for no reason.

Re:Holding back?

[mevets]

Too bad they didn't port the FreeBSD audio. It actually works.

Re:Holding back?

[causality]

PulseAudio is a useless piece of shit. It's like ALSA with a bunch of stupid complications. How it got to be the standard sound system for so many mainstream distros is a real mystery.

It was pushed by Redhat and nobody else had a better solution to clean up the morass that is linux audio.

PulseAudio is a relatively recent arrival. ALSA + Dmix by default has "just worked" for a long time now, about seven years. As a matter of fact, I don't see PulseAudio in a kernel config anywhere -- implying that PulseAudio is just an extra layer of software standing between the program wanting to play audio and ALSA. If the goal is to get rid of problems caused by ALSA (I'd love to hear what those are, by the way), then that's not going to work.

Please explain to me the specific problems with Linux audio and the ways that PulseAudio addresses them. I am hoping someone will respond to that, but if no one does I will definitely understand it is not a coincidence if no one can back up your assertion.

When I actually read user forums and do research on it, the impression I receive is exactly the opposite: PulseAudio is causing problems that didn't happen with ALSA. That's about what you would expect when you add redundant, needless complexity to an already-working system. As for me, on my system I have never installed PulseAudio. I use ALSA for all audio needs. Anytime I fire up Wine, mplayer, Amarok, or anything of the sort, audio just works and I don't have to worry about it. The only requirement whatsoever is that the user in question is a member of the "audio" group and that's all; it really is so simple and easy. I am so satisfied with this setup and the way it simply works that I have no problems with it to fix. What more do users want?

Re:Holding back?

[Wonko the Sane]

Before PulseAudio it wasn't possible to turn on a bluetooth headset and have any audio that was playing through your speakers automatically start going to the headset instead.

Re:Holding back?

[causality]

As for Alsa/another sound server replacing OSS, OSS do the mixing (and resampling?) in the kernel space, citing latency is one of the reasons, while alsa let userspace programs the jobs. IMO, that kind of works does not belong to kernel space, so I prefer alsa.

Regarding to pulseaudio, dmix is fine, but pulseaudio is better with features like glitch free playback (ironically, this is the reason why pulseaudio glitches so bad on some systems with broken drivers), you can set the resampling algo, per stream volume control, flat volume (another problematic feature), and as some people said, it is the only setup that allow output via bluetooth devices but I haven't tried it yet. The main reason for many problems related to it is the horrible audio drivers on Linux (as always), so you can't exactly blame pulseaudio, at least it always has fallback mode, and the distros never set them as default. Back when pulseaudio was first integrated into Ubuntu (around 8.04, right?), it didn't work well for me and stop working for many other. But now, most people I know have absolutely no problem with pulseaudio. PS: Aside from dmix, there are several other sound servers like arts, esd etc.... too, I'm glad that we get rid of all that and now pulseaudio on alsa is the standard.

The in-kernel audio drivers have always worked flawlessly for me. I have never had problems with latency, glitches in playback, etc.

But let's just assume, for the sake of argument, that I just got lucky. Let's assume most users have problems that can be directly attributed to shoddy in-kernel drivers (as highly unusual and unlike the typical linux kernel experience as this is...). The solution to that is to put available development effort towards fixing those drivers. They are, after all, the low-level foundation of the audio system. The solution is emphatically NOT to add a redundant software layer on top of broken drivers. You do like to solve problems by fixing things where they are actually broken, right? That's the sensible thing to do. That's the correct use of the talent of developers who specialize in programming sound systems.

Arts (what a piece of vulture shit that was) and ESD are not on equal footing with Dmix. Dmix is a small, relatively efficient, rather problem-free mixer for sound cards that do not have a hardware mixer. It just works and it actually serves a purpose, unlike the sound daemons. ALSA will use a hardware mixer instead of Dmix if you have high-end hardware and one is available. I have never known Dmix to introduce playback stuttering, idiotic problems with multiple users, or any of the other problems you can easily find when you do a Google search for Arts or PulseAudio. I have also never known Dmix to use any noticable amount of CPU.

Again I will reiterate. PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA. How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot. If there are such horrible problems with Dmix (that somehow I won the lottery of never personally encountering), that kind of development effort should be put towards fixing Dmix. Doesn't that make a lot more sense?

Re:Holding back?

[causality]

Before PulseAudio it wasn't possible to turn on a bluetooth headset and have any audio that was playing through your speakers automatically start going to the headset instead.

It's good to have a real answer to a question. Still, I have another question. Given the open-source nature of all the software involved, wouldn't the developer time be better invested in fixing the ALSA drivers to accommodate Bluetooth headsets instead of creating an entirely new layer of middleman software between the application and the audio system?

It's a question of how to best manage and invest the finite talent and effort that is available. Why would PulseAudio be the best possible method? What does that answer look like when you subtract from its gains all the time wasted by users with no such headsets who had to sort out PulseAudio-specific audio problems? There's a big picture here and it doesn't look good for PulseAudio.

Re:Holding back?

[Electricity Likes Me]

PulseAudio isn't a bad concept, it's just that it doesn't work properly for far too many people. But the widespread adoption of tablet, smartphone and other "slim computing" devices does kind of speak to a need for a software-agnostic way to stream audio from server to client - requiring every application that wants to do this to implement streaming isn't a very sensible solution to the problem IMO.

Re:Holding back?

[Anonymous Coward]

If the goal is to get rid of problems caused by ALSA (I'd love to hear what those are, by the way) ...

Not that PulseAudio would necessarily solve these, but here's my list:

(1) The default dmix resampler sucks. The "high-quality" one is better, but that one uses up significant chunks of CPU time. I haven't had a chance to look at the code (been meaning to) but it seems to me it should be possible to maintain quality without using so much CPU.

(2) Semi-pro home-studio type soundcards are poorly supported. Currently my ENVY 1712 does not come up right on boot and it takes an iteration or two of unload-modules and restart alsa before it "catches". Seems something broke somewhere between 2.6.32 and 2.6.38. Alas I need the latter to support this motherboard.

(3) After audio's been playing for an hour or two, I'll start to get some crackling in the left speaker. Unloading modules and restarting alsa fixes it.

(4) The resampler/dmix semantics are dumb given that many soundcards can run at any of the popular sampling rates up to 96K. A smarter way to do the mixing is: when no other sound is playing and an application asks for audio, set the card to run at the same rate as the source to be played. No resampling required. If and only if a second sound source wants to come in while sound is currently being played; and if this second source asks for a rate different than the one currectly being used, then and only then the resampler is started and used to match the second sound's rate to the first.

Most the time this does what you want: music being played will sound as clear as possible. Any ancillary system boops and beeps and desktop sounds that come in the middle will get resampled if needed. And you won't be burning CPU except when needed, and only for the relatively short ancillary sounds.

(5) Perhaps there's a way to configure the behavior desired in (4), but the alsa configuration language and options are so dense and (to me) counterintuitive I don't know where to start. It is like a programming language onto itself but there's no idea of what options are relatively efficient to use, and what should be avoided if possible.

(6) Related to (5) and indirectly to (4), there are time I _want_ exclusive use of the audio, without any mixing. I live with several roommates; we rotate around who plays mood music in main room. When I'm playing audio in this manner, the _last_ thing I want is to be shocked out of my seat when I inadvertantly visit the "wrong" web-page that blasts some sounds. What's the best way of expressing this in alsa-lingo?

(7) The Jack-audio-connection-kit realtime audio router seems to solve a lot of the same problems as dmix, and as PulseAudio. Why didn't they just use that? I get much better results when using Jack. Admittedly, Jack runs on top of alsa, so what's Jack doing that the apps aren't outside of Jack?

Some of these may well be PEBKAC. I apologize but find the documentation is simply too dense and obscure for someone who doesn't yet have a grasp of just how all the pieces interact that I may know where to look and what to tweak - or, even - what pieces are available. It didn't help that I was trying to set up audio right around the time dmix entered the picture and what I thought I knew one week no longer worked the week after, which has put a rathar sour taste in my mouth over the whole thing.

Re:Holding back?

[gilboad]

Actually, I -really- like Pulse.
For the first time since, err, RedHat 5?, I can actually hear music on amarok, watch a movie on youtube and get a call using skype without blocking the system.
I can dynamically reduce the volume of streams that I don't like (E.g. flash) without dropping the volume on other applications (E.g. amarok) or dynamically move streams from one device to another (E.g. Switch music stream from on-board / headphone to SB Audigy / 5.1).
I could never achieve that, not with Alsa (Linux w/ or w/o dmix) nor with OSS (under both Linux and FreeBSD).

Now, ***you*** may not appreciate or need it, but calling a very stable (at least on Fedora) a useless piece of shit just because ***you*** don't use it, should have earned you a -5 troll.

- Gilboa

Re:Holding back?

[Anonymous Coward]

The right way of dealing with it, IMO, is more or less the pulse-audio way. ALSA is doing a lot of stuff in the kernel that probably should be in userspace, and cramming your entire bluetooth stack (plus any other audio sources and sinks that might be hotplugged) into the kernel just to handle audio is architecturally the wrong fix. You want to take a step back, figure out what needs to be done in the kernel (analogous to kernel modesetting for video), and pull the rest of ALSA's functionality into a userland daemon analogous to an X server.

But PulseAudio is (still) immature, and in some ways (particularly its braindamage pertaining to multiuser systems) just plain wrong; I'm in no way advocating for its adoption now, much less back when distros started adopting it.

Re:Holding back?

[babai101]

PulseAudio is a useless piece of shit. It's like ALSA with a bunch of stupid complications. How it got to be the standard sound system for so many mainstream distros is a real mystery.

ALSA with dmix produces shitty quality sound. When pulseaudion was introduced in ubuntu 8.04 it was causing all sorts of problems, mainly with sound latency. If you give pulseaudio a try now you'll see all of those latency issues have somehow vanished, plug-in an audio device to your pc and it magically works like in windows, and the sound quality due to some good resampling is just crystal clear as with OSSv4. While OSSv4 has a very good resampler it fails to support the plethora of sound devices that pulseaudio supports.

Re:Holding back?

[gilboad]

Sounds like everything you could do with JACK years ago. Pulseaudio was written because... well... there is no good reason for pulseaudio to be written in the first place. Lennart simply didn't like JACK, or ESound, or aRts, or any of the other existing sound servers. It's the age old open source dilemma of rewriting from scratch what could otherwise be fixed in the existing systems..

.

I can only speak from my own personal experience, but at least in my case, ESD and Arts never really worked when trying combined non-native applications (E.g. KDE under GNOME or vice versa, let alone running OSS games/flash/etc under both) and as for JACK, well, tried it a couple of times, never really worked for me, dropped it.
Pulse marked the first time both me and the people around me can reliably mix multiple streams from different applications while getting expected results. (E.g. Mixing Amarok, skype, qemu running Windows VM w/ audio and a native Linux games that uses OSS)

Granted, both me and my friends/coworkers use Fedora which doubles as PulseAudio test-bed (which may be the reason to better out-of-the-box experience), but at least for us, PA simply, err, works?

The problem is that it got shoveled down the rest of our throats long before it was ready for public consumption, and without any real pressing need.

I fully agree, even though I understand Lennart's reasons for doing it (AKA KDE 4.0 release limbo).
Heck, I used to automatically remove PA as the first post install phase up-until Fedora ~8-9.

As I see it, PA had a rotten beginning and has improved tremendously since then but much like KDE 4.x, it still suffers from the bad reputation that trails it since the initial troubled release.

The irony is that a lot of people here praise Alsa... anyone that's old enough to remember the first years after the move from OSS to Alsa would easily remember that Alsa attracted more-or-less the same hateful reaction that PA now draws. ... One can only wonder what will be said on GNOME 3 and KDE 4 when GNOME 4 and KDE 5.0 will be released :)

- Gilboa

Re:Holding back?

[subreality]

IMO: Like you say, PulseAudio doesn't add any important technical features.

The problem with ALSA is the configuration. Changing anything (even as simple as redirecting audio to a digital out, or indeed, even enabling dmix) requires monkeying around in your .asoundrc which to put it politely, is arcane at best, and there are no user-friendly tools to make it easier.

So you slap PulseAudio on top of it, and it provides a convenient API. As such, there are easy GUI tools to configure where you want your sound to come out.

Of course that's a terrible solution to the problem. It just adds another confusing layer of complexity and incompatibility, but I think we're stuck with it until someone writes a better UI for ALSA.

Re:Holding back?

[smash]

The other linux problem: Not Invented Here.

See DTRACE vs Systemtap

Re:Holding back?

[gmueckl]

I hate audio demons. These crutches never worked properly and never will. Someone needs to actually make a lot of absolutely breaking changes to ALSA. Why?

When I plug in my USB headphones in Windows, all programs using default audio output automatically move from my 5.1 speakers (onboard sound) to the headphones the moment I plug them in. When I pull the plug, the reverse happens automatically. It just works! MacOS supposedly behaves the exact same way.

On Linux, this is broken in ways you cannot even imagine. When I plug in the USB headphones after booting, they are treated as the second sound card (hw:1) when everything uses the first one (hw:0) by default. So in order to have anything use the headphones I have to reconfigure the applications one by one and probably restart them (xine needs a restart). Same when I change back. When I leave the USB headphones in when booting, it is totally random which sound device will be hw:0 and which will hw:1. Great. To make matters worse, when I leave the webcam plugged in, the internal microphone also gets registered as a different sound device. Plus, when it is plugged in when booting it gets a number one below the headset. So sometimes the webcam microphone ends up as hw:0 during boot and every program attempting to use hw:0 as output device will throw up confusing error messages about how everything stopped working (if they even detect that). A normal user would have given up on this mess already!

The really proper fix would be the following: break the ALSA interface in a big way: don't number sound devices, but name them after the hardware they contain (not the bus location, esp. in the case of USB devices), and make the current default device queryable somehow. Programs must then query ALSA for the default device and be aware that this may change at any moment. ALSA must be extended by a mechanism to report such changes to programs, which absolutely have to respond to this in order to not crash and burn (it'll be a PITA for the programmers, but it's absolutely necessary to enforce all of this). Also, ALSA must be able to report the speaker configuration connected to a certain device.

Why? Programs that are capable of generating two or more channels of output sound need to be aware of how many channels are going to be audible. It's not enought to know that the sound device has a 5.1 analog output. It is equally important to know whether all outputs are actually connected to speakers (e.g. a headphone connected to the onboard 5.1 analog output) or the program will play sound on channels that are inaudible and will not be heard by the user. Really great programs even should distinguish between stereo speakers and headphones or different setups for the same set of speakers (I guess most OSS Linux app devs won't even know why that is). Automatic downmixing inside ALSA when the output channel count decreases on a device change should not happen because the program almost always has additional information and thus can do a better job.

I know that programmers will cringe when they read this because it makes using ALSA much more difficult, but that's what is missing to get consumer desktop audio up to par on Linux.

Re:Holding back?

[Burpmaster]

Hello again.

PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA.

So is dmix. I explained this to you before.

How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot.

You are conflating ALSA, the clean efficient kernel API for using sound hardware, with ALSA the user-space API that adds on a complex system of plugins that can be inserted in place of, or before, sending sound to the hardware. It's this complex plugin system (and the mixer built on top of it) that is inherently flawed and has fundamental limitations. There's no dynamic routing or hot-plugging for starters (and I mean while an application is running). Fixing these limitations requires a rewrite.

If there are such horrible problems with Dmix [...], that kind of development effort should be put towards fixing Dmix

Dmix is being fixed, via a rewrite called 'pulseaudio'. You may have heard of it.

Re:Holding back?

[TheRaven64]

Working audio was what made me switch to FreeBSD in the first place. This was back around 2001. The state of the art was something like this:

Applications played sound by writing writing to /dev/dsp. This was a fairly standard way of playing sound, based on the Solaris, and supported by most *NIX systems. OSS defined a set of ioctls for controlling playback, and these worked everywhere. There was one slight problem: most implementations didn't support software sound mixing if your hardware (like most cheap AC97 CODECs) couldn't do mixing in hardware. This meant that only one device could write to /dev/dsp at once, meaning only one application could play sound. KDE and GNOME both had their own (incompatible) sound daemons, so multiple KDE or multiple GNOME apps could play sound at once, but not both. I was using a KDE Jabber client, a GNOME email client and wanted to get audio new message notifications from either. I also wanted XMMS (which wrote directly to /dev/dsp) to play music in the background, and I wanted to play BZFlag! sometimes and have its sound work without breaking anything else.

In Linux land, there was ALSA. ALSA did sound mixing, but it required your applications to be rewritten to use it. Some sound cards only had ALSA drives, some only had OSS drivers. A few had both. ALSA had a half-arsed OSS emulation mode, but that broke various other things, and still didn't let multiple OSS applications play audio at once.

FreeBSD 4 had a virtual channel (vchan) mechanism. You had several /dev/dsp.n devices. /dev/dsp was a symbolic link to one of them. I set the KDE sound daemon to use /dev/dsp.1, the GNOME one to /dev/dsp.2, XMMS to use /dev/dsp.3, and whatever other app tried to use /dev/dsp got the /dev/dsp.0 channel (typically games, running in the foreground). All of my running apps could play sound at once and, after a small amount of initial configuration, it Just Worked.

I didn't stay with FreeBSD 4 for long on the desktop, I started using the FreeBSD 5 betas. This was a really unpopular FreeBSD release, because it was only about as stable as Linux at the time, which most FreeBSD users felt was completely unacceptable. It improved the sound system so that the vchans were automatically allocated. Now, things worked just as well as they did with FreeBSD 4, but I didn't need to configure anything. Apps could just open /dev/dsp and they'd each get a new vchan, up to a configurable limit (I set it to 16, which seemed to be more than I needed).

Now I use FreeBSD 8. As well as the earlier features, it has a new low-latency sound mixing path, per-vchan volume controls, and full OSS 4 support. Oh, and it even has a compatibility layer, so if I run old code that uses the OSS 3 APIs and tries to modify the global volume control via /dev/mixer, I can make it only modify its own vchan's volume.

Meanwhile, Linux developers were told that, actually, they shouldn't use ALSA, they should rewrite their sound code yet again, this time for PulseAudio. And people wonder why I hate having to support Linux...

In related news

[ArchieBunker]

Apple claims HTC is no longer relevant and Ford also claims GM is no longer relevant.

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

Re:In related news

[dgatwood]

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

Something that doesn't make him sound like a complete idiot?

The core of Mac OS X borrows heavily from BSD, so one could legitimately argue that BSD is now the most widespread UNIX variant. In fact, I wouldn't swear to it, but I suspect that makes BSD (and Mac OS X, specifically) more popular than all of the other Linux and UNIX variants put together.

You'd pretty much have to be living under a rock to think that BSD isn't relevant. Either that or you have to believe that Windows is the way of the future. Take your pick.

Re:In related news

[Tester]

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

Something that doesn't make him sound like a complete idiot?

The core of Mac OS X borrows heavily from BSD, so one could legitimately argue that BSD is now the most widespread UNIX variant. In fact, I wouldn't swear to it, but I suspect that makes BSD (and Mac OS X, specifically) more popular than all of the other Linux and UNIX variants put together.

1. Lennart is NOT a kernel developer. He is a userspace developer who wrote many important pieces of infrastructure for all free operating systems.

2. Lennart is trying to make Linux more like OSX.. What he is saying is that the other BSDs are way way behind in features. Apple had to radically change BSD to make it suitable for a desktop, and Lennart is doing the same.

Re:In related news

[Tom9729]

TFS is flamebait.

LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
I am pretty sure those other systems are not irrelevant for everbody, after all there are people hacking on them. I just don't think it's really in our interest to let us being held back by them if we want to make sure Linux enters the mainstream all across the board (and not just on servers and mobile phones, and not in reduced ways like Android). They are irrelevant to get Free Software into everybody's hand, and I think that is and should be our goal.
But hey, that's just me saying this. I am sure people do Free Software for a number of reasons. I have mine, and others have others.

He's saying BSD isn't really relevant on the _desktop_ (and sorry but no, OS X is not a counter-example to this) and that if developers want Linux to succeed on the desktop then they need to worry less about other platforms. In other words, don't cater to the lowest common denominator.

Re:In related news

[bonch]

The Apple variant of BSD is a dead end. All branches of linux are still alive and kicking, for example on Android phones - the most popular smartphone.

Android isn't a smartphone. It's an operating system. With iPods and iPads counted, the most popular mobile operating system is iOS by a large margin. Apple's Darwin foundation is the most popular UNIX in the world.

Re:In related news

[kc8apf]

It's interesting that the question implies that Linux is leading the charge in defining new APIs. Everything listed has a FreeBSD equivalent that predates the linux version:

cgroups -> jails
udev -> devfs
fanotify, timerfd, signalfd -> kqueue

Of course, the Linux developers decided to reinvent them all making compatibility impossible. I guess you could argue that the Linux versions offer some extra features over the FreeBSD versions, but from a user and developer perspective, the FreeBSD versions seem more complete and stable (see jails vs cgroups).

Re:In related news

[jon3k]

Not even close, linux dominates in the server world and Android is based on linux, which is outselling the iPhone quite easily (up to 550,000 android devices activated PER DAY).

Re:In related news

[Galactic Dominator]

Sure they have. Take this for example.

http://www.osnews.com/story/22331/FreeBSD_Gets_Grand_Central_Dispatch_Port

I could go on, but it's obvious you need to develop some research before forming opinion skills so I'll let you handle it from there.

Re:In related news

[Moridineas]

Apple is due to report quarterly earnings next week. Guesses are that they will have sold around 18 million iphones and 8 million ipads, maybe 5-6 million iPod touches. Comes out to a ballpark of roughly 360k activations a day.

Is it just me or is it almost unbelievable that between iOS and Android there are almost a million devices being activated every day? Amazing...

Re:In related news

[Darinbob]

Didn't Linux invent the NIH syndrome or are they just pretending there too?

Re:In related news

[MacGyver2210]

Lennart is trying to make Linux more like OSX

Thank you for clarifying that. Now I understand that he is to be stopped at all costs.

Re:In related news

[Anonymous Coward]

Linux didn't invent it, but they didn't like the existing implementation so they went ahead and rolled their own.

Re:In related news

[0x000000]

This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.

http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587

Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.

Re:In related news

[drinkypoo]

Lennart can work himself to the bone trying to mimic OS X, but he'll need billions in resources and thousands of quality engineers to pull it off.

Ubuntu Natty is very like OSX in every relevant technical way. I promise you I can find more ways in which they are like than ways in which they are different. Both have accelerated graphics interfaces which will tile your virtual desktops or your windows. Both have a unified menu bar, and both sometimes generate applications whose menu doesn't go there (when you run something targeted against an ancient API.) Both try to have a unified look, but both will run applications which use other widget sets and make your desktop look ugly. Both are Unix and neither are UNIX(tm). Both can be programmed in multiple languages but primarily C and C++. Both have components written in various languages, but primarily C and C++. Both have a capabilities-based security system. Should I really go on?

Your claim that you need billions in resources and thousands of quality engineers is close to the mark yet without actually hitting it. It's true that billions in resources and thousands of quality engineers must be involved, but it's not clear that one person must control them. The world has produced an operating system very like OSX, but one which is free, Free (with appropriate drivers) and Open Source, which makes it superior in my book. Indeed, anyone who claims that Linux cannot do more things than OSX "out of the box" is insufficiently familiar with both.

FreeBSD is a minor player compared to Linux. That's nothing against it, but the fact that there are multiple BSD forks and just one main Linux tree (there's tons of forks of forks of forks, but there's only one mainline for Linux, while there's four for *BSD now, if you count OSX) makes Linux more flexible and powerful than any single BSD. The same Linux runs in so many places! That makes it a more logical choice than a BSD for starting new projects.

Re:In related news

[drinkypoo]

You are making an apples/oranges comparison, it's obvious you know quite little about the BSD ecology.

That's funny, because I could swear I've installed and used a whole bunch of BSDs, including SunOS4, AOS 4.3 and BSD 4.3-lite on IBM RT PC, and scads of others (not to even mention x86 variants!)

The BSD OSes consist of a kernal and a complete userland, which even includes X11. Meanwhile, Linux is just a kernel, and there are dozens and dozens of different kludged together userlands that people combine with the linux kernel and call 'Linux.'

In practice they all tend to run approximately the same userland at the same time, although they may have different widget sets etc. This is also true of BSD to a certain extent, in that basically everything in use today is descended from BSD 4.4-lite, including OSX... as NeXTStep inherited bits from 4.3-lite and 4.4-lite at different times.

PulseAudio?

[0100010001010011]

This guy needs beaten just for this.

Re:PulseAudio?

[causality]

This guy needs beaten just for this.

I don't blame him for creating PulseAudio. I blame the distribution maintainers for having the poor judgment to make it the main sound system for so many distributions. It would be one thing to have a sane default like ALSA and then have PulseAudio available in the repositories for those who really want it.

For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using PulseAudio. If so, I remove it and replace it with ALSA. Suddenly issues related to audio playback go away and everything just magically works. Oh and they easily have a proper mixer without jumping through hoops, too, which is handy considering some of them are using 5.1 surround sound and/or bluetooth headphones.

The first headache I had with PulseAudio was when I tried to run something as a different (normal) user account and audio wouldn't work. There was no meaningful error message. There was only a "connection refused" error in the terminal. As it turns out, this is because PulseAudio has to be run by the user and it is recommended not to run it as a system-wide daemon. User A was running the user-daemon and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used ALSA since PulseAudio didn't do anything I needed it to do that ALSA couldn't do with none of the hassle.

In case you wonder why I was running something as another normal user, it was for using Windows programs in WINE. I always prefer to do that with a separate user account that isn't used for anything else. This special WINE account has additional restrictions because I do not trust Windows programs -- they might phone home, they might contain malware, they are binary blobs that cannot easily be inspected, etc. The point is, Unix and therefore Linux are multi-user systems. You expect to be able to have multiple concurrent users running programs without issue.

PulseAudio smacks of the walled-garden model, where as long as you are a very average user who does extremely predictable things that they have decided to allow for, such as only having one active user on the local system, then you have few or maybe no problems. As soon as you do anything even the slightest bit unusual (which multiple users on a *nix system hardly is) you start running into brick walls. To that I say "no thanks, not for me". If I wanted that experience I'd use Windows. If ALSA were a barely-functional, poorly designed sound system I could at least understand why PulseAudio exists and why it is becoming so popular. As far as I can tell it's a burdensome solution to a problem that doesn't exist.

Re:PulseAudio?

[fnj]

Word. Systemd. What a pointless masturbatory waste of effort. That's just one area where BSD, far from not being relevant, is right. They don't fuck with what works fine.

Re:PulseAudio?

[Chris Mattern]

"Oh something new and shiny that breaks backwards compatibility! Therefore it must automaticly be bad!"

Well, yes, actually. Breaking backwards compatibility is always bad. It may on occasion be necessary to do so to gain a greater good, but it's still bad.

Does Netcraft confirm this?

[mlts]

Just curious... does Netcraft confirm this?

Like SpinalTap

[jvillain]

I guess Gnome is becoming more selective in it's appeal just like SpinalTap.

Pulse Audio

[Beelzebud]

I don't take anything from this guy seriously after dealing with Pulse Audio on a few systems. The shit never improved and only added a layer of incompatibility to systems that ran just fine using ALSA by itself.

Re:Pulse Audio

[Anonymous Coward]

He has a tendency to develop things halfway, without taking any input from any users, and then everyone using Fedora has to end up using it even if it's complete shit. If you criticize him, he's got some staunch defenders that will call you out on it, mostly the people who have only ever used Linux on a laptop... that really does seem to be the only thing he cares about.

PulseAudio - a useless NIH layer. ALSA was just fine. He lists a bunch of other problems with Linux audio, but everyone was just using ALSA directly, nobody was using his straw men really (Jack? OSS? Really?) This is the first thing I remove on my Linux boxes.

I predict systemd will be his next "hit". He named the control command "systemctl" even though every Linux has a "sysctl" command already... one of the most easily avoidable CLI namespace problems I have ever seen in over 20 years of UNIX and 18 years of Linux administration. I think systemd is because he really really wants to make Linux into MacOS X. If you want MacOS X, then great, it's a fine desktop OS, have at it.... but Linux is still mostly used on servers, and there is nothing wrong with that at all. Anyway, systemd just throws out everything that was good about init and even upstart, and starts over, and he is busy adding the features of cron and inetd to it for some reason. Because saving some tiny amount of space in the process table is somehow useful.

I just wish there was some review of features that make it into Fedora, etc, to see if they're really worth it.

Re:Pulse Audio

[Anonymous Coward]

ALSA and OSS always just worked for me.... all the way back from the first time I tried audio on Linux with OSS on a 1.0.x kernel. I have been using Linux daily as my main desktop OS since 1993, with a variety of soundcards (mostly Soundblasters and recently more onboard integrated audio, but also a variety of other cards), and I'm telling you, I never had the problems PA was supposed to solve with just directly using ALSA. Now I get fewer functions and PA uses more CPU. Great. Removed.

Regarding systemd:

System-V init actually does exactly what a Unix-like system needs it to do... but regardless of that, my problems with systemd are:
1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.
2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?
3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.
4. Doesn't socket activation require changes to daemons?
5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)
6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.
7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

My concern is that systemd is going to make it into CentOS and RHEL at some point, and that will suck for me, unless Redhat actually makes some changes to it.

Am I still talking nonsense or are you just blind?

Re:Pulse Audio

[gmueckl]

From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes. Otherwise, that particular demon will be handled like in the old init system. So, in order to bring any benefit at all, the whole system (which worked) must be adopted to systemd in some way. Given that some of these demons are really there to be run on servers where systemd has no place, this thing does not seem like a very good idea.

But unlike PulseAudio, i haven't had a chance to see systemd fail spectacularly.

Re:Pulse Audio

[Richard W.M. Jones]

PulseAudio sucks, but systemd is reasonable stuff. It's like upstart (but done right) combined with inetd.

Unlike what another reply says, systemd does not require changes to daemons.

Rich.

Re:Pulse Audio

[PeterBrett]

1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.

Mainly because said concerns tend to boil down to "Waaah, it's different." Oh no.

2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?

"Annoying" is an opinion. Could you please link to said threads?

3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.

There are some advantages, such as per job/per request cgroups to make sure that all processes get cleaned up correctly. I'm not particularly bothered either way. Note that "in systemd" doesn't mean "in PID 1".

4. Doesn't socket activation require changes to daemons?

It does. However, you don't need to use socket activation -- "classic" forking services can be used just fine. Obviously, yes, if you want all the advantages of systemd, daemons do need to be modified to receive their sockets from systemd.

5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)

Some sort of RPC was needed for communication between systemctl and PID 1. TBH I would rather systemd used a solution that's already widely used in the Linux desktop, is well-maintained and robust, rather than Lennart rolling his own NIH version. But maybe that's just me. It doesn't seem like an unreasonable design decision to me. What solution would you prefer?

6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.

As far as I can tell, systemd is also optimised for ensuring that login sessions and daemon processes are correctly & fully cleaned up (for example, if you're rebooting apache, systemd will make sure all the processes apache forked are terminated -- something SysV init can't do).

7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

"systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever." People seem to be very keen to shoot the messenger (i.e. the systemd devs) for warning them that about breakage that has been present since before systemd existed.

Gah, I don't even run systemd myself and I seem to know more about it than most people commenting on this article...

Re:Linux itself isn't relevant anymore

[hedwards]

That was my thought, BSD gets a bit of a license in that regards because it isn't trying to take over the desktop space. There are a small number of OSes that are related, some are focused on the desktop environment, but they're more focused on polish and actually working reliably from release to release and evolving the experience over time.

Linux OTOH varies enough that I can't really make a particularly fitting statement on that. Some distros are run by people that know what they're doing and focus on fixing things that are broken, others like Ubuntu are clearly run by crack smoking monkeys and you end up with unusable garbage or releases that have nothing in common with previous releases.

But with the dozens of distros and all the talk of being relevant to the majority of users, it's hard not to view it like the short bus kid that thinks he's going to be valedictorian. At the end of the day, most of what's wrong with Linux is the direct result of trying to copy Windows and scoop up the users even if things like automounting were stupid to begin with.

Re:Linux itself isn't relevant anymore

[camperdave]

Linux on the desktop is so last year...

Re:Um... Pardon Me, But...

[scubamage]

Yeah, it was. BSD was THE unix for awhile after AT&T got split up. In the early 80's BSD was the basis for a lot of proprietary Unix's. Afterwards, the *BSD projects came out. It was incredibly important for awhile. Further, I know a couple of places that still use net-bsd with switch cards and iptables/ipchains to act as a second tier firewall after a hardware appliance. They work quite well. I wouldn't touch it with a 10 foot pole for anything desktop related though.

Re:Um... Pardon Me, But...

[TheGratefulNet]

not sure about today, but years ago, Juniper networks used freebsd inside, to run the userland side of their core routers.

netbsd was used (also about 10 yrs ago, a lot) for non-intel style embedded network devices. I was at a router/switch company and we used netbsd (ppc arch. at the time).

can't say I ever ran into a bay area company, during my travels, that used openbsd. but back about 10 yrs ago, freebsd and netbsd *were* quite popular in the enterprise. corp people didn't like the GPL (at least at the time) and bsd was the most business-friendly license they could find.

always wondered why PulseAudio sucked

[decora]

now we know.

the developer lacks humility.

Re:always wondered why PulseAudio sucked

[fnj]

You put it too kindly. I would say he is a punk.

redhat audio people on irc

[decora]

back in the late 1990s, i had a flamewar on an irc channel with a guy from redhat, screaming at me that there was no reason anyone would want to have two programs play a sound at the same time.

Re:redhat audio people on irc

[TheRaven64]

In the late '90s, I had MP3s playing all of the time and wanted to be able to have instant messaging and email applications go 'ping' when I had a new message. Being able to do that easily was why I switched to FreeBSD. The good documentation and a libc that doesn't make me want to kill the author whenever I write code made me stay.

ha ha

[Weezul]

Linux's vaguely meritocratic approach has obliterated the BSD cliquish approach, period.

Does any other OS have multiple competing teams writing the scheduler? How could anyone possibly compete with that? Seriously!

Conversely, the LLVM will eventually obliterate GCC for the same reasons, multiple participants engaging in healthy competition. Oh, plus the LLVM simplifies writing compilers for virtually any language.

p.s. Does APL/K/J have an LLVM based compiler yet?

Re:ha ha

[Anonymous Coward]

Conversely, the LLVM will eventually obliterate GCC for the same reasons, multiple participants engaging in healthy competition.

LLVM development is mostly supported by Apple.

Re:Of course

[VortexCortex]

What? People play Doom all the time...

Re:The worst thing about OSS ...

[Doctor_Jest]

Really? I thought it was all the goddamned vampires....

Re:The worst thing about OSS ...

[causality]

... or perhaps the only annoying issue with OSS in general, is that the OSS community contains far too many fools who think that their opinion about some other project they don't like somehow matters.

That's different from any other thing ... exactly how?

The world is full of people like that. Each one of them is perfectly right in his or her own eyes. Anyone who sits there hanging on their every word is not only part of the problem, but the biggest part.

Well ....

[DaMattster]

For security, stability, and reliability, I will take OpenBSD over Linux any day of the week. I can look at my logs and most would-be intruders give up after doing an OS fingerprint on my gateway machine. They see that it is OpenBSD and quit while they are "NOT ahead."

Lennart

[DaMattster]

Why does he have to spread crap like this around? Really, there should be cooperation between the Linux and BSD camps. They interoperate very well because, for the most part, they share some common userland tools and are also semi-POSIX compliant. One of Sun Tzu's principles in the Art of War is to divide and conquer. When FUD gets spewed from the OS camps, it simply shows how divided Open Source really is and makes it easier for proprietary OSes to gain inroads.

Re:Lennart

[Alcoholic Synonymous]

Poettering is a zealot for a religious cause. It has nothing to do with truth or facts or even logic. His chief gripe isn't actually that BSD isn't keeping up with Linux, it's that BSD does things different from Linux and he doesn't like it. He tries to spin different as not keeping pace, but that's based on the assumption that the way he wants to do things is the One True Way. Mind you, he says this while simultaneously and purposely trying to keep BSD out of the party by refusing any and all compatibility patches that would make his One True Way usable on BSD.

Amazingly, the BSD people have a way of fixing this crap themselves. It's just more of a pain in the ass when people like Poettering actively work against their efforts.

Re:Lennart

[Crispy Critters]

"there should be cooperation between the Linux and BSD camps"

Of course there should be, but you won't see it from Pottering. He doesn't care if anything works on Linux except under Gnome. He certainly isn't going to care if things work on BSD.

Oddly, as someone trying to use a modern Linus distro without Gnome, Potterings antics have made me wonder if I should switch to a BSD.

Re:Lennart

[staticsafe]

Nicely said. Infighting is OSS' worst enemy.

Re:OS X is on its way out

[dgatwood]

Sorry. I should have been clear: I'm not including embedded systems in that calculation; I'm only talking about desktops and servers based on PC hardware and similar. By that standard, Mac OS X has more than double the Linux installed base by most estimates (the most optimistic estimates I've seen for linux are 25 million, where the most pessimistic Mac OS X estimates are around 53-54 million, growing by roughly the size of the entire Linux installed base every 1.5 years or so).

If you include embedded Linux, Linux is probably more widespread, but then we have to get into the argument over whether Android is Linux and whether iOS is BSD, and that just gets messy....

Further pulseaudio reasons

[Sits]

Many of the things that pulseaudio provides:

• When I log into GNOME I don't have to have the same volume as the last user who logged into GNOME- it's restored on a per user basis
• Simplified volume interface. Pulseuadio multiplexes things like the Master volume and the PCM volume into a single control thus allowing better granularity than the Master volume alone
• When I plug a USB webcam in, pulseaudio now remembers that I prefer it as my default microphone and applications switch to using it rather than the built in one without forcing programs to be reconfigured
• The per app volumes are also useful - sometimes a Flash app in the browser doesn't have a volume control but I can use pulseaudio to make it quieter
• esd has been allowed to retire
• Using pulseaudio allows the kernel to sleep longer when audio is playing by sending a bigger buffer when possible. When not possible (because a quicker response is needed) it sends a smaller buffer. This enables power savings to be made.
• Easier to apply volume boost (artificially making quiet audio "louder")
• Easier to switch between audio setups (e.g. from stereo to 5.1)

There were introductory issues too:

• When it was introduced most programs didn't use pulseaudio directly. Some programs still wanted to use OSS. Pulseuadio can emulate a subset ALSA but some programs were using more than that subset
• Not all distributions enabled ALSA emulation when they first enabled pulseaudio. This created fights between ALSA using programs and pulseaudio using ones
• Bugs in audio drivers were uncovered. Like a tree falling in a forest with no one around to hear it, you can create a philosophical debate as to whether a bug is a bug if no one hits it. Regardless, the result was pain for some users.
• Bugs in the userland audio stack. Bugs in gstreamer and pulseaudio have caused issues like the volume going to 0 every time a track was changed or huge CPU usage that caused pulseaudio to be killed off.
• Choice of audio mixing methods which make use of floating point

These issues seem to have been mostly solved with time but caused a lot of heartache along the way. The problem is whether it was a chicken and the egg issue where these issues wouldn't have been uncovered until people started testing these things but you can never get enough testers so...

Then there are issues that are still with us. If you have a creative sound card your life is going to be difficult. Pulseaudio doesn't make use of hardware mixing so if you have such a card, you may have noticeably higher CPU usage than ALSA alone (even though the audio mixing is no better). Two steps forward, one step back?

ALSA was never going to be able to introduce all the features mentioned in the first part of this mega post, mainly because it is too low level. Even OSS on the BSDs doesn't present an easy GUI for all those features (it does do mixing and per program volumes) yet Windows and OS X have many of these features. The big picture is that I can do things that I couldn't before and sometimes a lot simpler (remember esd and artsd?) but there was a cost. You may not find the cost was worth it but my feeling is that it will be around on "big" Linux (e.g. machines similar in power to desktops) for the next 10 years.

Re:Linux itself isn't relevant anymore

[perryizgr8]

i think the only way for linux to be relevant on the desktop is if someone places their android phone on their desk.

Yes

[rawler]

Hurd is taking over it's space.