SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
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.
Fraud is the homage that force pays to reason.
-- Charles Curtis, "A Commonplace Book"
(Score: 2) by darkfeline on Tuesday November 07 2017, @05:13AM
The more I use systemd, the more I like it.
With systemd, all logs go into one place. All logs are automatically timestamped, and it is not possible for logs from multiple sources to intermingle, or for one process to pretend to log as another process. As long as the logs exist, I know that they have not been tampered with, since journald logs use forward secure sealing. This includes non-malicious tampering, like poorly written services that overwrite their log files. These logs also include output from containers, and services running inside those containers. Furthermore, it is trivial to run a regular service inside a container thanks to systemd's awesome container support. Things that some ill-informed Soylentils criticize, like systemd resolved (har har, why does systemd ship its own dns resolver), are directly tied to this level of container support.
This also includes logs for services tied to timers (replacing cron) and filesystem changes (easy inotify support). cron "logs" (emailed output) are shamefully bad; I have happily replaced all of my cron jobs with systemd timers. systemd provides easy logging, both of output and job run status. I can see when a job will run next, when it ran last, and its history of successes and failures. cron can't do that. Failed timer services show up the same way as failed normal services, making it easy to see when something is wrong, unlike with cron where a job can go bad for months until someone notices because the backups are missing. systemd can also intelligently batch timer jobs to account for system load and CPU wakeup when idle. Again, cron can't do that. The inotify integration is also great. I no longer have to engineer a monstrosity to make sure inotify watches are properly established and that they get re-established if they get lost. I set up a systemd path unit, and systemd will make sure the inotify watch stays in place. These also get logged, like everything else, in a uniform way.
I don't have to do the old pgrep and kill dance like with rc or sysvinit because systemd cgroup support guarantees that when a service is stopped, it is stopped. cgroup support also provides simple to configure service resource limits and namespacing.
rc and sysvinit fundamentally cannot cope with modern system management requirements, as they are not event driven like systemd. A simple synchronous startup might work on a traditional server, but they definitely don't work on laptops, which can have devices plugged and unplugged, and the network connect and disconnect at any time. systemd's event driven service management can handle that, rc and sysvinit cannot. Even for servers, unless you're running a traditional system, rc and sysvinit are no longer enough. Network resources can become available or unavailable, and containers are provisioned and shut down all the time to scale flexibly. The methodical and naive service management of rc and sysvinit cannot cope.
That's just a few things I have thought of at the moment. I will try to post more things that are great about systemd in the future, since SN is pretty much a giant anti-systemd echo chamber, for all you hypocrites say echo chambers are bad. Don't worry, I've got karma to burn.
Join the SDF Public Access UNIX System today!