Antix is to Debian what Obarun is to Arch, and Devuan is to debian what Artix is to arch. Such projects/distributions seem to be very promising in concept and execution. Equally promising, if not more, is Void, Sabotage, and Kiss linux taking an independent path. Unfortunately we can not cover the progress of too many distros and at times we may have to drop a few from the list and concentrate on the few we believe there is future and hope. We have dropped Devuan over a year ago due to serious doubts with the project’s management, its credibility. and now we have decided Artix has to go too. Continue reading →
Linux 6.2-rc2 kernel is out as the last commit in kernel.org at the start of the 2023 year. RUST is here, the initial code-base is included in the kernel. At least Arch seems to be disabling it for now, at the beta level at least, we shall see.
Rust is not just a language, as people commonly think, it is much more. It is a building environment, system, and a mode change of the philosophy of building packages from source. Rust incorporates its own git system in pulling code in from 2nd and 3rd parties. So if you have never gotten into the real FOSS practice of auditing code before you build, try and audit this stuff. If building in C you thought was a practice similar to building sand castles, by comparison, this is like building sand castles with quick-sand ON QUICK SAND.
Welcome antiX and Noir linux to the strict list, with edition 22 antiX is fully functional and lighter than ever without a trace of elogind!
This means this list has grown more than it has shrunk, over the past 2+ years it has been dynamically published.
Edited: December 26th 2022 (replacing older strict list)
This list is going to be short and there may be a sublist of distros with a medium strict standard. We shall explain what the object is, below the short list (which we hope the community will assist in making longer as we have not been able to currently review the work of every distro and fork).
2022 list of “healthy” hardcore distros in alphabetical order
antiX —> antixlinux.com debian fork without systemd/elogind nearly as famous and popular as Debian itself now
A vivid discussion has broken out between members of the community, whether q66 considers her/himself one or not is not our prerogative to define, or exclude anyone, about the hardcore stance against FOSS pests such as systemd, elogind, dbus, udev, etc. So since the topic of discussion is very specific it would have been best if a topic addressed the specific issue, which is irrelevant to whether Chimera Linux belongs on a strict list of distributions without systemd or not. The criteria about that list are very clear. The criteria for the “gray” list are not very clear, but nobody really cares about this sloppy list of gray categorized distros, such as void, artix, and devuan. Continue reading →
obarun stands for OpenboxRunit … but has been the home for arch based s6 implementation with tools (currently 66) to make s6 less hostile to MOST users of linux. Runit only lasted a few weeks before s6 was implemented and runit dumped. Currently featuring a graphic installer of base, openbox, jwm, xfce4, and plasma desktops and a setup of s6/66 to get you going.
joborun stands for JwmOpenBoxObarunRunit, so it is everything Obarun can be, plus runit that can coexist and alternatively boot instead of s6/66, but also replaces most core Arch pkgs with ones built in vaccuum of systemd/logind/udevd. Currently not including an installer, or an iso image, but an old fashioned tarball of the base and instructions on how to make it a bootable system within minutes. Joborun is basically a source based distro, although it provides 2 tarballs, base system, and builder system, and binary repositories of all packages it provides source for. You always need a binary system to build your binaries, joborun just makes the process easier and quicker, without frustrating fails. Continue reading →
We are currently reviewing the distros on the strict list, verifying they are still actively being developed, whether they still meet our strict criteria and anything that has changed since they were first admitted to the list.
If you search reddit for r/linux and systemd you will find many more threads in the “removed” section than on the visible part. Come to think about it, if one crossposted the removed threads into a new board called r/linux-removed it may become a much more interesting board for discussion than the temple of doom, r/linux.
But the above is one of those rare occasions where systemd is in the title of a thread in r/linux and was not removed. Why? Basically because anyone wishing to voice some form of criticism over the “holly cow” of industrial/corporate/state-security-agencies linux, gets the ax permanently and can not speak. But how can they discuss the holly cow as deranged worshipers between themselves?
The thread/article and discussion is probably more interesting from a psychoanalytic perspective (psychological/psychiatric interest) than a systemd administration perspective.
Do you need pkexec and polkit on a WM? NO! CVE-2021-4034
Not unless you want some automated menu and icons to click on and use various user/root rights to execute a gui! Otherwise you are “safe“.
Don’t think because RH is reporting this the only affected parties are RHEL users, anyone who uses their systemd elogind and polkit derivatives are equally affected.
But gksu/gksudo was insecure and had to be erased from nearly every distro that is an IBM “client”.
More and more complexity is expected to avoid this. Sudo gparted from a terminal would have been fine, but if you want to click on a gparted icon in a menu or filemanager as a user and have it execute as root, this is how much complication is added. A logind -aemon negotiates with a polkit, through one of the layers of dbus, whether to allow you to execute something or not. Mind sizzling …… enterprise security in your “DESKTOP“.
First we should explain the reason for the title, then we should explain why has this become a trendy catchy titling of pseudo-media, what is pseudo-media, who they serve, and how can there be real linux development without this consuming black hole?
How were desktop environments conceived and developed, and why were they developed? Many technical reasons:
1 as hardware became quickly more able to display more complex graphics than the old text terminals, it became possible to display graphical images that weren’t drawn by grouping alphanumeric symbols together in lines, then digital drawings (CAD), then low resolution photographs that kept climbing in higher and higher levels, then video and high-fidelity audio. Continue reading →
Except for a few distros that assist their users to build everything they install from source (kiss and forks, LFS and forks, gentoo and forks, crux, exherbo, T2-sde, etc), most linux-distributions, offer binaries to be installed, usually backed up by the source code (script) building the package from either their own source code, or what we call upstream (other FOSS sources). How do you know though, that what the source repository shows and what the binary package contains is the same? One way is to build it with the same recipe (packaging source script) and compare the sums. Very few people do this and in very rare and controlled environments is the product the same, meaning checksums are identical (Arch is reporting 15-20% failure to reproduce their own packages). So what most distros do is they sign their packages and by having their public signature key, you know what they built is what you got. But are you sure they built it right, or did they take adequate measures to make sure what they pulled from upstream to build the package is what the author really published? How can you check?
This article is written on a reverse logic, starting from end and attempting to go towards the beginning, although we are not very clear on where to begin 😉
In the end of the article there is the reference article and direct quote of the error and why it is produced. To sum it up, logind within systemd produces an error for a user process attempt to start an X session process through an ipv6 connection. Although our allergic reaction to the fact the author on this article speaks in general about linux and displays a systemd related error, we will bypass this detail for the content’s importance.
error: Failed to allocate internet-domain X11 display socket
Now why does X get compiled with its own networking abilities? Because “some people” like to get X access to the machine remotely. A problematic reason on its own, but we are not here to solve all of the world’s problems. It is systemd complaining because sshd is not working right, it prevents a remote ipv6 connection, but logind is there to make sure that a proper connection is made when it should. Many other pieces of software have their own parts of ipv6 networking functionalities and abilities. Hmmm,…… !!! Scratch …scratch … why should they? Should they not?
WHOSE PROBLEM IS IPV6 MEANT TO SOLVE?
Yours, mine, … my ISP’s, …..? It has taken nearly 2.5 decades (since 1998) to transition from ipv4 to ipv6. Continue reading →
Hypothetically speaking, let us take Arch, and rebuild nearly all of it, without systemd. What does this mean?
On any particular core, extra, community package, the minimal environment needed to build a package, incorporates systemd and its libs. It is part of Arch base. So systemd is present even when it is not required. Some packages from source incorporate utilities based on systemd/libs and will utilize those in their package when present. Sometimes it is evident, sometimes not so obvious. So the hypothetical task is to build everything (except systemd and parts themselves) in a systemd-free environment. See when errors arise due to the lack of it, disable systemd/logind utilities where we can, and see what arch would be like without systemd.
Apart from the object to build arch minimal base without systemd and its libraries, the idea or question that came to mind was whether you can build all your packages from the Arch recipes. Since Artix now is autonomous and relies on its own software base, not Arch, the same question applies, and I suppose the same applies to Manjaro. Most of the core pkgbuilds in Artix are just copies of Arch. Systemd may not be there but many of its libraries or pieces are still there. But let’s say you just want to build Arch, authentic and 100% true arch.