SoylentNews is people
SoylentNews
The antiX Linux project announced version 17 of its distribution:
The developers of the Debian-based antiX GNU/Linux distribution announced the release of antiX 17, dubbed "Heather Heyer" and based on the Debian GNU/Linux 9.2 "Stretch" operating system.
antiX 17 follows the trend of previous versions to offer users an operating system that does not include the widely used systemd init system. With this release, Gentoo's eudev device file manager for the Linux kernel is used by default instead of udev.
Eudev is a fork of udev, made by the Gentoo project to avoid dependency on systemd.
Also at It's Foss and Distrowatch.
Related: Q4OS: A Very Flexible Linux Distro - Review
This discussion has been archived.
No new comments can be posted.
antiX 17, a Linux Distribution Without Systemd, is Released
|
Log In/Create an Account
| Top
| 33 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Hey, wait a minute!! I want a divorce!! ... you're not Clint Eastwood!!
(Score: 1, Disagree) by opinionated_science on Monday November 06 2017, @11:57AM (15 children)
Is there an actual use case for text only system start up?
systemd has has its *issues* for sure, but it has also greatly simplified the process of getting a reliable boot on dodgy hardware.
So I'm ambivalent leaning towards supportive of systemd.
The one technical advantage of the systemd approach, is that rc-scripts are so massively prone to error or corruption, as they are free format.
(Score: 2, Informative) by Anonymous Coward on Monday November 06 2017, @12:34PM (1 child)
Servers. Embedded systems. People who need speed and not eye candy.
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @02:13PM
And myriads of corner cases, like a funky network card (integrated, really) that does not always goes back up in a reboot. I found that the plain, non parallel init works best of all other systems because it displays the DHCP handshake and lets me unplug/replug until it works. All init "improvements" boot to a no network state, requiring me to login as root, take networking down and back up, so I can get to the dhcp handshake again.
(Score: 4, Insightful) by Anonymous Coward on Monday November 06 2017, @01:29PM
Thing is that systemd keeps growing and taking over various non-init related tasks.
Bloody thing has its own inetd in there now, never mind things like logging. And the less is said about the whole consolekit/logind/polkit mess the better, it was a bad idea from the start but now it has become mandatory.
(Score: 5, Insightful) by Thexalon on Monday November 06 2017, @02:47PM (1 child)
Any time you don't want/need a GUI. Or any time you want to see what went wrong to cause a boot failure.
On the contrary, I've found it considerably less reliable than many non-systemd boot systems. Mostly because if something isn't working, other init systems will attempt to keep going without whatever isn't working (so, for instance, you don't render yourself unbootable if you broke the Mysql script), and also a manual recovery option if all else fails, whereas systemd will give you a blank screen of death. I learned this the first time when I tried to boot a systemd box with my mouse unplugged, and discovered that alone bricked it.
Not really: If you don't know shell scripting, just leave them alone and your distro will get it good enough. If you do know shell scripting, then you should be able to fix your problem. As for random users messing with it, you aren't giving out root or full sudo access to everybody, right?
The idea that the shell scripts are bad or confusing is mostly FUD from the pro-systemd camp.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by opinionated_science on Tuesday November 07 2017, @10:43AM
there's far too much FUD in this world , masquerading as "debate" when really it is "listen to me!!!!!!!!".
I personally think that has much hate has LP gets, I only listen to those who write an alternative.
So I'm glad a systemd-free version exists. I'm well aware there may come a use-case for it, and I'll be grateful.
Right now, kinda loving systemd working well - KDE was a *pain* however....
(Score: 0) by Anonymous Coward on Monday November 06 2017, @03:03PM
HTF can you say SystemD makes booting on dodgy hardware easier, when the simple alternative would be to have a simple init just start a shell?
Afaik SystemD doesn't require graphics or gnome yet, but how would you like to have to get that working on your dodgy hardware as a condition to boot?
I wrangle many embedded servers; I don't care about parallelised boot because 1) I don't have a habit of rebooting my servers and 2) the init system needs to just start the workload and get out of the way.
Thankfully nobody is pooh poohing these SystemD free distros here yet, but let me throw out that hard dependencies on SystemD as init will preclude software from working on the BSDs, which have a higher consensus on being allowed to exist.
(Score: 3, Insightful) by mth on Monday November 06 2017, @04:09PM (8 children)
It's not about graphical vs text: systemd can do a text-only boot while a graphical splash screen can work with any other init system. The package that is most often used to provide a graphical splash screen is Plymouth [freedesktop.org].
How does systemd make that more reliable? For me, the parallel nature of systemd has made booting less reliable, since if there is an undeclared dependency between boot tasks, the task that needs the dependency might boot fine on other people's machines but break on mine because the timing is different.
I think the main problem with rc-scripts is that there is a lot of boilerplate code that is copy-pasted between scripts and not kept in sync, and is distro-specific as well. This could have been solved by creating a library of standard functions; LSB attempted a bit of that but it didn't really go far enough in my opinion.
I also don't like that sysvinit requires the admin to order the startup tasks manually (S75mydaemon etc). Instead, an init system should look at the dependencies and order the tasks automatically. But for reliability it would be better to store the ordered list and boot the same sequence every time instead of determining the next task dynamically during boot.
The main problem I have with systemd is that it is not modular and keeps expanding in scope.
(Score: 3, Informative) by KritonK on Monday November 06 2017, @04:29PM (6 children)
This. My first experience with systemd was that, after upgrading to the first version of Fedora that used systemd, my computer would not boot. It turned out that there was an entry in /etc/fstab, referring to a disk that I was no longer using. Before systemd, the non-existent disk would simply not be mounted, and everything would be fine. With systemd, it was all my fault, so I should be punished by having my computer become non-bootable, with no obvious clue regarding what went wrong, so that I might have a chance of fixing it. It took me quite a while to figure what the problem was, wasting more time than the accumulated speedup in boot time, if any, achieved by using systemd since then.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @05:20PM
Just to throw in another current, fun systemd'ism. I have a centOS server that occasionally reboots. Why?, hmm well journald usually shutsdown 10-12 hours before the system reboots so there are no logs, heh. Well, there is some logs, but they are out of order, there is some duplicate blocks and of course 10-12 hours are missing altogether.
Is it hacked?, is it just systemd that is borked? Who the fuck knows? I need to treat it like it's hacked, but it is probably just hacked by systemd. What a mess.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @06:15PM (2 children)
Ah yes, the change in the handling of mount exit codes.
Previously most init solutions ignored most errors because the error message itself would be printed on screen (and if anything other than / failed to mount, it could always be fixed manually later).
Systemd devs claims they do it the way they do to avoid incorrect writes by "services" in places they should not.
This because the focus of systemd has long since left the desktop (where they initially claimed to boot faster, but now don't want people to talk about boot times at all), and is no firmly on managing container farms in the cloud.
(Score: 2) by KritonK on Tuesday November 07 2017, @10:19AM (1 child)
So it wasn't only my impression that systemd has stopped touting its supposedly fast boot times.
Interestingly enough, I read somewhere that Void Linux achieves it fast boot times because it doesn't use systemd!
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @02:19PM
Void linux has a fast boot/shutdown and a fast package manager. Runit scripts are also straightforward compared to "yo let's implement a DSL to boot, it should be fun" systemd. If I cared about the boot process I'd try void before all else.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @08:11PM (1 child)
I have an internal file server that runs CentOS 5. Even though it is an internal-only machine, our policy at work is to strictly enforce the system update process. After one update, my system is fucked. It can't talk on the network any more. I used to be able to still ssh into it, but that stopped as well (timeouts when trying to connect). The local console works ok, but anything in desktop mode takes FOREVER (try to open an application, etc.). I've been down the rabbit hole of troubleshooting with most advice talking about how IPV6 needs to be disabled (which I did), but nothing has worked for me so far.
I hadn't thought about systemd fucking it up; things were working just fine until after that update, so it wouldn't surprise me if it is something very small and stupid like you mentioned.
(Score: 2) by KritonK on Tuesday November 07 2017, @10:10AM
If I remember correctly, systemd was introduced in RHEL/CentOS 7, so your CentOS 5 server should still be running init.
BTW, if you have a policy of strictly enforcing the update process, you should update to a newer version of CentOS, so that you might have updates to apply. Version 5 has reached end-of-life, and there are no updates forthcoming.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @06:11PM
Funny thing about boilerplate in RC scripts.
Best one recalls, the BSDs move said boilerplate to its own file that is then loaded by the daemon specific scripts via the source command.