5 ms·
> his contributions towards open source have brought far more problems than any of the solutions he looked to replace. If this were true, nobody would have ado
by joelthelion 12y ago
> his contributions towards open source have brought far more problems than any of the solutions he looked to replace.
If this were true, nobody would have adopted his work. If most of the major distros have switched to pulseaudio and systemd, it's because the people who actually know about this stuff have looked at his work and found it excellent.
- enneff 12y ago> If most of the major distros have switched to pulseaudio and systemd, it's because the people who actually know about this stuff have looked at his work and found it excellent. Here's a theory. This is pure conjecture on my part—I'm not close to the systemd project or the various distros—so please take it with a grain of salt. Programmers prefer to do less work. Simple tools get the job done and are easy to understand, but often require more effort to use effectively. Using a hand saw, it is hard work to cut a solid piece of wood, but the only servicing it needs is to sharpen the blade. On the other hand, with a chainsaw it is much easier to cut through wood, but there are many more things that you need to care about to keep it running smoothly. When put this way, the hand saw seems superior in its simplicity, but remember that it's not immediately obvious that chainsaws can be difficult to start, or that the chains get stuck sometimes. Standing in the hardware store, the chainsaw might seem like the way to go, but one might regret not choosing the simpler option when complications arise later. It seems to me (conjecture, remember) that systemd offers a lot to the distros. It gives them hooks to manage difficult things and, after all, the systemd people are doing all the work. That explains why the distro maintainers might choose it, but my worry is that the convenience comes at a cost.
- laumars 12y agoSo you're assuming that I don't know about this stuff? And that the members of Debian who voted against systemd doesn't know their stuff? Or even that Linus Torvalds (who's often complained about how bugs in systemd get pushed back as bugs in the Linux kernel) doesn't know his stuff either? While it's true that systemd does have it's supporters; equally not everybody "who actually knows about this stuff" likes systemd either.
- pantalaimon 12y ago> Or even that Linus Torvalds (who's often complained about how bugs in systemd get pushed back as bugs in the Linux kernel) doesn't know his stuff either? When did that happen? There was one udev bug regarding firmware loading where during the discussion it turned out that it's the right thing to do that in the Kernel to begin with. How this is related to the greater systemd is beyond me.
- laumars 12y agoThe occasion that springs to mind wasn't an altercation between Lennart and Linus specifically. But it was about systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA (there's probably better write ups on this argument, Phoronix was just the first link that came up when Googling for the /proc/cmdline Linus systemd rant)
- the_why_of_y 12y agoThat is interesting... so basically the systemd developers wanted to turn the generic parameter kernel command line parameter "debug" into something that could be easily used by admins to find out why their system won't boot (whether the problem is in the kernel or in userspace), and got flamed to a crisp by kernel developers who want to keep using "debug" to debug their kernel code because they've always done it that way, and couldn't care less about helping actual end users.
- laumars 12y agoYou have things backwards. It was the systemd developers that didn't want the debug command line to be used against systemd. They were the ones who filed the patch to prevent the debug command line from reaching user space (/proc/cmdline) and it was the kernel developers (well, Linus specifically) who refused to patch and demanded that systemd cleaned up their debugging output so that 1) it didn't crash Linux (which it was doing previously), and 2) the output was more useful to end users for debugging.