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.
Everything you know is wrong!
(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.