Slashdot Mirror
Systemd-Free Artix Linux OS is Looking For Packagers (artixlinux.org)
MrBrklyn (Slashdot reader #4,775) writes: Artix Linux, the young systemd free OS based on arch, is reaching a critical point in it's development and calling for new packagers.
Here's more from the ongoing thread on the project's forum: You don't have to be an expert in the occult arts for that; an elementary grasp of Linux in general and how PKGBUILD works should be enough for basic contributions. Help and training will be provided, free of charge!
Here's more from the ongoing thread on the project's forum: You don't have to be an expert in the occult arts for that; an elementary grasp of Linux in general and how PKGBUILD works should be enough for basic contributions. Help and training will be provided, free of charge!
Most likely it will be the usual, RTFM!
Void Linux's package system is similar enough to Arch's, and Void isn't using systemd and you can choose either glibc or musl based installs. I think I'd rather throw my weight behind Void than try to fork Arch.
That's a weird way to say "There aren't really that many developers or other technically skilled users who don't want systemd."
I don't know what it replaced, what it unified, what it extended, and what it does. I'd be curious to learn
Some drink at the fountain of knowledge. Others just gargle.
It replaces SysV init.
Basically, SysV init meant there was a lot of duplicated code involved in starting system services, as every service had to write its own SysV init script, and didn't provide a dependency mechanism (this service requires this other service be running first) so that most distros ended up hacking on a solution to provide that. (Basic example is "web server requires network running before it can start.")
systemd solves those problems and then introduces a whole host of brand new problems. Whether or not you want to deal with the brand new problems systemd adds defines whether or not it's "better" than SysV init. It does legitimately solve some issues, but it also makes the boot sequence unpredictable and way more complicated, along with other issues there's no good reason for it to have, like logs that aren't human-readable and moving random system functions into init for no good reason.
Or, in short:
Good idea: replacing SysV init
Bad idea: replacing SysV init with systemd
Anyone who is skilled, and looks at systemd, will lose his hair very quickly, at the insane "framework" shit, that only the worsr "enterprisey consultant" of the iHipster generation could come up with.
No, the traditional systems aren't great.
But suggesting systemd instead, is like suggesting somebody should try ass rape by a horse because she thinks nipple pinching hurts a bit.
How about *a sane new system*??
Neither the old clunker, NOR systemd cancer!
Go home Lennart, the adults are talking.
I want to know which logfile editor to use to read the journal.d or /etc/logs. Vim or Emacs?
Thanks
http://saveie6.com/
I don't agree that replacing sysIV init is a good idea. All the arguments for that boil down to "not invented here".
Why is it that so many tech people cannot let things that work well the fuck alone?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Around 2014, with the switch to Systemd, Debian started to decline in popularity. This was followed by the equally stunning change in Ubuntu to the same init system. By 2018, it was apparent that both distributions were headed to the scrap heap of history as they had lost nearly 80% of their user base in the 3 intervening years.
Oh, wait, that didn't actually happen? Debian/Ubuntu still has the same userbase in the Linux Desktop and Server markets it had before the Systemd change?
I guess the markets have spoken, and the predictions of doomsday were nothing more than the echo chamber effect of a very small and very vocal minority of people who do not appear to represent either Linux users or Linux developers as a whole. That is the only explanation that fits the facts.
I wish I had a good sig, but all the good ones are copyrighted
This issue is only for Luddites who are stuck in the past. Once systemd achieves its ultimate goal of moving every available service and user application into a single executable, distros aren't even going to need "packages" anymore.
SysVInit worked fine for me, and no it doesn't boot slower. See what systemD does if you've got stuff waiting for network and for whatever reason there's no network or it's flakey. No warning at all - just no boot, or eventually a boot with no warning. .share way.
Why do I have to learn it's log and status tools after already having had to learn the other way of just using a text editor and knowing some filenames? I have other stuff to learn.
How helpful.
See what systemd does about share mounting in fstab or even the
Why guess when you can know? Measure!
I don't agree that replacing sysIV init is a good idea. All the arguments for that boil down to "not invented here".
Why is it that so many tech people cannot let things that work well the fuck alone?
+1 Wish I had mod points for that. It seems like so many people think mature software is bad or something. Sure, Sys-init/Upstart/whatever had its issues at times (and usually in very small ways), but there were solutions to those warts; it's just that no one really put all the parts together, or so it seems to me.
I've had Systemd fail me in mysterious ways where the system refused to come up (1 I never figured out and solved by backing Systemd out), but I've never had Sys-init/Upstart/whatever fail to boot far enough I couldn't do something with it (and it fails me even in tiny ways so infrequently it's been years since that happened).
To me as a *user*, Systemd feels like a solution in search of a problem. I know the distro/package maintainers like it because it creates less work for them, but I think this is a case where the distro/package maintainers have forgotten at least 1 of their goals: to make it easier on the user.
One example:
systemd keeps services (including user login sessions, which it treats the same way) as a group of processes, which the previous systems did not. When I stopped a service under SysV init, it would terminate the "main" process, but if that process had started children, they might not receive that signal. Thus, SysV init might leave some resources used, and attempting to start the service later might fail. systemd can reliably terminate a service and all its descendant processes.
Furthermore, systemd can report the status of all of those processes in its "status" command, which SysV did not.
systemctl can capture all of the output to stdout and stderr and collect those in logs that can be associated specifically with the service they came from, which SysV did not do. Troubleshooting services in SysV was sometimes more difficult because errors *were* printed by the service, but they were lost.
systemd has so many advantages that when I try to describe one advantage, I describe three.
The original purpose of systemd was to replace System V init.
They did replace System V init, in a very non-Unix-like way, with a monolithic blob full of binary interfaces, Windows-style.
They then continued to merge in more and more stuff, like a friggin DNS server. Had they stopped before replacing Network Manager with yet another integrated blob, systemd would just be a poorly thought out init system which is the opposite of the UNIX way of doing things. Since they didn't stop, but rather continue to merge more and more unrelated stuff, it's a real problem.
I had systemd run maybe for a combined 10h so far, in a number of new installations. Nothing but problems. Even the one where I originally thought I could leave it in (Orange Pi zero), it caused serious problems and ripping it just out for sysIV init was far easier than to track down and solve its obscure issues.
It is like Windows: Unless you do exactly what the "developers" ("cretins" would be a more appropriate term...) expect, it falls flat on its face and it is maximally unhelpful when you try to find out what is wrong. That is not anything I will tolerate in a Linux installation.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
+1 Wish I had mod points for that.
Thanks!
It seems like so many people think mature software is bad or something.
It does indeed. Must be some deranged idea about "old"="bad".
To me as a *user*, Systemd feels like a solution in search of a problem. I know the distro/package maintainers like it because it creates less work for them, but I think this is a case where the distro/package maintainers have forgotten at least 1 of their goals: to make it easier on the user.
This often happens when the original creators move out and the 2nd rated people take over: They think they can do better than the original creators and usually they mess it up because they completely overlook fundamental things like this. "Linux is about freedom" very much means it lets you tinker with it and all things that can reasonably be made relatively easy to change, are. sysIV init has that. The systemD people do not even seem to be aware of the idea.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Okay, great for ditching systemd but why did we need yet another packaging system? Was something wrong with dpkg or rpm? Maybe you wouldn't need so many packagers if you could leverage the scripts already written for rpm and deb derived systems?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I can't read on the comments any longer accept in chrome. I thought it might be noscript, evidently there is something more fundamentally wrong. I only see about 3 comments, and nothing else is coming down. It is now unusable,
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
NetBSD's pkgsrc collection has been designed to be portable. I believe it's already been ported to Slackware, and Solaris and other OSes.
The tools exist to just import it into this new Linux flavor.
Or if you're just trying to escape systemD madness, just use NetBSD. Or one of the other freenix choices that already has a package system built for it.
>>It replaces SysV init.
No - it replaced all the core OS functionality. If it just replaced SysV there would have been some grumbling, but not all the outright hostility.
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
systemd keeps services (including user login sessions, which it treats the same way) as a group of processes, which the previous systems did not. When I stopped a service under SysV init, it would terminate the "main" process, but if that process had started children, they might not receive that signal. Thus, SysV init might leave some resources used, and attempting to start the service later might fail. systemd can reliably terminate a service and all its descendant processes.>>
Systemd did not invent that, and it doesn't do it very well. Cascade affects like that usually screw users, like when you're database is turned off by a failed webserver, and then your LDAP, which also might depend on the database service doesn't work and you can't then log in.
Regardless, this kind of dependency was not invented by systemd, and is capable of being done by a variety of system, no of which also take over logins, counsels, and journals.
My favorite of course, is logind, which is totally broken in systemd.
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
I'd volunteer to maintain the SystemD package and help them move to the future. >>
My future is watching my grandchildren play in the sand in the beach and continuing research on computational applications to biological and genetic problem....mostly using C++ and R.
It is not chasing Pottering garbage down a rabbit hole and wondering why X won't start up after 40 years of stability because systemd broke it.
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
like when you're database is turned off by a failed webserver
I'm not talking about dependencies, I'm talking about process groups. Your database is almost certainly not started by your web server, or by the web server service. It's not part of the same process group.
I'm starting to get the impression that you don't understand how these things work.
> like logs that aren't human-readable
I don't have a problem with journalctl and binary logs since they're more efficient and easier to filter by unit. My problem is when you have log messages that don't make it to the journal. That makes it much hard to troubleshoot problems.
What Linux needs is a good App Store. >
Shirly you Gest
http://www.mrbrklyn.com/amsterdam.html http://www.brooklyn-living.com
All the arguments for that boil down to "not invented here".
So you are very clearly ignorant of the arguments then. Especially since many of the systemd replacements which by your assertion were NIH were actually replaced by something else NIH.
Why is it that so many tech people cannot let things that work well the fuck alone?
When you show us something that works well we will. But I understand why you are unable to comprehend this question given your total ignorance of why sysvinit was replaced (not just by systemd but by various attempts by various projects over the years).
gweihir: Claims to be a scientist, but turns out to be just a knight who saaaaaays NIH!
SysVInit worked fine for me, and no it doesn't boot slower.
Lets leave aside that this wasn't the reason for getting rid of it, but given your assertion that it doesn't boot slower is actually easily proven false in any benchmark and even when you conceptually think about the approach of sysvinit vs all the other systems that attempted to replace it, why did you decide to post this? Why make the opening sentence of your argument not only irrelevant but something very easily proven false? Anyway lets look at the rest:
See what systemD does if you've got stuff waiting for network and for whatever reason there's no network or it's flakey. No warning at all - just no boot, or eventually a boot with no warning.
"Dear user: I'm still working on this problem" I guess you prefer a completely dumb senseless warning compared to waiting for the boot order to complete? Or maybe you prefer the sysvinit approach where half the services end up in a failed or various other states.
See what systemd does about share mounting in fstab or even the .share way.
The perfectly sane thing. Boot to emergency console when a core system partition failed to mount. Worried about something non-core or network related? Why would you automount it through fstab rather than listing a mount requirement in the systemd unit file?
Why do I have to learn it's log and status tools after already having had to learn the other way of just using a text editor and knowing some filenames? I have other stuff to learn.
Well if learning a single command is hard for you ... you don't. You can simply install syslog and go back to the way you were doing it years ago. The only downside is that you actually get more information in syslog now since it will show logs from before syslogd actually starts. Did I say downside? I meant upside. Do you know how to use apt to install a syslog daemon or do you want that spoon fed to you too?
I had systemd run maybe for a combined 10h so far
Wow we have an expert here!
Nothing but problems.
Given your inability to get it working vs the literally countless cases where it works just fine as a scientists and an engineer I am beginning to see a common trend in all your systemd installations.
It is like Windows: Unless you do exactly what the "developers" ("cretins" would be a more appropriate term...) expect
Funny most people don't have problems with Windows either. I was about to say maybe this Linux thing is too complicated for you, but really maybe you should stop using computers altogether.
It seems like so many people think mature software is bad or something.
No one thinks that. People who don't see problems and are affected by solutions will often refuse to understand the problems experienced in the first place.
Sure, Sys-init/Upstart/whatever had its issues at times (and usually in very small ways), but there were solutions to those warts
The solution was bolting together a frankenstein's monster of a mess that didn't solve the underlying issue. You wouldn't be talking about the benefit of bandaids and patchwork while shitting on Windows, so why do you think it's a good idea on a piece of linux software? Biased?
it's just that no one really put all the parts together
People have put these parts together in the past and they have broken in some horrible ways. Fundamentally shoehorning a modern event based requirement into the linear mishmash of scripts that is sysvinit didn't work. (not didn't work well, just flat out didn't solve the problems).
I've had Systemd fail me in mysterious ways where the system refused to come up
Yes that happened a lot in the early days of people setting up systems by treating systemd as something that executes a mishmash of scripts rather than actually using the features it has to solve a problem, distribution packagers have long since gotten past this. If your system is failing to boot then it's a good time to bust out the manual and find out what you've done wrong.
but I've never had Sys-init/Upstart/whatever fail to boot far enough I couldn't do something with it
Define something, if your kernel is up, systemd will at the very least get you to a console. Are you expecting a fully functional system after a failed boot?
To me as a *user*, Systemd feels like a solution in search of a problem.
A user of what? Users come in various flavours. A user of a server that boots up and then hums away in a corner for the next year would come to that conclusion. A user of a laptop who's system is in a completely broken state due sleeping and waking on different networks on the other hand will likely have a different conclusion. If you want a list of problems with sysvinit go to the debian mailing list. They were discussed in great detail along with why systemd was chosen.
forgotten at least 1 of their goals: to make it easier on the user
Funny, I find it much easier to work with systemd than I ever did with long list of initscript, symbolic links, PID files, and the inevitable orphaned processes.
"I had systemd run maybe for a combined 10h so far, in a number of new installations. Nothing but problems. " ROFL, bad workman blames his tools - there are plenty out there who have working systems.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
ROFLMAO - it you are going to troll, find something that is vaguely true
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
.
Work on the problem BEFORE you release something that'll be shoved down my throat and break things, please. Arrogant much?
.
Why should I have to write different error detection and fallback code every release of this crap?
.
No, it doesn't boot the console for me when a share (for example a NAS) didn't come up in time. It just hangs for quite some time, then fails (which is all it can do). If it did go to console it'd be kind of a mess for a physically hard to get to headless box (say a raspberry pi in the fusion lab).
.
Learning a single command? I count at least systemctl, journalctl, a few new directory layouts for service spec files, the formats of those which vary between some daemons and some mounts and it seems, on and on. As for a single command, I'd bet you can't even quote what all the options to rsync do...or know every file spec you'd put into it to backup a config without just doing every file on the box and failing because of the odd special file. Give me a break, single command.
.
Hint - I've been programming longer than IC's and most modern languages have existed- from the metal on up, including realtime embedded opsys when necessary as they didn't exist yet. These are the complaints of a newbie who only knows one system or language.
Why guess when you can know? Measure!
systemd keeps services (including user login sessions, which it treats the same way) as a group of processes, which the previous systems did not.
pgroups are manipulated with simple commands, and this could have been done in the init script includes. This does not justify systemd.
systemctl can capture all of the output to stdout and stderr and collect those in logs that can be associated specifically with the service they came from, which SysV did not do.
What? Who told you that? Of course you can do that with sysvinit. You do it in the init scripts.
systemd has so many advantages that when I try to describe one advantage, I describe three.
Get back to us when you come up with something you can't do in an init script.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I agree with you that far too little effort has been extended in pushing systemd concepts as standards outside Linux, and the scope has been distressingly ambitious.
Still, systemd is a great improvement over the respawn behavior of inittab, allowing me to drop root privilege, set environment variables, chroot(), all combined with restart supervision. Yes, there are likely many other programs that do this, but respawn is SysV's job, and it should be more flexible. As it stands, when I have to do this, I write a bunch of shims either with shell scripts or custom C, and I've had do it on a wide variety of legacy operating systems.
The inetd.conf also benefits from most of these new features, although I uncovered a bug with socket activation and chroot() that I was able to work around that has since been fixed.
Improvements to respawn and inetd are the killer features for me, and give me things that simply cannot be done with standard tools on other POSIX-focused operating systems.
SysV init should be extended to cover these uses, and I would feel more nostalgic for it were new versions to emerge.
I suspect that the developers were out of their depth. Probably not formally trained.
Same here. Or they failed to learn anything from their formal training. They are clearly inexperienced and have no business working on such a critical component. Now, I would not mind if systemd had remained their obscure hobbyist project. I do mind that the most efficient way to deal with their crap is to rip it out and that I have to do that on basically any new Linux installation I make.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Nice. And empty, probably much like your head. Makes it easy to just discount anything you say as less than worthless.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Oh, I am using good tools. And I do insist on good tools. After some evaluation I just found that systemd was not a good tool from available evidence. Not that this was any surprise, that it is pretty bad was clear from a purely theoretical appreciation.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Funny how so many people run into things in actual reality that according to you are "not true". You are just a liar.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well, one of the problems with init scripts is that they weren't consistent, so while it's possible to capture all output to the logs using "2>&1 | logger", I never actually saw an init script do that.
So, a) common init scripts didn't do what you're saying they "could", and b) even if some of them did, it wasn't something you could rely on as a standard. Logging output is standard under systemd.
The same applies to process groups. Under bash, you could probably "(set -m; exec $daemon) & echo $! > /var/run/pids/$service" or something, but have you ever seen that? Not to mention that you still wouldn't make use of cgroups, and your login processes wouldn't be grouping user sessions.
Now that systemd needs to be complete is a good init system.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Funny. My empty head can use systemd without problems. Maybe it's just too complicated for you :-P
Could you describe some of the problems you've run into? I've been steadily migrating all our many dozens of VMs to Centos 7 and I can't say that I've run into one single problem that was caused by systemd.
I've had far more problems getting sssd working right than I have systemd.
> Not that I particularly care about the Unix way, but it is arguably more "philosophically" correct
I suppose the UNIX way works really well for some things and the Windows way works well for some things.
The UNIX way scales very nicely from IOT to supercomputers h all, or almost all, supercomputers use Linux or another *nix. Most corporate desktops use Windows. So it seems they each have a niche or two.
The thing is, if you want to do things the Windows way, to have a 2GB or 4GB piece of software that has a thousand different functions, there is an operating system designed for people who like the Windows way. That OS is called Windows. Microsoft makes plenty of applications, such as MS Office, that have hundreds or thousands of different functions buried three levels deep in menus and two levels of dialog boxes. That's how Windows programmers and users like things to be done.
On UNIX, we have wc, which is separate from sort, from grep, from cat, from cut. If you want to count how many entries have the word "Slashdot" in them, on Unix you pipe grep (search) into wc (count). One program searches, a different program counts. That's the UNIX way. We don't build a separate program for "count how many URLs are from Slashdot", we combine the two small existing tools with a pipe.
If you want a system where you have to download a "count how many of the URLs are from Slashdot" program, you want Windows. That's not how *nix works.
Not that I particularly care about the Unix way, but it is arguably more "philosophically" correct
The UNIX way scales very nicely from IOT to supercomputers h all, or almost all, supercomputers use Linux or another *nix.
That is a very nice illustration of the Unix Way being arguably more correct. Thank you. :)
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
That's certainly an example of how it's more flexible.
On the other hand, menus allow an inexperienced user to keep exploring until they find what they're looking for (assuming the function exists). Combining small programs means you kinda have to learn what the building-blocks are and figure out how to combine them.
One big app with all the functions built into menus is probably the right choice for the UI of an ATM. To withdraw money you'd rather have a wizard than type commands. That works well when there are a limited number of options (withdrawal, deposit, check balance) and the user uses it infrequently. On the other hand, on a system you use all day, every day, it's worthwhile learning some commands and how to combine them to do whatever you want.
Spot-checked a CentOS 6 system, and here's what I found:
No services appear to log stdout and stderr to logger. Anything output is printed on the console. If you're not physically at the console, that output is lost.
The "daemon" function does call cgexec if it is installed, but cgexec is not installed by default.
Numerous services don't use the "daemon" function, including mysqld, postfix, and sshd.
So, as I said: systemd does things *by default* that the older init system didn't. Not couldn't. It's possible to do some of those things, but making a large collection of shell scripts consistent is hard, and keeping them consistent over time is harder.