Slashdot Mirror
Debian Dropping Linux Standard Base (lwn.net)
basscomm writes: For years (as seen on Slashdot) the Linux Standard Base has been developed as an attempt to reduce the differences between Linux distributions in an effort significant effort. However, Debian Linux has announced that they are dropping support for the Linux Standard Base due to a lack of interest.
From the article: "If [Raboud's] initial comments about lack of interest in LSB were not evidence enough, a full three months then went by with no one offering any support for maintaining the LSB-compliance packages and two terse votes in favor of dropping them. Consequently, on September 17, Raboud announced that he had gutted the src:lsb package (leaving just lsb-base and lsb-release as described) and uploaded it to the "unstable" archive. That minimalist set of tools will allow an interested user to start up the next Debian release and query whether or not it is LSB-compliant—and the answer will be 'no.'"
From the article: "If [Raboud's] initial comments about lack of interest in LSB were not evidence enough, a full three months then went by with no one offering any support for maintaining the LSB-compliance packages and two terse votes in favor of dropping them. Consequently, on September 17, Raboud announced that he had gutted the src:lsb package (leaving just lsb-base and lsb-release as described) and uploaded it to the "unstable" archive. That minimalist set of tools will allow an interested user to start up the next Debian release and query whether or not it is LSB-compliant—and the answer will be 'no.'"
Does FreeBSD support the Linux Standard Base?
> The sky certainly hasn't been falling with systemd
True. On the few hundred servers we've upgraded, systemd has been perfectly reliable and boots faster. Also, the custom units we've added work better than the typical Sys V init scripts my guys wrote in the past. It's great in that regard, but it does make it much harder to troubleshoot since stderr is swallowed and very often error messages don't make it into the journal.
would be to know where Debian is heading.
I'd very much like to support a distro which has clearly stated technical and societal values which mirror my own, but it's hard to distinguish exactly what Debian's values are anymore. Merely embracing GPL licensing and its values doesn't really tell you a lot, because even code with ethically questionable goals can be GPL.
Perhaps it's time for a Debian Conference in which "What do we stand for?" could be addressed and made a little more specific.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Yet, strangely, the only people I hear complaining about it (usually - note that this is usually) are those who haven't actually had any problems with it. I can see why they would prefer the older system (avoiding monolithic things is probably a good idea) but I don't see too many people complaining in the real world. There's one person, here on Slashdot, who's tearing it apart piece by piece. I think they're on section 8 or 9 of their process. Phantom someone maybe? I'd have to look and will do so if it is important.
Anyhow, they're pretty picky and they've got some pretty good ideas from what I've read. They're about the only one that I see being constructive. However, keep in mind, that the "Linux way" jumped the shark years ago - from the start, as I understand it. Unix, try Minix for an accessible and free version, uses a microkernel. Linux is monolithic in design - drivers don't run independently and failing drivers can crash a whole system where it is, as I understand it, easier to reload a crashed driver in a microkernel. I also understand there are some serious improvements to security by doing so but the expense is speed.
I could be missing something but a lot of the complaints that I read are those who are saying that it is just not the "Linux way." Well, Linux has already gone for the monolithic approach. It doesn't, to my eyes, appear must different to have a centralized initialization service to go along with it. I'm not seeing any problems there.
As an end user, well, I also don't have any problems with it. I learned a couple of new commands and Google the rest as needed. I keep adequate backups and don't even generally save anything locally if it's even remotely important. I save everything to NAS and call it good. At this point, to be honest, I'd love a thin client setup where I simply load a base and then select the OS, and keep my files and configurations between them with everything being unloaded to the network with the local CPU/GPU chugging away as needed. I'm not that patient, however.
"So long and thanks for all the fish."
Slashdot's hivemind seems to have decided that systemd is simply evil, with no clear reason why. I understand that we're all traditionalists, but this often goes beyond common sense.
Well then somehow you have missed all of the good points. None of these points are "rumors" and I will be glad to show you sources for each.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
Binary log files (PUKE)
Extremely poor documentation
Rushed to market with little objective testing
Bugs pile up with no resolution in sight, they just keep going for another dameon.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless. /me gets popcorn.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
Which has security implications. If they're implemented as separate daemons running with dropped privileges communicating via IPC then any attack on one does not put you in the execution context of the others. With systemd that can potentially happen. Eg a buffer overflow in the processing of DHCP packets could give you root access to the system via the init process, at a core enough level that you could make it a rootkit invisible to the sysadmin (eg hide it from ps etc).
Funny enough, I've noticed in every single *buntu instance where I've gone from upstart to systemd, the boot times have gotten longer. One of the many reasons why I figure upstart was a better choice to modernize the init system, it's actually better at the "being an init system" part! Unfortunately Canonical sabotaged any chances they might have had due to their CLA, but ironically enough upstart probably remains the most popular desktop Linux init system thanks to ChromeOS using it (and Google has shown zero inclination to change; I suspect if it really ever needs it, which it likely won't for quite some time, Google will just maintain a fork of upstart).
I remember sigs. Oh, a simpler time!