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.
(1)
(1)
Hacking's just another word for nothing left to kludge.
(Score: 2) by Whoever on Monday November 06 2017, @02:10AM (2 children)
Gentoo/MATE.
It has udev, not eudev, but no systemd.
(Score: 2) by Magic Oddball on Monday November 06 2017, @11:50AM (1 child)
PCLinuxOS/Trinity Desktop Environment — similarly, has udev without systemd.
(I'd be alternating between MATE and TDE, but losing the ability to customize window colors beyond the GTK themes was a deal-breaker.)
(Score: 0) by Anonymous Coward on Monday November 06 2017, @01:26PM
Ah yes, TDE. The continuation of Qt3 and KDE3. Been meaning to install that since forever...
(Score: 4, Interesting) by cubancigar11 on Monday November 06 2017, @08:51AM (2 children)
Can someone explain this for noob like me who has been using devuan (jessie)? A cursory reading through top google search results didn't help.
(Score: 4, Informative) by KritonK on Monday November 06 2017, @04:16PM (1 child)
Antix's emphasis is on being a distribution that is as light as possible, so that it can run well on old hardware. I may not have liked it, but that thing felt very snappy!
Being Debian-based, Devuan might also require a CPU that supports the PAE instruction set, which may be a problem for older 32-bit processors; AntiX does not have such a requirement. My laptop is a borderline case, with an atom processor that supports the PAE instruction set, but does not report that it does so. My brief dalliance with Lubuntu required booting with a "forcepae" kernel option, which allowed the PAE kernel to boot, but may have been the cause of the instabilities that I observed.
(Score: 3, Informative) by cubancigar11 on Tuesday November 07 2017, @07:26AM
Thanks. That helps. From the summary it seems antiX major selling point is lack of systemd :o
(Score: 3, Interesting) by KritonK on Monday November 06 2017, @08:53AM (4 children)
Having read so much about antiX, I tried the previous version on an old laptop, whose time had come to say goodbye to XP. I found the stable version way too ancient. (You were running XP, I can hear you say. That was ancient too. May be, but I was running recent versions of the applications in which I was interested, which antiX did not.)
I then tried the unstable version of antiX. The first surprise was that, when I told the installer to install that, it didn't; it installed the stable version, with tweaked repositories. I then had to update the system, which reinstalled just about every single package, one at a time, a process that took forever on such a slow machine. The second surprise was that I couldn't install one of the applications, in which I was interested, because some QT5 packages were being "held", whatever that means in apt-speak, so out the window antiX went.
I briefly tried Lubuntu, but found it way too unstable: booting and shutting down successfully was a gamble, so I ended up using the LXDE version of Fedora. It may run systemd, but at least it is stable and, despite my machine having only 512M of memory, which is half the amount recommended by Fedora, it runs fine. If Fedora stops supporting 32 bit machines in the next release, I'll probably switch to Void Linux [voidlinux.eu], which I've tried in a VM and have found it to be light, fast, up to date (it's a rolling release), runs the applications in which I am interested and, as a bonus, is systemd-free, using runit [smarden.org] as its init system.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @10:21AM (1 child)
Which has the same problem. Certain packages have *HARD* requirements on systemd now. Notable among those is QT5, GNOME/GTK, and KDE related packages.
Many of these will fail on any debian derivative because they don't have build flags/testing for the non-systemd configurations of those packages or the resulting downstream dependency changes that result.
(Score: 2) by KritonK on Monday November 06 2017, @04:06PM
If you are referring to AntiX, it is not related to Devuan. It's being on its 17th release, while Devuan is on its first, should be a clue.
If you are referring to Void, it's also older than and not related to Devuan. Void may not have drawn as much publicity as Devuan, but it seems to be in a more advanced state than Devuan, as everything works on it except gnome, which I would consider a feature. Even KDE is supposed to work, according to their web site.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @12:21PM (1 child)
I try to get about ten years of use out of each desktop or laptop I buy. I think that's a reasonable value for the purchase price. Trying to continue on with something with 512 MB of RAM seems like too much. I know that's unimaginable personal computing power by 1997 standards, but that was 20 years ago.
I haven't had any problems with systemd and use it at home and at work. That said, I had an outstanding experience with Void Linux when I used that and had no problems with runit either. So if you go that route, best of luck to you (no sarcasm intended). Competition and choice in the free software world is one of the things that makes it awesome, so even if I never leave systemd again I'm glad alternatives and their supporters exist.
(Score: 2) by KritonK on Monday November 06 2017, @03:55PM
For a laptop that was destined for recycling, it does what I want it to do (play music and non-HD media) admirably, even if it is 15 (not 20 yet) years old. I'm not spending any money on it for upgrades, which would be a waste, but replacing it with a new computer (or, more likely, a media player or TV box), while this one does the job, would also be a waste.
(Score: 0, Interesting) by Anonymous Coward on Monday November 06 2017, @11:45AM (1 child)
Obvious political grenade aside, what is the draw to holding up victims as objects of veneration, rather than mere memorials? Why are victims made out to be akin to heros? Do those doing such want people to be victimized? Is being a victim somehow a good thing now? What's the sense in promoting victimhood as a moral good in contrast to survivors or achievers?
(Score: 0, Offtopic) by realDonaldTrump on Monday November 06 2017, @12:17PM
She knew what she was signing up for. She's not a hero. She's a hero because she got killed. I like heroes who don't get killed. In Charlottesville there were heroes on many sides. And hatred, bigotry and violence on many sides. On many sides.
(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.
(Score: 0) by Anonymous Coward on Monday November 06 2017, @07:58PM
i'm fine with archlinux and systemd for now but i'm glad projects like this. if nothing else they provide a home and support for projects like Eudev so if tshtf with systemd these projects might still be healthy. just because they're after you doesn't mean you're not paranoid! :)
(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!
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @06:23AM (1 child)
Is this some militantly CLI-only distro?
/s
(Score: 2) by KritonK on Tuesday November 07 2017, @10:30AM
Nope. Various lightweight desktops are supported. The "anti" in "antiX" probably stands for "anticapitalista", the distribution's developer.