You are quite correct, but making life hard when uou can just click and they are grouped by type very easy. Unless you are on another system and have to link to that repository first as a socrce.
1 Like
Just my two cents⌠Iâve heard from several professionals that think systemd is great. It allows concurrency in starting your computer for faster start-up. On the other side of the argument, for people who want more control over their system, itâs often not what they want. Itâs not easy to build from source and itâs being required by more and more packages. Linux users tout their freedom of choice to use whatever window manager, desktop environment, file manager, etc. they like.
However, with systemd being installed on so many Linux systems and with it being so invasive and used by or replacing so many packages, itâs not easy to replace with other options. Some Linux users feel it restricts their freedom of choice. They donât like how it does not conform with the âdo one thing wellâ philosophy since it tries to do much more than one thing. Not everyone needs the same type of init system. It may be a benefit to some but it may be a negative for others.
As to flatpaks, theyâre one solution to the difficulty developers have of sharing their applications across so many Linux systems. Many developers have avoided Linux distributions or only support one or a few large distributions because itâs so hard to build software with all the differences in libraries and versions on each distribution.
This is one area where Windows shines. Software built for a modern Windows distribution works on just about any modern Windows distribution as long as itâs compatible with the processor. With all the differences in Linux distributions, this just doesnât work for Linux.
Some developers have been trying for years to find a way to distribute their software without having to distribute an entire operating system with their software just to get it to work.
The LSB was supposed to allow for more interoperability of programs. It really isnât that helpful. Some developers try to find and build their programs with the oldest copies of libraries they can with the assumption that libraries may not be backward compatible but for the most part, they should be forward compatible.
This isnât necessarily the case. Many developers use techniques like flatpak or Docker or similar solutions where they pretty much distribute every library they need along with their programs. Itâs not that efficient and not something every developer is going to want to do just to distribute a program. Bedrock Linux and some minimalist/efficiency enthusiasts recommend using static compiling.
You donât need to redistribute all the libraries. The application has everything it needs to run and wonât accidentally load the wrong library or try to load an incompatible one. One drawback is that the statically linked library code wonât update automatically when you update the library thatâs part of your distribution.
That can make your system more vulnerable to security issues. Another major problem with this solution is that glibc is simply not designed to be linked statically. One would need to use another C library such as musl. Some developers including some of the glibc developers are very much against using static linking over dynamic linking in general.
There are pros and cons to both options. Iâve been looking into the issue of trying to distribute applications for several years now and reading about the various solutions that have been tried. At this point, Iâm leaning more toward the static library solution.
It doesnât require that you distribute practically an entire operating system of libraries including a C library just to get one program to work. The lack of consistency of libraries and versions can be touted as a benefit in Linux but it can also be a drawback since many professional developers donât want to take the time to specifically develop for each distribution of Linux.
Then again, many die-hard Linux enthusiasts donât seem to care since a lot of the programs they develop are closed source. Maybe if there was as much consistency in libraries and versions as their seems to be in the push to use systemd on most major Linux distributions, there wouldnât be as much of a problem distributing programs for Linux.
3 Likes
That is also available in some of the newer alternstive init systems⌠notably dinit and S6. Runit also allows parallel startup but its management of dependencies is not as clever as in S6 or dinit.
That is something users tend to forget.
I am a fan of static binaries⌠I think they perform as well as more complicated solutions.
One program that I use that comes as a static binary (keenwrite) works in every distro except Void. I cant see how a static binary can fail to execute in one distro, when it works elsewhere? That seems to say static binaries may not be the perfect way for developers to share applications.
It is more than that. It is a really good summary of the issues.
Thank you.
2 Likes
Thanks for your detailed reply in relation to my question.
One of the biggest practical flaws I think systemd has is that it doesnât allow people to learn; itâs a black box which does everything for you. ALL other init systems are one, maybe two, tiny binaries and the rest is glued together by scripts doing the magic. This is how any UNIX-like OS should function.
Now, Iâm only a desktop user these days. It shouldnât matter much to me, right? Wrong! I once tried having my Google Drive available on login. I needed to download a systemd unit file and stuff it somewhere in my home directory. Of course figuring out what this script actually does is quite the effort in and of itself.
The other init systems are way more user friendly (this comes from an ex-Void and -Gentoo user). I found how Void (runit) dealt with stuff really elegant and simple. Two lines (per init script) to get a service up on boot is the norm. Elegant and simple. Meanwhile, with systemd you get a lot of boilerplate to simply launch a service.
No, systemd is not the way forward, itâs a gigantic leap backwards. What are the systemd devs trying to do? Outperform Microsoft in regards to complicated?
1 Like
For me and 99 % of users thats ideal, I know there is an engine in my car and it takes diesel but apart from topping up the wash bottle I dont need to know more, just pay tge bills when they come.
1 Like
I agree other init systems can handle concurrency. However, when I speak to systemd fans/advocates, they seem to think systemd handles concurrency better than many of the other options out there. The people Iâve heard from tend to be working with Linux for businesses and may not want to fine tune start up of applications the same as a Linux hobbyist or enthusiast.
I am surprised that keenwrite works everywhere except Void. Can you use objdump, nm or a similar tool to see what libraries it may be linking to? Maybe itâs still using a few dynamic libraries or expecting the glibc library to be accessible instead of musl? Usually the only thing that would be an issue is if the CPU and/or bit size is different.
2 Likes
I bet that is it. Try it in Alpine and see if you have the same issue.
1 Like
I think they get that attitude from comparing systemd with sysvinit which it replaced.
The newer init systems, especially S6 with the 66 service manager, are just as sophisticated as systemd. They can group services into bundles and enable and disable bundles dynamically, as well as autostarting them.
I think startup time is unimportant, but all the newer init systems handle dependencies automatically and parallelize accordingly⌠It is only sysvinit that is serial.
I think the best init system for home users is dinit where available, or OpenRC otherwise. For business, I do not know enough to say ⌠if they want simple I would say the same ( dinit or OpenRC), but if they want sophisticated it would have to be systemd or S6 with 66.
I need to take a closer look. ldd does not work on static binaries. Maybe strace or your nm. My Void is glibc, not musl.
Update: I looked closer. It works in Void if I do not specify a filename. That is more a keenwrite issue, I think. My mistake, sorry.
4 Likes
Solitaire is also aisleriot sudo apt install aisleriot
Frank in County Wicklow - Ireland
3 Likes
Iâm curious why you went with glibc over musl. One of the pros of using Void Linux is that it supports use of musl. I personally like a lot of the design choices the developers made when they coded musl. There may be some compatibility issues for building some programs with musl but theyâve done a great job not just following the POSIX standards but making it as ABI compatible as they could too.
3 Likes
About 5 years ago I had 2 Void installs⌠one with glibc, one with musl. I never noticed any difference⌠Most of the serious computing I do is R, and it will compile with either.
So I discarded one of the Voids⌠took the conservative choice and stayed with glibc.
Now, I have seen more about musl, and I have looked at Chimera which has LLVM and musl, and I feel I probably made the wrong decision⌠so one day I might reinstall Void/musl. Artix uses musl too. I like Artix.
I have heard/read that systemd will not compile with musl. That is unlikely to bother me, but it may explain why many popular distros do not use musl.
4 Likes
This is because musl sticks 100% to the standard, while glibc adds all kinds of things.
2 Likes
Was just reading the comments on the closed issue at Github for systemd marked as Improve libc portability #10130. The musl developers got into a discussion with some of the systemd developers. Didnât sound like a cooperative discussion either. Iâm personally biased toward the musl developers. They put a lot of thought into their design.
They have specific reasons for what they will or will not add to musl. Plus, they do an impressive job with efficiency. Not sure, why one of the systemd developers assumed no one uses the POSIX standards. Several developers do.
Looks like some groups have tried to patch systemd to work with musl but thereâs probably not going to be any official upstream patches. I do think non systemd solutions might appeal more to people who work with musl though, so maybe this will help encourage more developers to help out with creating and maintaining efficient and useful alternatives.
3 Likes
For me it is the other way round. Musl is an option because I am non-systemd.
It will be interesting to see which way BSD goes.
3 Likes