SoylentNews is people
SoylentNews
Greybeard-built Debian fork bringing init freedom on track for early 2017 release
The self-proclaimed "Veteran Unix Admins" forking Debian in the name of init freedom have released Beta 2 of their "Devuan" Linux distribution.
Devuan came about after some users felt it had become too desktop-friendly. The change the greybeards objected to most was the decision to replace sysvinit init with systemd, a move felt to betray core Unix principles of user choice and keeping bloat to a bare minimum.
Supporters of init freedom also dispute assertions that systemd is in all ways superior to sysvinit init, arguing that Debian ignored viable alternatives like sinit, openrc, runit, s6 and shepherd. All are therefore included in Devuan.
-- submitted from IRC
This discussion has been archived.
No new comments can be posted.
systemd Free Linux Distro Devuan Releases Second Beta
|
Log In/Create an Account
| Top
| 82 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Our business is run on trust. We trust you will pay in advance.
(Score: 2, Funny) by Anonymous Coward on Sunday December 04 2016, @04:18AM
Systemd is an ill conceived, poorly designed, incompetently programmed attempt at an OS that sits atop of the Linux kernel.
There's a whole heap of absolute crap on top of Linux these days: systemd. Network manager. Udev. Dbus.
No. Dbus is not the right design. It began as a hack, and now, some really incompetent developers think dbus should be in the kernel. That concept is so fucking wrong it makes my brain hurt.
You incompetent fucking cunts want to adopt systemd and move dbus into the kernel? Dbus, a thing designed to replace corba? Fuck you all.
Linux absolutely fucking sucks in 2016. It's been overrun by the hipster bearded laptop Linux to be cool types, and not people who do actual work.
Fuck you Lennart you cunt.
(Score: 2, Interesting) by Anonymous Coward on Sunday December 04 2016, @09:27AM
Ever since the Bitlocker bullshit, Linus has jumped the shark in delegating and maintaining the kernel.
You want an example? Try manually configuring a kernel today. There are *HUNDREDS* of options that are arbitrarily turned on that the average user would never need, even in option trees that are otherwise *OFF BY DEFAULT* (This ranges from specific drivers to options and features that almost nobody outside distribution kernels would need to enable.) In addition to being a bad idea from a compilation time/kernel+module bloat, it is a massive potential security issue when new features and modules are enabled by default in the kernel config and especially updating the .config file used against past kernel releases. Not all new config options result in prompts. Some are simply silently added and unless you go back through manually you might never notice them. If one of those features (un)intentially has a security defect, you've just unwittingly added attack surface to your kernel, perhaps meant to intentionally create an exploit or favorable conditions for one!
Expanding on this: Many of these new config options are so underscrutinized that they are ARCH-SPECIFIC without arch specific tagging. Meaning you have ARM/SoC options showing up in the x86 configurations now (SoC audio and possibly GPU/Framebuffer options that are IP not available on x86), as well as tons of hardware options on non-x86 hardware that obviously never had/will have it.
Honestly the problem at this point isn't just the linux distros, it is the organization of the linux kernel itself. It needs a major overhaul. Separation of code between both arches, and generations of hardware (say split off core kernel code into an i386->i586 kernel loop, i686->pre x86_64 p4, then x86_64 to modern power management, then modern power management+). Additionally rather than constantly moving targets, the driver architecture needs to be 'snapshotted' with fixed features and kernel requirements for each generation iteration of BUS/kernel interface ABIs. The number one reason for this is so that reference drivers can be stabilized on a fixed codebase so that future architectural changes to the drivers and interfaces can be regression tested on a harness against a documented operating system (even if it is not known to be 100 percent stable, which honestly is becoming more of a problem by the year for linux, especially among filesystems and advanced power management features/firmware interacton.)
Lennart, as bad as he is, is still just a small fry developer in comparison, but Linus has given the example for him to reach cult-like status in the development community, over plenty of other developers just as if not more competent. That said: I think the past 7 years has resulted in the hardware equivalent of systemd, which has resulted in far more damage to both the hardware and software ecosystem than anything that happened in the past. (Short of the alternate future where clipper-chips went mainstream.)