 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 1, value: US$2) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Manjaro issues upon first boot (by brad on 2024-05-27 00:53:52 GMT from United States)
I have noticed that the first boot after installing Manjaro presents problems similar to the problems that Jesse mentioned in his review.
I've been using Manjaro long enough now to find that whatever issues crop up after first boot are usually resolved without further intervention after a subsequent boot.
Of course, things like that just shouldn't happen, as Jesse has observed, but I like Manjaro enough to "overlook" this particular flaw, reboot, and continue to use it, because of its many good qualities (the one I like the best is the ease of installing "LTS" kernels in place of the "latest and greatest").
I'm also pleased with how well Wayland works with Plasma - I've been "testing" it for over a month, and have found no show-stoppers (full disclosure - I don't have an NVIDIA graphics card on my laptop).
2 • Init systems (by New User on 2024-05-27 01:18:17 GMT from Canada)
Thanks for that discussion on init systems. This was the clearest explanation I have ever come across. I use primarily Slackware (and derivatives), so familiar with Sysvy, and have had no problem editing it's scripts. Occassionally used Debian (before systemd came along) and found the script layout looked a bit "messier".
Thanks to your clear explanation, I understand why; and for the first time, have gained some insight into why systemd MIGHT be appreciated (by some). Personally, it still comes across as an abomination.
In last week's weekly edition, you'd asked about suggestions re coverage. Perhaps a step-by-step tutorial on taking a disto (say Debian and or Slackware), and replacing it's default init with OpenRC or rcunit.
Seem to recall coming across a distro that offers a choice of init (including OpenRC and runit) during install. Might have been MX? (Do recall that MX does at least offer a choice of whether you want to use systemd during install).
Much as I dislike systemd, have at least come across numerous tutorials on THAT one.
Part of the problem is sometimes, there is not enough information, and sometimes there is so much, it takes time to plow through it all; and just haven't got time anymore. So when you give your weekly answers to reader's questions, that one feature alone makes this site invaluable.
Sites like linuxquestions are great, but usually go there when looking for specific answers. Over HERE, we pick up new knowledge each week that we weren't expecting to find!
3 • Manjaro punching bag (by Rick on 2024-05-27 01:22:20 GMT from United States)
This review seems to be a clear case of punish Manjaro, which is number 5 on the distrowatch home page. What distro are you recommending? Can you join the Manjaro team to support the distro and make it "perfect"?
4 • slackware init (by john on 2024-05-27 02:00:13 GMT from Canada)
Yes, Slackware uses sysV, but what I did not see mentioned is all init scripts are in one specific Directory, /etc/rc.d
The sysv run level directories exist and are usually empty. But these will be examined if some package dumps something in one of those directories.
I actually like the Slackware method better than the BSDs, want or do not want a service, do a chmod(1) on the init script in "/etc/rc.d". Nice and simple :)
BSDs want you to edit /etc/rc.conf and systemd wants you to issue a 1 or maybe 2 commands (I forget).
Anyway very nice overview.
5 • Manjaro experience and troubleshooting (by Vinfall on 2024-05-27 02:06:19 GMT from Hong Kong)
The reason I prefer Manjaro over Arch/Artix is simple, it does not break after I blindly run "sudo pacman -Syu" (or in the Manjaro way, "pamac upgrade -a") upon initial setup. Of course I should read all the changes careful before bumping versions. But none of the other rolling releases (Void, Gentoo, openSUSE Tumbleweed or even Debian "unstable") I use have this problem, so I would blame Arch for this even if it's my fault.
Also, I happened to try Manjaro-sway last week and it just works like a charm, despite the fact that I was unable to run Calamares installer. Everything is well-suited, calcurse opens when you click on date, htop shows up if you click on system usage status bar... I'm still trying to set up a similar workbench in Void in favor of musl-libc.
Regarding the update issue, it *might* relate to a misconfigured file (I entercountered that on SwayWM, not Plasma, so YMMV). Manually removing /var/tmp/pamac/dbs/sync and create a directory of the same name solves the issue for me. Or maybe it's a keychain issue as always, at times I have to run "pacman-key --init" before using pacman.
6 • Manjaro Plasma - pamac authentication (by Roger Brown on 2024-05-27 03:19:53 GMT from Australia)
Issue is not evident in Manjaro Xfce 24.0-240513 running under VirtualBox but it was noted in a clean Manjaro Plasma 24.0-240513 installation also under VirtualBox.
In this case authentication failed on first attempt but then succeeded on retry (correct password used in both instances). Command line installation either using pacman or pamac was fine.
Hopefully the Manjaro devs will sort this out because otherwise this implementation of Plasma works very nicely.
7 • Pamac, review (by Mr. Moto on 2024-05-27 03:33:27 GMT from Philippines)
Had the same problem with Pamac authorization. It resolved for me with "sudo pacman -Syu" Did the update, restarted. No more problem. (Don't know why. I ain't no techie,)
8 • Undecided vote on Plasma 5 and 6 (by Bobbie Sellers on 2024-05-27 04:53:47 GMT from United States)
I use KDE's Plasma 5.27.11 and am very happy with it.
Using a Rolling Release I wait on the packager to compile the DE as with any other
part of PCLinuxOS 2027.05. I read with great interest every report on Plasma 6
and hope that it's arrival on my machines will not impede my rather slow
work flow. Sooner or later it will come to my Dell 7730 and my E7450.
bliss- Dell Precision 7730- PCLOS 2024.05- Linux 6.6.31-pclos1- KDE Plasma 5.27.11
9 • Arch and derivatives not for me (by Any on 2024-05-27 05:20:59 GMT from Spain)
I tried in the past to use Manjaro and then Artix as my daily driver but they were prone to mismatch KDE after one month of updates. So, no rolling release distribution for me. Finally I settled on Debian Stable. Still my preferred distro is Slackaware, but what keeps me on Debian is it is much easier finding and installing some programs. I got lazy :)
As of the poll - I haven't tried KDE6 yet.
Thank you for explaining the init systems in Linux.
10 • Manjaro 24 with KDE 6 (by Terry Parris on 2024-05-27 06:38:29 GMT from United States)
Jesse,
I recently downloaded and installed Manjaro 24 with KDE 6 (minimal image). I chose the minimal image as it allows me to do more custom selection of software to my taste. I'm happy to report that I had none of the issues you ran into with pamac graphical software center nor getting the "desktop cube" working. Though I too had to install qt6-quick3d package like you did. Using the "meta + C" works. My only complaint with the cube is not having the open windows float above the cube face like it did in KDE 5.
Though I've not had good luck trying to run the cube in PopOS (with installed extension) nor any other flavor of Gnome. Same applies with Linux Mint Cinnamon and it's cube extension. It's possible I did not look into getting this extension set up properly in either desktop.
As to your issues with desktop effects in virtualbox, most distributions (KDE Neon, EndeavourOS, and Manjaro etc. etc.) distinctly disable many desktop effects in virtualbox as well as KVM. I've verified this using both forms of virtualization. The jumping taskbar which you mentioned is also something that can take some getting use to. The plasma taskbar is actually a floating taskbar. When you maximize a window the taskbar will jump. This can be avoided completely by right clicking on the taskbar, select enter edit mode, then under Style sliding the slide bar to the right. That will disable the float taskbar and stop the jumping around.
As to the "full image" which you used to install Manjaro KDE 24 causing the pamac issues you stated, I'm not sure what caused that. I know you check the downloads via checksum. You might have to check back in a bit. It's possible they may have corrected the issues you ran into with that image file.
And for your knowledge, I installed Manjaro KDE 24 on a System 76 Pangolin 11 with 32 GB of RAM and 1 TB of SSD. The only extra work I had to do in order for Manjaro to work without issues on this laptop was to install the System 76 drivers via AUR and using pamac. Other than that, I'm happily running KDE 6 with only one bug which I've yet to report to KDE involving dual monitors.
11 • Plasma 5 vs 6 (by Chris on 2024-05-27 06:52:26 GMT from South Africa)
I am running Plasma 5 on Kubuntu 24.10 and very happy and often think about when the Plasma 6 testing will begin ;)
12 • Hon /e/ pot (by Mur(ky ar)ena on 2024-05-27 08:08:17 GMT from United Kingdom)
Why take a google system and ‘attempt’ to de-google it?
But it makes an excellent platform to target surveillance to those who seek to circumvent the dragnet.
Perhaps The best thing to do with a murena is burn it before using it.
13 • Manjaro (by tomas on 2024-05-27 08:43:25 GMT from Czechia)
I have two installations of Manjaro on my PCs.
After running an upgrade on the first one I have now the problem of authentication in Pamac.
It is rather a long time since then but still no solution.
On my other installation I have already 728 updates available but I will not go into that!
As a side-note I must say that some visitors here insist that the "ordinary" user must read every information before installing some software or update.
I strongly disagree with this opinion - if this is necessary, Linux will always stay behind the closed operating systems like Windows or MacOS (though Windows had also some downfalls).
14 • Manjaro (by Jürgen on 2024-05-27 10:35:20 GMT from Czechia)
Ever since using Manjaro for a few weeks (several years ago), and then suddenly getting a non-booting system (no error messages, nothing), I had to realise Arch and derivatives are what they say they are: useful toys for learning, but totally unreliable for any practical use. (There was no information on either the Arch or Manjaro pages about any update needing attention, the distro suddenly just wouldn't boot. There wasn't even a back-up older kernel, because it wasn't configured by default.) I know, I know: some people will tell how their Arch(-based) distro is running without errors for decades now (Yeah, for sure...), but that won't change the fact the a distro "deciding" not to boot (without any visible reasons) is unusable. It's almost "good" to see it doesn't work very well these days either.
15 • Init Systems (by Otis on 2024-05-27 11:21:11 GMT from United States)
Amazing explanation of the init systems! Thank you for that, Jesse.
I've been philosophically against systemD since I began reading about its implementation in the open source world several years ago. But to tell the truth I have never seen or detected any significant differences between init systems as I distro hopped over the years.
Perhaps I did see or feel a difference from one distro to the next, but did not know it may have been a nuance of systemD, SysV vs OpenRC etc.
Bottom line is Linux users settle into their respective distro(s) and maybe the init software is not noticed much.
16 • Manjaro (by Roger Brown on 2024-05-27 11:21:24 GMT from Australia)
@14 Your experience of Manjaro from several years ago is almost certainly irrelevant to this discussion as the maintainer arrangements have significantly changed for the better in recent years.
That said, Archlinux, and to a fair extent, Manjaro are designed for experienced users who know how to keep their installation up to date, to diagnose and correct problems, and to take precautions such as installing a back up kernel series (usually linux-lts).
For these users, and I am one such, Arch and its derivatives are indeed reliable.
17 • init modularity (by BluPhenix316 on 2024-05-27 11:46:50 GMT from United States)
You said you liked s6 because it is modular. You didn't mention in the description of systemd that, it too, is modular.
systemd does a lot of things but the last I checked it too was modular. You could just run with the init replacement systemd and not use all the other stuff you mentioned.
For example systemd-boot does exist but most distros I've used(and currently use) still use Grub2. They don't use systemd-boot.
18 • systemd (by Jesse on 2024-05-27 11:50:57 GMT from Canada)
@17: "You said you liked s6 because it is modular. You didn't mention in the description of systemd that, it too, is modular."
That's because systemd is not at all modular. Not even a little. You can't, for example, use runit for init and systemd for service management. You can't use just systemd-home, but not systemd-init. They are all tied together.
With the other systems, like s6 and OpenRC you can swap components from other stacks. You can run SysV init with OpenRC managing services, for example.
19 • init (by Jesse on 2024-05-27 11:57:27 GMT from Canada)
@2: "Seem to recall coming across a distro that offers a choice of init (including OpenRC and runit) during install. Might have been MX? (Do recall that MX does at least offer a choice of whether you want to use systemd during install)."
There are three possible times when a distribution can provide init choice: Downloading, Installing, and Booting. In other words, you can select an init system tied to an ISO, you could select which init to enable in the installer, or you can select your init software at boot time from the GRUB menu.
antiX, Devuan, and Artix all allow you to select your init software at download time (you pick the appropriate ISO).
As far as I know there are not any binary distributions where you pick your init software at install time. Though I believe both Gentoo and LFS allow the user to pick their init software during the build process.
MX Linux allows you to pick your init software (SysV or systemd) at boot time from the GRUB menu.
20 • runit (by R. Cain on 2024-05-27 12:10:09 GMT from United States)
Can 'runit' be installed on MX-Linux? For absolutely dead-certain?
21 • init aware (by crayolaeater on 2024-05-27 13:22:33 GMT from United States)
@15
"Bottom line is Linux users settle into their respective distro(s) and maybe the init software is not noticed much. "
I would think not noticing the init would be a good defining description of init working well.
Like you, I have really never had any real issue (at least not instgated by me) with any init. Cut my linux teeth on Slackware and SysV eons ago, and since have run distros with systemd and runit. On all, I just let init do it's business, and now I pretty much keep my fumbling fingers off them.
In the end, I remain partial to my first, SysV, yet stay intrigued with runit for it's being the most 'linux' to me - lean, simple, basically one job and do it well.
22 • init (by kc1di on 2024-05-27 13:49:14 GMT from United States)
Just want to thank Jesse for the nice write up on init. Easy to understand.
Thank you. I like many I suppose don't pay a lot of attention to Init system as long as the system boot. But like the Idea of runit.
23 • manjaro (by hmm on 2024-05-27 13:52:31 GMT from Moldova)
Jesse,
this article is unfair, cause it is from a distrohopper's point of view, who ocasionaly tries manjaro, but never used it for a period of time.
the problem with pamac on manjaro, is because manjaro is a rolling release, and pacman design limitations,
the solution is to do a 'pacman -Syuu', pacman will update its caches(or whatever), and then everything will work just fine (pacman, yay, pamac cli and pamac gui).
every user of manjaro knows that, also every user of arch who uses pacman on other arch based distros knows that too...
so thats why IMHO it is an unfair article.
p.s:
pamac has wonderful cli and integration with aur and both snap & flatpak)
for example `pamac install vlc` instead of `pacman -S vlc`
but some problems are from upstream, i hope they will be fixed some day...
24 • Manjaro (by Jesse on 2024-05-27 13:57:57 GMT from Canada)
@23: "this article is unfair, cause it is from a distrohopper's point of view, who ocasionaly tries manjaro, but never used it for a period of time."
Why would you think I haven't used Manjaro for any length of time? This is a false assumption.
"the problem with pamac on manjaro, is because manjaro is a rolling release, and pacman design limitations,
You probably mean "Pamac" rather than "pacman" here? As I mentioned in the review, pacman worked perfectly.
"the solution is to do a 'pacman -Syuu', pacman will update its caches(or whatever), and then everything will work just fine
I did that. It doesn't work. As I mentioned in the review, even after running the updates from pacman, Pamac still failed to function.
"every user of manjaro knows that, also every user of arch who uses pacman on other arch based distros knows that too..."
Yes, that is why it was the first thing I tried.
"so thats why IMHO it is an unfair article."
How is it unfair to point out something is broken? Also, how is it unfair of me to point out something is both broken and that your suggested fix doesn't work?
25 • manjaro (by hmm on 2024-05-27 14:02:03 GMT from Moldova)
also, maybe there is a bug in how installer configures users in manjaro
in the installer there is a checkbox to use same password for root as the password of the main user, maybe the GUI package updates didn't work in this edition because this option wasn't checked...
cause it is a rolling release, sometimes unfortunatelly such bugs happen, and fixed in next .iso build.
26 • init choice (by Jimmy T. Geek on 2024-05-27 14:18:56 GMT from United States)
I like having a boot choice for init and use MX.
Jellyfin seems to require SystemD. Most of the time I boot with SysV because I don't want SystemD to override my choices.
Years ago, before I had more Linux experience, Mint 13 and an update to systemd changed my DNS from local dnsmasq with two host files and upstream resolver using DNSCrypt to systemd-resolve and Google DNS. At the time, the documentation for stopping systemd-resolve did not work. My solution was to find a better distro.
I have tried Manjaro and liked it but not as well as MX because of init choice and because MX has great tools such as snapshot and Live USB maker.
27 • SysV (by Otis on 2024-05-27 15:17:02 GMT from United States)
@21 (crayola eater, lmao brings back grade school memories).. anyway, noticing for the first time a short while back that our venerable Jesse is the maintainer/dev(?) of SysV, I think we should seek out and deploy whatever distros have that particular init, just as a reward to him for his dedication and work in that and this site. We can provide a plethora of feedback right here. ;o)
Now, we also await a Jesse developed Linux Distro Extraordinaire, no fooling. That would be something indeed (if he's already done that, don't tell me; I feel dumb enough about all this as it is).
28 • init and distro (by Jesse on 2024-05-27 15:25:07 GMT from Canada)
@27: " anyway, noticing for the first time a short while back that our venerable Jesse is the maintainer/dev(?) of SysV, I think we should seek out and deploy whatever distros have that particular init, just as a reward to him for his dedication and work in that and this site."
This is a nice idea, thank you. But please, use what works for you. I use SysV init, I like it. But I don't claim that it is the best init software. I encourage everyone to use what best suits their needs.
"Now, we also await a Jesse developed Linux Distro Extraordinaire, no fooling."
I've never created my own distro from scratch. I have contributed to a handful, but I've always been more inclined to help someone else improve their vision of a distro/game/init/service than build my own. The only distribution I've had a big role in was Phat Linux, but that was ages ago.
29 • runit (by former on 2024-05-27 15:46:28 GMT from United States)
@20 Don't know about MX. I know antiX now also uses 'runit' (and of course sysvinit). antiX and MX devs are working together, so maybe MX can in the future go 'runit' way also?
30 • @ 23; @ 24 • Manjaro (by Jesse... (by R. Cain on 2024-05-27 15:48:35 GMT from United States)
Everyone here needs to read the following article.
Every *fan(boy/girl)* needs to read the following article.
Every thin-skinned individual who thinks that a negative review, or a negative comment about their all-time personal-favorite Linux distribution is a personal attack needs to read this ("all-time personal favorite" for today, anyway; most of these types are distro-hoppers--hobbyists only--who have no concept nor intention of sticking with one distro long enough to learn anything about it...but they WILL attack anyone who has the temerity to comment negatively on their "distro du jour").
"Reading Comprehension is a Big Problem in Open-Source"
Updated: February 24, 2016
https://www.dedoimedo.com/computers/linux-reading-comprehension.html
A few snippets from the article for your serious (one can only hope) consideration...
----------------------------------------------------------------
"Commenter: "Wow. Sad to think that the reviewer only needed to add Packman to "fix" most of the issues he faced." "
"Reviewer: "No. It is sad that whoever wrote this comment didn't bother reading the review and paying attention to my message. Adding Packman was probably the FIRST thing I did." "
"...and the focus switches from technical pain points, of which there are many...to personal traits of the reviewer and how he/she may be suited to using Linux."
"...It makes me wonder if these kind of people ever bother reading anything at all, or if they are firing semi-coherent responses just because a title of a post or something along those lines caught their attention. And rage..."
"...The fact people comment on things without reading. After all, all those words. So difficult..."
"...When people [ a REVIEWER ] complain about technology, they are not attacking you [dear READING-COMPREHENSION-DEPRIVED READER ]. They are attacking lousy products. They want shit done. As long as the commentary diverges into discussions about noobs, someone's ability to gstreamer their sister and such, Linux will NEVER rise mighty as a consumer product. If your first instinct is to discuss the reviewer, you should shift-delete your Internet. It's all about being able to receive constructive feedback. Once that happens, we might actually end up with some decent software..."
-------------------------------------------------------------
Warmest regards...
31 • init (by ric on 2024-05-27 16:55:57 GMT from United States)
@19: "As far as I know there are not any binary distributions where you pick your init software at install time. Though I believe both Gentoo and LFS allow the user to pick their init software during the build process."
PeppermintOS's latest offers a debian base (systemd) version or a devuan base (sysV) version at download time; and, either 64bit or 32bit.
If one chooses PeppermintOS devuan version, one has a choice of 3 inits during installation: sysV, runit, openRC.
32 • KDE 6 (by J on 2024-05-27 17:36:47 GMT from Panama)
I voted for "Like KDE 6 less than 5" simply because some of the applets I like and latte-dock were discontinued and are incompatible witrh KDE 6.
33 • Plasma 6? Better to wait. (by Alvaro on 2024-05-27 20:30:11 GMT from Italy)
I tried Plasma 6 on Fedora KDE spin and had annoying problems with the bottom bar. Better to wait for the project to mature.
34 • init diversity (by anticapitalista on 2024-05-27 21:06:21 GMT from Greece)
antiX has a supported alpha development release by a user that is called init-diversity.
It includes sysVinit, runit, s6 and s6-66 on the live booting iso.
User can choose which init to try when running 'live'.
If user installs to a hard drive, all 4 init systems are still available and can be booted into.
More information here:
https://antixlinux.com/unofficial-antix-23-init-divesity-spin/
35 • @16 Manjaro (by Jürgen on 2024-05-27 22:00:46 GMT from Czechia)
@16 I was expecting an Arch-/Manjaro-fanboi post, and you didn't disappoint. :) Let me disprove your faulty "arguments".
> Your experience of Manjaro from several years ago is almost certainly irrelevant to this discussion
No, it isn't. Fanbois praised the hell out of both of them and swore to their mother's life that both were rock solid, dependable OS's -- they kept saying that even then. They weren't and they clearly still aren't.
> Archlinux, and to a fair extent, Manjaro are designed for experienced users who know how to
As a reply to me, this an ad hominem (which invalidates it instantly), moreover it is factually wrong. (Why the hell do you assume things?) I am certified in Linux system administration, already have been when I tried Manjaro as a daily driver. And while I never had as much experience with Arch/Manjaro as with Debian et al., I practiced a lot with them, did the manual Arch installation several times, so thank you, I knew what I was doing. To top it off, I did everything by the book, as they suggested if for beginners. Yes, I had the lts kernel (it was either the default, or I switched to it; I definitely checked I had those). I had no backup kernel because at the time there was nothing about it in the "newb" docs. I always disable splash-screens and such, and enable kernel messages, because I like to see what's going on -- or not going on. Manjaro suddenly stopping to boot with absolutely no visible error and without absolutely any obvious reason is a typical Arch-family problem. (And there was nothing in either the Arch or Manjaro news to suggest something needed attention.) I kept my system up-to-date, I didn't even wait long with updates, I did them every day or two (mostly daily). (By the way, not-regular-enough updates being able to break the system is cold hard proof how unreliable it is. You can update a Debian-machine after it has been turned off for months, and it won't bat an eyelash. You can do major-version upgrades just like a simple update, the only extra is changing the codename in the repo source files, and that's it, upgrade, reboot, done. And some derivatives not being able to do this doesn't disprove the point.)
So, if you please, stop it with the assumptions (you got them wrong), stop it with the condescension, and stop it with the faulty arguments and denial. There is a reason you hardly (if ever) see Arch/Manjaro as a server. Red Hat (et al.), Debian (et al.), Ubuntu (et al.), Alpine, some other Linuxes and BSDs of course make great and reliable servers (thought it can be done wrong as well, of course), but Arch/Manjaro are nowhere near the ballpark. When they work, they work great -- then one day they decide they stop working, and then they don't work at all. That's not even desktop-stable, let alone server-stable.
36 • @28 - Jesse and Phat Linux (by Andy Prough on 2024-05-27 22:03:12 GMT from Switzerland)
@Jesse - >"The only distribution I've had a big role in was Phat Linux, but that was ages ago."
There's still a 2002 article on Linux.com by Jesse about bricking his Phat Linux installation by deleting his C library, and then figuring out how to get it all working again. Good times! Was it "Phat" as in the hiphop definition, or as in "Portable RedHat" or something Jesse? There was a "Pubuntu" a few years later which did a similar thing - allowed users to install a Portable Ubuntu on a file in a running Windows instance.
37 • Phat Linux (by Jesse on 2024-05-27 22:17:58 GMT from Canada)
@36: " Good times! Was it "Phat" as in the hiphop definition, or as in "Portable RedHat" or something Jesse?"
To be honest, I don't know where the name came from. That question never came up in my discussions with the project's creator. The Phat Linux distribution was based on Mandriva Linux though, not Red Hat, so probably not any variation of "Portable Hat".
Personally, I always thought the distribution's name (Phat) was an alternative spelling of "Fat" because Linus Torvalds said he wanted the Tux logo to look like this:
"You should be imagining a slightly overweight penguin, sitting down after having gorged itself, and having just burped. It's sitting there with a beatific smile -- the world is a good place to be when you have just eaten a few gallons of raw fish and you can feel another burp coming."
Maybe I'm wrong, but that was the way I always thought of the distribution's name - a nod to Torvalds and how he wanted Tux to look - fat/phat and happy.
38 • manjaro left me disappointed (by someMuppetOnTheInternet on 2024-05-27 22:55:21 GMT from Australia)
I used manjaro for a few months a few years ago, but it bricked itself (DE crashed, was unable to bring it up again) after a normal pamac update. It was a vanilla xfce installation, with nothing from the AUR. I replaced it with fedora. This, and some other tidbits I've picked up along the way have left me with the impression that manjaro sometimes doesn't quite live up to its aspiration of providing a stable/approachable version of arch. Jesse's weird password experience and a few comments from other folks here seem to gel with my impression. It's clearly got traction, and all distros have bugs and various other kinds of tradeoffs and shortcomings, but I moved on myself.
39 • init (by lincoln on 2024-05-27 23:08:30 GMT from Brazil)
Jesse, correct me if I'm wrong, but when you say sysvinit has around 3000 lines, are you referring only to the file init.c (https://github.com/slicer69/sysvinit/blob/main/src/init.c) (excluding dependencies)? If so, wouldn't it be more accurate to compare it to runit-init.c (76 lines) (https://github.com/void-linux/runit/blob/master/src/runit-init.c), which generates the runit-init.o executable (https://github.com/void-linux/runit/blob/master/src/Makefile), or at most adding the 346 lines of runit.c? Wouldn't all the other lines of runit be "helper programs and optional add-ons" or service manager implementation?
Another question, Jesse, what do you think of the design and implementation rules of Daniel J. Bernstein (creator of daemontools and inspiration for runit and s6) (https://cr.yp.to/qmail/guarantee.html) in relation to the Unix philosophy?
40 • @39 init (by picamanic on 2024-05-28 09:30:17 GMT from United Kingdom)
@39:lincoln. A more realistic comparison between the sizes of the sysvinit and runit init systems can be assessed from the respective source directories: sysvinit=11646, runit=6030 lines of C. From memory, the sysvinit scripts are the same again, whereas runit scripts are tiny. Most of the size for these init systems comes from the daemon/service management. Without that, basic "sinit" init is just 120 lines of C, and the same again scripts. More modern init systemd like "dinit" are a similar size. All these are small because they concentrate on just doing the things necessary to init Linux and basic daemons.
41 • @40: init [correction] (by picamanic on 2024-05-28 10:19:40 GMT from United Kingdom)
@40: 'modern init systemd like "dinit"', "systemd" is a typo, sorry.
42 • init (by dr.J on 2024-05-28 10:30:41 GMT from The Netherlands)
The legend is knitted and it is that systemd makes work so easy for developers. What should we users do? Fall to our knees in gratitude? I think it's a myth. The basic idea of systemd is similar to that of Microsoft or google: a few people out there create the perfect system (for their purposes of course) and then take care of it. And everyone is happy that they do the work for us.
What a load of crap.
runit or OpenRC show that at most a few scripts are needed to control the basic processes of a system. The many processes that systemd has now taken over, including timers for logrotate etc., the completely unnecessary replacement for cron etc. only show me that a new monster is being created here that no longer has anything to do with the basic idea of Linux/Unix/BSD.
43 • @40 init (by lincoln on 2024-05-28 12:42:53 GMT from Brazil)
@40:picamanic. Take into account that within these 6030 lines of runit, there are experiment files (trycpp.c, trydrent.c, tryflock.c, trymkffo.c, trypoll.c, tryreboot.c, trysgact.c, trysgprm.c, tryshsgr.c, trysocketlib.c, trysysel.c, tryulong64.c, tryuwtmp.c, tryuwtmpx.c, trywaitp.c).
And a partial reimplementation of stdlib.h, stdio.h, string.h, unistd.h, signal.h as can be observed in the files alloc.c, alloc_re.c, buffer.c, buffer_0.c, buffer_1.c, buffer_2.c, buffer_get.c, buffer_put.c, buffer_read.c, buffer_write.c, byte_chr.c, byte_copy.c, byte_cr.c, byte_diff.c, byte_rchr.c, env.c, error.c, fmt_ptime.c, fmt_uint.c, fmt_uint0.c, fmt_ulong.c, open_read.c, open_trunc.c, open_write.c, openreadclose.c, scan_ulong.c, seek.h, seek_set.c, sig_block.c, sig_catch.c, sig_pause.c, str_chr.c, str_diff.c, str_len.c, str_start.c, stralloc.h, stralloc_cat.c, stralloc_catb.c, stralloc_cats.c, stralloc_eady.c, stralloc_opyb.c, stralloc_opys.c, stralloc_pend.c, , strerr_die.c, strerr_sys.c, subgetopt.c, ... If necessary, the extra lines from the dinit event library (dasynq) need to be counted.
But the main point would be Daniel J. Bernstein's design and implementation rules in contrast to Unix philosophy. In your opinion, does the software not become smaller, faster, more reliable and secure because of them?
44 • init comparison (by Jesse on 2024-05-28 13:02:06 GMT from Canada)
@39: > "Jesse, correct me if I'm wrong, but when you say sysvinit has around 3000 lines, are you referring only to the file init.c"
Yes, you are correct. For context for folks reading the comments, this is what I wrote: "The runit software includes process monitoring, optional automatic service restarts, built-in support for running services in parallel, offers a logging service, and has a clean, filesystem-oriented approach to enabling services. All of this is accomplished with under 1,000 lines of C code. For comparison's sake; SysV init is about 3,100 lines of code. Once you factor in all of SysV's helper programs and optional add-ons the SysV suite is about 11,600 lines of C. systemd's suite is up to about 1,300,000 lines of C code."
So the direct 1:1 comparison for the whole suite is 1,000 of C for runit, 11,600 for SysV, and 1,300,000 for systemd.
> "Another question, Jesse, what do you think of the design and implementation rules of Daniel J. Bernstein (creator of daemontools and inspiration for runit and s6)"
I think Bernstein makes some good points, particularly about parsing and passing information between programs. Parsing is where things tend to get weird in terms of exceptions, unexpected input, and weird corner cases.
I am a big fan of Daniel's idea of reducing attack surface and minimal privileges.
The last point in the design guidelines though strikes me as not being practical. Daniel mentions a lot of the work on the example mailing service uses a custom library rather than a standard C library. This is probably not good universal advice for two reasons:
1. Custom libraries are not viewed/audited/used by many people so bugs are likely to be missed. Most developers will almost always be better off using dedicated libraries rather their own custom solutions as the former have been through trials by fire. We all make mistakes and those mistakes are more likely to be fixed in tools like musl c, glibc, OpenSSL, etc than in our one-off creations.
2. Writing everything from scratch, including the low-level libraries, will take a long, long time. It might improve security or simplify a design, but if the developer wants to ship their service or application in a reasonable timeline, then they will probably need to borrow some libraries for any non-trivia task.
45 • init comparison (by lincoln on 2024-05-28 13:44:40 GMT from Brazil)
@44: >Thank you very much for the answer Jesse, your work is formidable, with clear and objective ideas that are very well grounded and conveyed.
46 • init (by This-or-that on 2024-05-28 16:05:18 GMT from United States)
Thanks Jesse -- that was a nice piece of work that even I can understand. The only thing better would've been an example of how to start/stop/restart a service in each. Very much appreciated.
47 • init and reading comprehension (by Stasek on 2024-05-28 17:53:13 GMT from Czechia)
Thanks for the "reading comprehension" article, it is quite on point. It is funny you should link it now: this week's DW (and commenters) mentions init systems, and I also looked at a few MX Linux user reviews here this week. The common point? One reviewer complained about having to try to make MX work with systemd for compatibility with some software; and they weren't the first such user. Apparently they didn't read the most basic FAQ or description about MX linux; had they done that, they would know it ships with SysV init *änd* systemd, and booting it with systemd is as simple as choosing the right GRUB menu entry. What I'm about to say may contradict the "reading comprehension " article, but I stand by it: if someone knows about init systems and they know they need a particular one for whatever reason, they have no excuse not to realise it is already installed for them and ready to boot. Some users are indeed not knowledgeable (or rather: attentive) enough for the use of some distributions.
48 • SysV init (by beardless coder on 2024-05-29 00:53:52 GMT from New Zealand)
Thank you Jesse for an enlightening writeup on the init systems. It seems to have become a very political arena, mainly due to systemd increasing the exposure of a system as it tries to be one tool to rule them all. For most folks, you start a system, and work. Init, what?
SysV init has a special memory for me as it was the "new" thing when I was moving into smaller Unix systems in the 1990s. The whining voices back then were that SysV wanted a slightly different folder structure than previous releases... the one you see in still today in most Linux distros. People it seems complain about change, for any reason.
49 • Bug fixed in next ISO! (by Gary W on 2024-05-30 08:29:56 GMT from Australia)
@25 "fixed in next .iso build."
So you have to reinstall your rolling-release distro from a fresh ISO, to deal with an egregious bug? Sounds like a case for installing debian-stable, or one of its flash derivatives like MX.
50 • @20 runit and MX (by Hoos on 2024-05-30 13:55:24 GMT from Singapore)
"Can 'runit' be installed on MX-Linux? For absolutely dead-certain? ..."
I'm not sure how perfectly their systems run, but a search of MX forum would indicate that a few members have managed it.
I am guessing that since it's not default, you will need to be able to sort out any issues on your own.
Slight tangent - MX has a basic graphical service manager that works with systemd and sysV. There was a forum member using runit on MX asking if runit management might be added to the tool. The MX developer replied that while he was not interested in doing this, he would be happy to consider pull requests.
https://forum.mxlinux.org/viewtopic.php?p=755620#p755620
@Jesse, thank you for the init comparison article. It helps me understand things better.
Number of Comments: 50
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • Issue 1120 (2025-05-05): CachyOS 250330, what it means when a distro breaks, Kali updates repository key, Trinity receives an update, UBports tests directory encryption, Gentoo faces losing key infrastructure |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
KolibriOS
KolibriOS is a tiny open-source operating system with a monolithic preemptive kernel and video drivers for 32-bit x86 architecture computers. KolibriOS is a fork of MenuetOS, written entirely in FASM (assembly language). However, C, C++, Free Pascal, Forth, among other high-level languages and compilers, can also be used in application development. KolibriOS features a rich set of applications that include a word processor, image viewer, graphical editor, web browser, and over 30 games.
Status: Active
|
| Tips, Tricks, Q&As | | Tips and tricks: Finding the right words, sorting filesystem snapshots, truncating audio files |
| Tips and tricks: Compressing memory with zRAM |
| Myths and misunderstandings: Wayland, Xorg and Mir |
| Questions and answers: Finding a secure distribution |
| Tips and tricks: Using GRUB with XFS |
| Questions and answers: Improving performance with custom-compiled source packages |
| Questions and answers: Linking an ISO file to a specific user |
| Questions and answers: Benefits to building your own kernel |
| Tips and tricks: Basename, for loop, dirname, aliases, bash history, xsel clipboard |
| Tips and tricks: Creating bootable USB drives with UNetbootin |
| More Tips & Tricks and Questions & Answers |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
