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.
(Score: 5, Insightful) by Anonymous Coward on Saturday December 03 2016, @08:10PM
systemd is a full-on assault on the UNIX design philosophy. Devuan is in protest and opposition to that. I run non-systemd Linux on several systems. My parents run non-systemd Linux on all of their computers (ironically, this essentially eliminated my family tech support burden).
That sentence implies that Devuan is not desktop friendly, and/or that systemd is more so, both of which are entirely false.
Obligatory car analogy: If you want to fix something on your car, would you prefer to study specifically to replace the plugs or have to fully comprehend and replace the entire electrical system? Because the UNIX philosophy is the former, while systemd is the latter. systemd looks ever so slightly better on paper, except where it improves is largely in the realm of "nobody cares" (boot time? When was the last time you rebooted your Linux system?). Then, when anything goes wrong, you're fucked.
Bring on Devuan - on the desktop. Or at least mine.
(Score: 1, Insightful) by Anonymous Coward on Saturday December 03 2016, @08:37PM
what if i am just a windows 7 user holding out until death? is this stuff easy to pick up on? be honest, i just expressed determination and perserverence despite all odds pointing against survival.
(Score: 3, Informative) by Anonymous Coward on Saturday December 03 2016, @08:52PM
Do yourself a favor and try Linux Mint. It's like a blazingly fast Windows 7 with an even better UI, updates, and no telemetry. Wine will run most common Windows applications at this point, Steam is there with a huge and growing gaming library. Not AAA titles but there's lifetimes of quality entertainment. Chrome is available and it'll play back your streaming service of choice.
(Score: 2) by mhajicek on Saturday December 03 2016, @08:58PM
Will it run professional grade CADCAM?
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 4, Informative) by butthurt on Saturday December 03 2016, @09:20PM
People have run AutoCAD under Wine, with varying results.
https://appdb.winehq.org/appview.php?iAppId=86 [winehq.org]
https://www.techwalla.com/articles/how-to-run-autocad-on-wine [techwalla.com]
http://www.architectafrica.com/bin0/news200411111_wine.html [architectafrica.com]
(Score: 2) by butthurt on Tuesday December 06 2016, @12:17AM
"Varying degrees of success" is what I meant.
(Score: 2) by mmcmonster on Saturday December 03 2016, @09:34PM
Wine will do a lot of stuff pretty well, and wine-based offerings like Crossover will give you confidence that your application will work (if it's on their list).
Another option is running Linux Mint (or other Linux variant) as your OS and create a virtual machine running Windows 7 for those times you need a package that only runs under Windows.
The fact of the matter is, if you need a package that runs Windows, you should probably be running Windows or looking for alternative applications. If you don't want to bother looking for alternative apps, why look for an OS alternative?
(Score: 2) by frojack on Saturday December 03 2016, @10:33PM
Agreed, sometimes you just run windows, even if it means running it in a virtual machine.
Wine is Crossover based, not the other way around.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by mhajicek on Sunday December 04 2016, @04:07AM
It's not a matter of "bother looking". In several years of looking I have found one professional grade CAM system that runs on something other than Windows and it would cost about $40k to switch over, discarding my current $20k software. 20 to 30 years ago most ran on Unix, but not so much any more. Many were acquired and discontinued.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 3, Informative) by Appalbarry on Saturday December 03 2016, @10:08PM
Assuming you have your Windows install media, it's easy enough to install VirtualBox, and run pure Windows inside Linux.
On any recent hardware it'll work fine, and avoid the quirks of Wine.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @12:56AM
If you have a valid key, you can download ISOs from Microsoft. That way the only spyware and viruses that come with it are from Microsoft.
(Score: 2) by captain normal on Sunday December 04 2016, @07:06AM
Gee..I sure don't need anymore of those.
Everyone is entitled to his own opinion, but not to his own facts"- --Daniel Patrick Moynihan--
(Score: 3, Informative) by butthurt on Saturday December 03 2016, @09:09PM
You could experiment with Linux by installing it in a virtual machine, or by finding a distribution that runs off a DVD or thumb drive. Here's a link to a list of distributions that are suitable for beginners.
https://distrowatch.com/search.php?category=Beginners [distrowatch.com]
(Score: 2) by Thexalon on Saturday December 03 2016, @09:39PM
Another option, if you have some older hardware lying around, is to use it to make that old Windows XP machine great again (Or at least usable). The wonderful thing about messing with old hardware like that is that there's no risk you'll ruin anything important, and you can learn a lot about how things work, or in more exciting cases how they don't work.
But yes, I highly recommend firing up Linux and trying it, because there's absolutely no obligations or costs other than time to doing so.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Insightful) by JNCF on Saturday December 03 2016, @09:28PM
Here's my argument for starting with Ubuntu: the sheer volume of tutorials directed at complete novices. If you go with Mint or Devuan you'll find less up-to-date information targeted at beginners than you will with Ubuntu. Ubuntu has a big community with a great newbie-helping culture. I view Ubuntu as a gateway Linux; you should start using Ubuntu because it's easy to find help when you hit a dumb wall like not knowing where a certain menu is, and you should stop using Ubuntu if and when you discover that Ubuntu has made something way more complex than it should be. There's a chance you never will make that discovery, in which case Ubuntu will have sufficiently insulated you from its underlying complexity and you won't have to worry about it; I don't know what you use your computer for.
I also think Ubuntu has a pretty decent default desktop environment with a nice starter set of keyboard shortcuts, which you can to view at any time by holding down the Windows/Meta/Super key. It's not my favorite, but I can unflinchingly say that I prefer it to Windows 7.
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @10:09PM
If you go with Ubuntu, install then login to gnome-flashback session. It's more like WinXP user interface than the Unity crap they now use as default.
(Score: 2) by VLM on Sunday December 04 2016, @01:17AM
I don't see anything factually wrong about your post, however WRT
tutorials directed at complete novices.
Very few novices write a custom initscript from scratch as their first experience with an OS. They won't know the difference.
apt-get install emacs is pretty much gonna do what it always did, etc.
(Score: 2) by JNCF on Sunday December 04 2016, @05:54PM
That's totally fair, I was actually thinking more along the lines of GUI-related ignorance. I don't know GGP-AC's use cases, but he might be a point-and-clicker -- and they still get frustrated when switching user interfaces. There are a bunch of tutorials available for Ubuntu users who get stuck on really simple tasks, and I've seen this be really helpful.
I woke up this morning realising that I'd failed to mention Ubuntu's very real GUI-related security concerns. No, I don't want to tell Amazon every time I search for an application locally. That should be opt-in, not opt-out.
(Score: 1, Informative) by Anonymous Coward on Monday December 05 2016, @12:01AM
The Ubuntu Shopping Lens has been disabled by default since April. [google.com]
This has been covered here previously. [soylentnews.org]
You can stop your hand-waving about this issue.
.
As for your previous post regarding tutorials, folks have to be careful that what they find applies to the version they are using.
In that respect, it's not so different from Windoze tutorials.
A large volume of how-tos is nice--as long as those are all actually applicable.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by hash14 on Saturday December 03 2016, @09:40PM
Unfortunately, no distro can do everything. It's very difficult to balance user friendliness with other considerations, like security, stability, or freedom of choice. For example, you wouldn't want to use a distro with an emphasis on user friendliness on a mission critical server.
Traditionally, what has happened is that there are upstream distros which focus on building a solid technical foundation or platform that other distros can build off. Debian used to be a good example of this, and then derivatives like Ubuntu and Mint focused on making them more user friendly while trying to maintain the benefits of the solid foundation that they were built on. Of course, since they adopted systemd, Debian ceased to be a sound technical choice, but hopefully Devuan can fill that void. If the project picks up steam, then I would very much hope that a similar effort to make a downstream user friendly distro off of that would result.
(Score: 2, Interesting) by Ethanol-fueled on Saturday December 03 2016, @09:27PM
https://www.youtube.com/watch?v=igDsu5QWhpo&list=RDigDsu5QWhpo#t=141 [youtube.com]
(Score: 1) by fritsd on Sunday December 04 2016, @06:03PM
Um.. should I propose the name "22817 Shankar" for the next Devuan version??
(Score: 5, Interesting) by tisI on Saturday December 03 2016, @09:57PM
Yes.
With the onset of systemd infecting Debian, last Deb release I ran was Wheezy.
Went to FreeBSD as primary and Mint as alternate utility system for now.
FreeBSD has a very nice and clean filesystem structure. No systemd here. Just easy to read and configure .conf files.
Additionally it is much faster than any Linux I have run, ever, and all software are near bleeding edge releases. Uncommon with Debian.
Boot times are a null issue as this box runs 24/7 and doesn't choke down and gag to a halt requiring reboots.
Systemd was the wet dream of M$ admins in a Linux environment, Red Hat, and fucked up linux.
Oh the irony, Red Hat 9 gave me the jump off point from M$ products so many years ago and now Red Hat has driven me from Linux to FreeBSD.
Good job! What will they fuck up next?
"Suppose you were an idiot...and suppose you were a member of Congress...but I repeat myself."
(Score: 3, Insightful) by VLM on Sunday December 04 2016, @01:14AM
A better car analogy would be something like you bring it in for a trailer hitch to be attached and some goofball insists that the 12V negative ground DC electrical system has to be replaced by 6.3 volt AC electrical system and then massive handwaving begins with "that's what tow trucks need in 2016" and "everything else can just change or go away"
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @07:18PM
Yes please! For us tube folks a 6.3 VAC filament supply would be a godsend.
(Score: 2) by jmorris on Sunday December 04 2016, @04:39AM
except where it improves is largely in the realm of "nobody cares" (boot time? When was the last time you rebooted your Linux system?)
Except Devuan even wins on boot time. Installed on an older Thinkpad it goes from grub to the SlimDM login prompt faster than the external LCD can catch up to the mode switching, i.e. screen goes blank after Grub as the kernel switches to the graphical console framebuffer and before it settles and displays an image again, the login prompt is there. This desktop machine I am on right now running Fedora (obviously with systemd) takes much longer to boot.
The problems with Devuan having a formal release seem to mostly be in the installer. Upgrading from Debian has been reliable for some time. And netinstall seems to work too. This has probably delayed the release, not enough pain to motivate the effort to squash the bugs.
(Score: -1, Redundant) by Anonymous Coward on Saturday December 03 2016, @08:37PM
...so long as it isn't systemd?
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @08:44PM
init-system-helpers [devuan.org]
This package provides helpers for all init systems (except systemd because we've removed that for Devuan, because it doesn't allow other init systems
(Score: 2, Interesting) by Anonymous Coward on Saturday December 03 2016, @11:57PM
Actually systemd does allow other init systems just fine. Even a lot of the stuff in the systemd repository will run fine without systemd being PID1! See syatemd-udev, which is actually used in devuan.
But systemd-init offers a service by managing cgroups and other unrelated software depends on that service being available. That is what makes it hard to switch to another init system. Those dependency is what makes it hard to use anything but systemd.
Devuan's solution to those dependencies is to just remove that code enrirely, mostly without even bothering to put in the code that the systemd-implementation replaced. That seems rather short-sighted to me: That code was added by developers for a reason (and no, they were not bough by Redhat, there are technical reasons for those dependencies), so just removing it without bothering to understand what that code does is dangerous.
E.g. running xorg in devuan less secure than elsewhere: Logind (which is one of the big things depending on the cgroups management service of systemd-pid1 can actually revoke access to the devices it hands out. So logind can enforce that e.g. xorg can not read keyboard input while you log into a virtual console as root. Devuan needs to hope that the x-server will play nice... that was good enough for decades, true, but going back behind what is the standard today wrt. security is something that needs to be discussed and documented so that users can make informed decisions based on their use-cases. I would currently recommend to stay away from Devuan on multi-user systems, but it probably is fine for single user machines (as long as you stay away from their horribly insecure custom network manager:-).
(Score: 5, Insightful) by coolgopher on Sunday December 04 2016, @01:15AM
The thing is, systemD isn't an init system, despite the frequently repeated statement to that effect. It's a monolithic replacement of everything from init through to just-below-the-desktop-UI. These days I believe it's even more monolithic than Windows, on which AFAIU it was modelled in the first place. It's a my-way-or-the-highway approach, with a large degree of fuck-you-all inserted, and goes against the core principle of Unix design - one tool does one thing, and does it well, and can be substituted as desired. Conceptually, it's going from e.g.
dd if=/dev/sda bs=512 count=2 skip=6 | xxd -g1 | grep 'AA 55' | cut -f2- -d:
to
somemotherfuckerofabinary --mode=readrawsector --sectors=6-7 --match='AA 55' --matchformat=hex --outputformat=hex --outputfields=2-17
and then you discover that there's no option to set the blocksize/sector size and it's hardcoded as 4096, or there's no way to specify the field delimiter for example. You lose a fuckton of power and flexibility down this path, and bugs get harder to deal with since there are no alternatives you can use in the meantime while said bug is getting fixed. From a developer point of view it's hell too, because all of a sudden you have a huge codebase that touches on all aspects of running an OS which you need to get your head around before you can dive in. It goes completely against accepted best practices in terms of architecture and design as well, which is to keep separate concerns, well, separate, and with well defined interfaces between the components. Whether it's classes, modules, libraries or separate binaries, the philosophy is the same.
While initially a monolithic design can be appealing due to the more rapid development cycle (by foregoing having to define the interfaces between components), over time this comes back to bite you. The weight of the design eventually causes the whole thing to collapse in on itself, and forces a complete rewrite of everything. Over my years as a developer, I've seen this happen over and over to this type of application. The ones who had the extra time spent up front to modularise have needed far less maintenance work to evolve to changing requirements.
I believe systemD is the worst enemy the Linux ecosystem has come up against to date, worse than Microsoft and SCO/Novell. That threat was sufficiently external that people bandied together to fight it. This one is more insidious, and has already caused a divide.
(Score: 0, Disagree) by Anonymous Coward on Sunday December 04 2016, @08:17AM
There were few facts in your post and there is no point to argue about personal beliefs.
Systemd is indeed more than an init: It is a project that wants to do the building blocks for an Linux-kernel based OS. There are lots of bits and pieces that can be used separately or together. There is no Linux distribution out there that uses everything and most use at least parts of systemd. Even devuan uses part of systemd! If systemd was as monolithic as you claim then that should not be possible, should it?
It is a layered architecture though: Starting out with the init system, logging and communicationat the base. That is the same design principle that is at work everywhere in Unix by the way.
Having the core system in one repository is another very unix-y thing by the way. The BSDs do exactly that from the very start.
(Score: 4, Informative) by fritsd on Sunday December 04 2016, @03:04PM
That is a bit disingenuous. The current version, Devuan Jessie uses systemd-udev, to stay as close as possible to Debian Jessie.
The reason is that udev, a critical component, has been absorbed by systemd.
For the next version, we're looking at alternatives for systemd-udev, and then Devuan will no longer use anything from systemd.
I'm not 100% sure if the alternative is already stable, because when I last looked half a year ago, there were some issues with the initramfs stage. And initramfs stage is difficult to debug.
I agree with you when you say "If systemd was as monolithic as you claim then that should not be possible, should it?".
With respect to systemd version 215 from 2014, which provides the udev that is still used in Devuan Jessie.
I don't speak for Devuan, but personally I don't trust that systemd udev would stay "buildable" without the rest of systemd in the future.
(Score: 2) by Justin Case on Sunday December 04 2016, @04:33PM
udev, a critical component
Serious question: why is it critical? I'm not sure I want it there at all. It seems to cause trouble, and I'm suspicious of root processes that run forever with no perceived value.
From what I can find without hours of research, it changes /dev entries when hardware is added or removed. Well I certainly don't want to do that! On the rare occasions when I do upgrade my hardware, I'll expect to create the appropriate /dev entry once and not have it shifting under my feet like quicksand.
What am I missing?
Did you mean to say that it is "critical" for unstable hardware configurations?
(Score: 2) by fritsd on Sunday December 04 2016, @05:52PM
Yeah, I think I said it wrong. From a wrong perspective.
udev is not critical, in the sense that your server will boot fine without it, if you have a simple disk layout.
If your root filesystem is an encrypted filesystem on an LVM2 logical volume on a RAID 5 array, then your initramfs has to do a lot of complicated stuff before the final root filesystem is available for booting from.
I think this includes creating new device inodes when they become available (e.g. after mdadm has assembled a RAID array). I don't actually know if it would work to
mount /dev/md0 /
if the kernel would somehow try to assemble the /dev/md0 raid itself from its component partitions' metadata (which are the component partitions??). I haven't studied the code, but I think the mdadm userspace program does that.
Now that I have read "man 4 md" I'm doubting.
For people like me who use Linux as a workstation with a GUI (most of the time), it's nice that you can plug in USB stuff and have it working. That's an important function of udev. And when you plug in a USB device it adds new hardware
(the system couldn't know before what you were going to plug in).
I've had to modify some udev rules to get my mobile phone recognized so that I can access it with adb (Android development) as non-root. So it's a program to regulate user access to hardware.
From my perspective, which is a really odd and uncommon perspective (sorry), udev was "critical" because it was a big log in the systemd "log-jam" [wikipedia.org] of dependencies in the low-level base Debian system.
(Score: 2) by butthurt on Sunday December 04 2016, @10:29PM
If your root filesystem is an encrypted filesystem on an LVM2 logical volume on a RAID 5 array, then your initramfs has to do a lot of complicated stuff before the final root filesystem is available for booting from.
The man page for udev says it's for "dynamic device management." Your example isn't dynamic. The grey-beard way was mknod, perhaps run from a /dev/MAKEDEV script.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @09:35AM
Xorg requires +s/suid on systems where either init is used or the systemd configuration is broken (mine is the latter, since it was an older system upgraded from init, apparently without distro provisions to handle that migration outside of an upgrade cd/program instead of a package manager.)
The infuriating part about it is that X doesn't have error messages which make it clear what the failure is when the Display Manager triggers the user change and attempts to log in. I finally after a few hours found a forum post mentioning the error being the permissions shortcomings of X when run without suid or logind. Upon setuid, X login worked as expected.
Much like my complaint about Linus elsewhere, the X.org guys have been phoning it in for years on the features they should fix in X, similiar to issues with the kernel and the missing features in sysvinit/alternatives compared to systemd. And *NONE* of these groups of developers are bothering to make clear and concise new documention covering the features, errata, and known gotchas of interaction with common applications that would help reduce debugging burden due to insufficient error messages, common configuration issues. :(
(Score: 2) by butthurt on Sunday December 04 2016, @08:43PM
"The wrapper is loosely modelled after the existing Debian Xwrapper," says the Xorg commit log.
https://github.com/mirror/xserver/commit/e7b84ca46944895971a8f048c7e34869b7de01c0 [github.com]
Running a non-suid X server was not just possible, but was the default, with XFreee86 in 1999:
https://groups.google.com/forum/?_escaped_fragment_=topic/comp.windows.x.i386unix/7QOVG3xanSM#!topic/comp.windows.x.i386unix/7QOVG3xanSM [google.com]
From a better-formatted copy of the same text:
Q.E14- What is Xwrapper and why can't startx or xinit find it?
The XFree86 X servers require root privileges to access the video hardware. In releases prior to 3.3.2 the X servers were installed set-uid root so that normal users could run them with the required privileges. This is a potential security problem, especially given how large and complex the X servers are. One class of such security problems is exploiting the set-uid program with carefully crafted user-supplied data (either on the command line or in the environment). Starting with the 3.3.2 release the XFree86 X servers are installed without the set-uid bit set, and a small wrapper program ``Xwrapper'' which is installed set-uid root is used to start the X server after checking the command line and environment. This does not provide a 100% guarantee that the X servers are not vulnerable to such exploits, but it does reduce the chances of such exploits succeeding. Also, if vulnerabilities are found in the future that the current Xwrapper doesn't catch, we can easily supply an updated version. It is much easier to do that than to provide updated versions of all the X server binaries.
The xinit command (which startx runs) provided with XFree86 3.3.2 and later has been modified to look for an X server called ``Xwrapper'' instead of ``X''. If you don't have Xwrapper installed, you will get an error message from xinit/startx when it tries to start the non-set-uid X server without using the wrapper. The same thing will happen if you do have Xwrapper installed but you have an xserverrc file (usually $HOME/.xserverrc, but it can be any file pointed to by your XSERVERRC environment variable) that references ``X'' instead of ``Xwrapper''. To fix that, edit your xserverrc file and replace ``X'' with ``Xwrapper''. If instead of X you have some other X server name (eg, XF86_SVGA) in your xserverrc file, you will need to create a symbolic link from it to /usr/X11R6/bin/X and replace it with ``Xwrapper'' in your xserverrc file.
We strongly recommend against making the X servers set-uid root because of the potential security implications of doing so. We also recommend running xdm at boot time to handle starting the X server on a multi user system.
-- http://www.fifi.org/doc/xfree86-common/XFree86-FAQ.html#Xwrapper [fifi.org]
(Score: 3, Interesting) by Bot on Saturday December 03 2016, @09:21PM
are you seriously suggesting that the debian fork without systemd should waste development effort readding it?
Account abandoned.
(Score: 2) by fritsd on Saturday December 03 2016, @10:17PM
Well, it was actually suggested by someone on the mailinglist.
But no, it was regarded as "we don't support systemd anymore" ;-)
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @10:30PM
Surely some people want to have the option of using systemd. Packages that support it along with other init systems could--politics permitting--be included in Debian, so they wouldn't have to be maintained separately.
(Score: 1, Informative) by Anonymous Coward on Saturday December 03 2016, @10:33PM
Debian already exist for those people.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @12:03AM
Really, systemd is optional in Debian? Then there is no reason to have Devuan.
(Score: 2, Disagree) by Aiwendil on Sunday December 04 2016, @09:14AM
It is - just requires that you blacklist systemd (or append "systemd-" to any and all upgrade, install, remove et.c operations) and that will case apt to find alternate solutions.
(Do anyone know if there is a way to make sure apt enforces a certain package is alwsys installed?)
Of course it probably will land you in depenncy hell (in part due to some solutions will prevent systemd-shim [helper to reduce the systemd-mess on systemd-free systems] from being installed, and in part due to some packages requiring systemd without offering alternatives [knowing how to alter and rebuild deb-packages is very helpful])
Heck, the official debian way to run a systemd-free debian [debian.org] is to just install a conflicting init (which will cause apt to kick out systemd and all that depends on it with no other requirement-ruote)
(Score: 4, Interesting) by fritsd on Sunday December 04 2016, @03:13PM
I'm a long-term Debian user.
When I upgraded from Debian Wheezy to Debian Jessie, it installed systemd.
Without asking, without even a mention in debconf, that I can recall.
Then my system was fucked up.
Then it took me more than a week to try to extricate all the packages that depended on packages that depended on packages that suddenly depended on systemd, but never did before.
You are right: it landed me in dependency hell.
Maybe it's me, but I found that it was really *extremely difficult* to remove systemd; even with 20 years experience with Unix, Linux, Debian, even as an amateur dpkg package builder, it was extremely difficult.
Then I became a Devuan volunteer and shared my experiences modifying packages to remove the dependencies! So it all ended OK ;-)
(Score: 2) by Aiwendil on Sunday December 04 2016, @10:46PM
Ahh, I avoided systemd by doing a crapload of apt-get install systemd- foo bar baz (and apt-get --dry-run dist-upgrade to get a list of what was needed) until I got a clean enough apt-get upgrade
(I'm in the habit of doing it that way since I've gotten my system hosed by bad libc [static linked dpkg and lynx are in my toolbox], conflicting perl-packages [always intersting to upgrade perl-base] and gotten gnome accidently installed once (took a while to get my system back to "login at console" after that one) over the years - so I distrust anything I havn't check by checking the output of apt-get --dry-run $command first)
(Score: 1, Informative) by Anonymous Coward on Sunday December 04 2016, @09:41AM
The entire point of devuan was that the leadership of debian voted down attempts to keep systemd optional and provide alternatives to systemd because 'too many other packages rely on it.'
As a result of that schism a number of dissenters were forced out/quit and spun off devuan instead.
Personally I think it was a good thing. Deb+Ian have been dead for years, Ian himself has been dead for a year. The Debian distribution has been dying for a long time, and this is just finally an opportunity to put another nail in its coffin as it slowly fades into irrelevancy (well outside its basis as the foundation of Ubuntu.)
Having said that: Adding support for systemd to devuan shouldn't be too hard. The biggest issue is finding a way to include optional systemd configuration packages for devuan packages that no longer contain them (most distros and a number of source packages install them by default whether you wanted systemd config files or not, cluttering up your filesystem, esp given most of them install to /usr/lib/systemd or elsewhere rather than /etc like config files are supposed to. Xorg isn't helping with that nowadays either, putting its default config files in /usr/lib and having /etc/X11 only being overrides. But then again they think dbus is a spectacularly good idea.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @10:40AM
As a result of that schism a number of dissenters were forced out/quit and spun off devuan instead.
That is false as none of the people involved in Devuan have been part of the Debian project before.
They are people who haven't worked on a real Linux distribution (i.e. not just a live image) before and are slowly starting to try and figure out how this works. There is a reason they can't do any estimates on how long something would take.
(Score: 2) by fritsd on Sunday December 04 2016, @06:06PM
I was never a DD; don't know about the others. I'm not sure you can generalize.
(Score: 0) by Anonymous Coward on Friday December 09 2016, @09:47AM
I'm not sure you can generalize.
It's a fact that none of the Devuan developers were members of the Debian project.
Unlike your feelings it could be proven wrong (if it were not true).
(Score: 2) by Bot on Monday December 05 2016, @10:45PM
In fact Jaromil worked at dyne:bolic which is a live image.
This is not a matter of experience. Given the real reasons for pushing systemd, I expect that it will be tears and blood for those wanting to remove it, or on the other hand master it, no matter their experience. Systemd is complicated and, according to the creator, always a moving target, Android style. It does not matter if the doors are unlocked if you have to open 343349 of those to go for one room to another.
Account abandoned.
(Score: 2) by hash14 on Saturday December 03 2016, @09:30PM
I'm not sure if systemd can be installed or not, but without a doubt, Devuan comes with a better default init system.
But systemd is all about eliminating choice anyways, so while there's an illusion of choice on Debian and other distros today, they are with no uncertainty marching to a world where that's not the case.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @08:21AM
Sure. Sysv-init/sysv-rc is a great combo. That is probably why literally every Linux distribution is dumping that for systemd, OpenRC, epoch, and lots of other replacements.
Even in devuan there is lots of talk about replacing sysv-rc eventually.
(Score: 2) by butthurt on Sunday December 04 2016, @08:19PM
According to the Slackware Web site, they haven't dumped sysvinit.
http://www.slackware.com/config/init.php [slackware.com]
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @09:59PM
What about Upstart? Works pretty well in Ubuntu 14.04, although I see Canonical has since moved to systemd.
(Score: 1) by zoward on Saturday December 03 2016, @10:17PM
Ubuntu felt they more or less had to. They're downstream from Debian, and Debian had already decided to go systemd. They felt it would take too much effort to have to maintain the modifications it would take to keep all the downstream applications that had added systemd as a dependency running correctly. I'm looking forward to trying Devuan out on my server.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @09:31AM
Considering that very a third of the members of the Debian technical committee work on Ubuntu, I dare say that ubuntu had its fair share of influence on Debian's decision.
(Score: 2) by fritsd on Saturday December 03 2016, @10:14PM
Of course you can try to install systemd on your Devuan machine, nobody is stopping you doing whatever on your own machines.
Whether it still works is your problem; you can download and study the systemd source.
If you want to have systemd as init system, please consider Debian instead of Devuan.
Debian is basically Devuan + systemd support ;-)
(Score: 3, Insightful) by MadTinfoilHatter on Sunday December 04 2016, @06:02AM
Debian is basically Devuan + systemd support ;-)
While I realize you're (partially) joking I think there is a need to clarify this issue, which the starter of this thread seems to not have grasped:
With Debian you can pick any init you want, but if you pick anything except systemd, you're relegated to second class citizen status. Some things won't work with non-systemd inits, because everything is built from a systemd-über-alles point of view. With Devuan you can pick any init you want (except of course systemd), and will still be a first class citizen, no matter your choice.
I think Devuan is doing the sane thing. Systemd is basically like a bully in the sandbox, who refuses to play nice with anyone else. The right thing to do is to banish the bully from the sandbox until he learns that if he won't play nice, he won't play at all.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @08:31AM
Actually with devuan you can install any init system and you get a second rate experience with all of them. Upstream projects do use systemd to improve security, features or convenience and that then gets removed by devuan.
Systemd does play nice with a lot of developers and helps them solve problems in the Linux platform. Yes, it does break stuff in the process. Yes, that is annoying at times. But at least the platform improves that way.
(Score: 2) by canopic jug on Sunday December 04 2016, @11:50AM
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @01:53AM
Well, it'd be Debian then, wouldn't it?
(Score: 3, Interesting) by Subsentient on Saturday December 03 2016, @09:00PM
I need to resume work on SubLinux 3. Powered by Epoch [universe2.us] for the init system with a new package manager, packrat.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by JNCF on Saturday December 03 2016, @10:22PM
Do you have an overarching plan for which pieces of SubLinux you're eventually going to replace with tools you've written yourself, or are you just winging it as you go and adding the stuff you write and use? Somewhere in-between? Do you think the first public release of SubLinux will include all of the projects you have listed on your website and github, or are you leaving out the particularly niche stuff like aqu4bot?
(Score: -1, Troll) by Anonymous Coward on Saturday December 03 2016, @10:08PM
Congratulations to MikeeUSA and team to the new Beta release!
With seven updated packages since the first Beta six months ago (according to ci.devuan.org), it looks like nothing can stop the success story here.
(Score: 5, Informative) by fritsd on Saturday December 03 2016, @10:24PM
MikeeUSA was more active (as in: toxic radioactive??) on the mailinglist than actually fixing packages, I think.
He managed to troll lots of people away from Devuan though, before Jaromil kicked him off the mailinglist.
I hope he's in Syria now with his underage bride(s).
I think you just said: "The Devuan devs have proven that, with only the effort of changing 7 packages, the yoke of systemd can be cast off." Right?
Thank you for your appreciation and confidence in our distro!!! :-)
(Score: 1) by butthurt on Saturday December 03 2016, @10:51PM
When contributing to Devuan did he use the handle "sgryphon"?
https://web.archive.org/web/20161203223325/https://osdir.com/ml/debian-user-debian/2016-04/msg00891.html [archive.org]
(Score: 4, Informative) by fritsd on Saturday December 03 2016, @11:39PM
I don't remember. The mailinglist is fairly high-volume, often I just browse it.
I think in june 2016 it was "concernedfossdev".
This is a link to a link to a discussion of mikeeusa:
https://lists.dyne.org/lurker/message/20160611.125957.f0c41553.en.html [dyne.org]
I'm glad he was banned, nobody else pulled the level of discussion down as much as him. It was really not normal what he all said (even for the Internet).
That's why I got annoyed at the comment here about Devuan: "mikeeusa and his team".
(Score: 0) by Anonymous Coward on Tuesday December 06 2016, @07:54PM
yes.
(Score: 2) by butthurt on Tuesday December 06 2016, @09:05PM
The OP insinuated that MikeeUSA was the project's leader, but he doesn't seem to be listed at all among the project's principals:
https://devuan.org/os/team/ [devuan.org]
I'm inclined to believe the message linked by fritsd that says MikeeUSA was banned from the project's mailing list, and I'm inclined to believe fritsd's statement that MikeeUSA was more active on the mailing list than in contributing code. I would assume that his code, if any, has received extra scrutiny.
(Score: 0) by Anonymous Coward on Sunday December 11 2016, @12:24PM
MikeeUSA contributes only to videogames in freedom.
ChaosEsque Anthology has been submitted for packaging, though it takes up a full dvd...
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @11:03PM
Heh, good point! They aren't rebuilding every piece of Debian here...
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @10:34AM
The Devuan devs have proven that, with only the effort of changing 7 packages, the yoke of systemd can be cast off.
So you say Devuan forked Debian over *seven* packages? And took over two years for that?
And that to change the default init system to another one supported in Debian?
(Score: 2) by fritsd on Sunday December 04 2016, @04:06PM
Um.. Devuan sounds a bit pathetic, the way you put it across.. lemme try to express it a bit more positively.
I don't speak for the others, but I just wanted to keep on using Debian!
We didn't want to fork, it just ended up that way :-) because we felt that we had to.
My general impression is that it was not an act of hubris, but instead "This needs to be done. Looks like nobody else wants to do it, so we will have to, even if we're maybe not the best."
I have a strong *belief*, i.e. cannot prove rationally, it's just a hunch from personal experience, that systemd is an evolutionary dead-end, because of the complexity caused by unnecessary interdependency.
Also, there's the fact that the Debian leadership has chosen to support systemd as the only init system from Debian Jessie onwards.
Also, I and others found out that it is very difficult to un-install systemd and choose another init system (e.g. sysvinit, although nobody claims it's the bee's knees)
I *believe* (no proof) that, the way systemd has been developed, it would only become more and more difficult in the future to construct a basic low-level Linux infrastructure, based on Debian,
that does not depend on systemd.
In conclusion to what i just said, I really *believe* that the Debian project, Red Hat, Ubuntu, and other projects, have tied the millstone of systemd around their necks. Voluntarily. And that it will drag them down, unless they cut loose from it.
I need Linux for work! That's a tragedy, if they all become crappy distros!
Debian in particular forms the basic groundwork of lots of smaller specialized distros.
picture: humongous family tree [wikimedia.org]
That picture proves that in practice, Debian is particularly suited as a basic disc of prepared dough to make all kinds of different pizzas with (some tastier than others).
But now Debian is inextricably tied to systemd. Then you can either just give up and learn to love systemd, or you can try to fork Debian sooner rather than later.
All the wailing and gnashing of teeth, and bitching at L.P., on the mailinglist was fun and cathartic, but after a few months, a few people in the world decided to do something difficult but constructive and actually go ahead and fork Debian, and that's how Devuan saw the light.
I have enormous respect for all the work that Debian people have done in the past 20 years. But for me personally, I really think Devuan has more future, because it still has the resilience and flexibility(*) of the Unix philosophy, just like Debian Wheezy.
So when I have time and energy, I try to help the Devuan project.
It is discoverable (with lots of effort)
It is maintainable (with effort)
It is repairable (with effort)
just like all Linux distros before, and like the big Unix stuff before that.
(*) (Personally I dislike D-bus, logind and consolekit as well, but maybe I'm just crazy)
Um.. yes? Feel free to help out if you have time and energy to spare. In fact, feel free to hire me for .deb packaging contracting work, I'll have LOTS more time and energy available then.
Yes. In order to preserve the ability for Devuan Linux users to switch to MuchBetterInitSystem2030 in 2030, if you want to put it like that.
There are developers of alternative init systems that have shown interest in Devuan, so maybe we'll be able to provide a few that Debian doesn't have.
There can be only one init system running, and Debian has systemd and it won't let go, so I can't see a future for any init systems other than systemd in Debian and descendants.
Even when (not if!) something better is developed. Future progress in this arena is now permanently blocked in Debian!
(Score: 0) by Anonymous Coward on Friday December 09 2016, @09:43AM
I have a strong *belief*, i.e. cannot prove rationally
Nothing more needs to be said.
Devuan, Trump, ...: all about "feels" and "beliefs", less about reasoning or rational conclusions.
the fact that the Debian leadership has chosen to support systemd as the only init system from Debian Jessie onwards
And as usual mixed with untrue statements presented as "facts". Welcome to post-factual reality!
(Score: 2, Informative) by Deeo Kain on Saturday December 03 2016, @10:40PM
I got well over half-a-dozen updates in the last week alone...
(Score: 0) by Anonymous Coward on Sunday December 04 2016, @08:00AM
You probably confuse "updates provided by Devuan" (that are taken from Debian) with "packages people in Devuan have worked on".
(Score: 2) by requerdanos on Saturday December 03 2016, @10:50PM
I'll be curious to see whether Devuan can produce a stable "Jessie" release before Stretch comes out. Their announced target was to have it ready about the time Jessie came out.
(Score: 2) by fritsd on Saturday December 03 2016, @10:55PM
I just read on the Devuan mailinglist about a systemd issue:
Here comes the shameless Devuan advertisement:
On Devuan, you don't have this issue :-)
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @11:28PM
Actually you do: Udev is still used in devuan (the one from systemd, too). Udev will potentially run a lot of stuff. Do you want all that in /? Someone might want to run /use from NFS, somebody else might want to use crypto, somebody else might want to amb-mount /usr, or use ceph or whatever new networked OS.
If you want to keep / functionalmenough to bring up /usr for all those use cases you need to move a lot of junk into /. And there is no way for distributions to check that they really got everything covere, which means the whole thing is hit or miss. Go and check the bugs open in all distributions about exactly this kind of issue! Now add all the siscussions about whether something needs to be in / or /usr. A lot of time is wasted there.
This is something that is driven by distributions, not by systemd.
(Score: 5, Insightful) by srobert on Sunday December 04 2016, @01:50AM
The article at the Register depicts Devuan as having been started by a bunch of old crackpots who think Linux has become too desktop-friendly. Legitimate concerns over systemd are dismissed with a "chicken-little" reference. Overall the author seems to be parroting the dismissive tone of systemd advocates who don't feel they should have their decisions questioned.
(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.)