 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$1012) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Void (by nanome on 2020-02-24 00:38:19 GMT from United Kingdom)
I have used Void Linux for many years. The sound issue is one I cannot crack, but am mostly pleased to not be interupted by noisy web sites [I run MX if i want to listen to music or podcasts]. I did not answer the opinion poll as I consider all of the features listed to be important.
To shutdown Void, logout from the desktop and move the mouse pointer to the bottom-right corner of the lxdm screen: Quit appears. Clicking on the Quit button shows Reboot or Shutdown as options. I know, not very friendly for first time users.
2 • GalliumOS (by greenpossum on 2020-02-24 01:38:03 GMT from Australia)
Not so long ago I had some fun trying out GalliumOS with a ChromeBox I picked out of e-waste. I logged the saga here: https://hackaday.io/project/169535-restoring-an-asus-chromebox-cn60
It worked fine, but eventually I pivoted to openSUSE, a mainstream Linux distro, because it supported the network interface out of the flash key, whereas I would have to get an extra driver for GalliumOS. To be fair this was because in GalliumOS the network interface driver was a DKMS module.
3 • Void (by name_is_mandatory on 2020-02-24 02:25:22 GMT from United States)
I ran it for a while, nice fast Linux. I also hope runit gets more adopted. Maybe by MX one day?!?
It is not for beginners, though. Since I'm relative beginner in Linux world, it was too much for me. Because of small dev team, not that many software is available. No problem, if you can package it on your own. I can't.
When I at some point ran into problem I couldn't fix, I moved on. But problem was this users lack of knowledge, not Void's. Void gets 10 from me. Hope they do well in the future.
4 • Artix Linux - The Runit Version (by David on 2020-02-24 03:24:09 GMT from United States)
I'm currently testing the Runit version of the Arch-based distro Artix Linux on my bare metal demo box.
It is pretty slick so far, except for a boot sequence issue that causes it to hang on start-up occasionally, which I think it may be related to the brevity of the HDD initialization time frame. I'm tinkering with a couple of BIOS settings in my effort to isolate & fix the problem on my PC. It may also be related to the fact that I dumped the initially installed Cinnamon DE, and replaced it with XFCE4. The solutions offered in the Artix Wiki are inconclusive, so my testing will continue.
The distro also offers OpenRC and S6 versions, but I prefer Runit because of the bloat-busting minimal number of lines of code required for it, vs. Systemd or the somewhat archaic OpenRC.
You'll find it at #84 on the DW/HPD ranking list - https://artixlinux.org/
JMHO
5 • Void (by Wellenjäger on 2020-02-24 03:34:56 GMT from Russia)
I use Void on my home PC for three months on a daily basis.
The LXQt edition (with glibc libraries) has no issues with sound, reboot or PolicyKit. Absolutely no complaints.
Void has become my favourite OS.
6 • Void (by Yuma Joe on 2020-02-24 03:35:53 GMT from United States)
The musl library is not the one that is most commonly used. That may cause some of your problems. Quote "There is no default graphical package manager for Void." This is a big deal to me. Also using the cfdisk partition manager instead of the more modern gparted can cause problems for new users. The last time I tested it I had sound, don't have a clue there. Wish them best of luck!
7 • Void Linux (by Saleem Khan Marwat on 2020-02-24 03:53:38 GMT from Pakistan)
Installed Void through chroot from my Arch Linux last night with Plasma, and it was like a breeze setting up system . Runit is very simple . As someone mentioned in comments about Artix with runit , will test install it from chroot as well. Runit is just very simple to manage.
8 • void (by pin on 2020-02-24 06:32:21 GMT from Sweden)
I've been using Void on top of musl-libC for 4 years without a break. Running AwesomeWM, booting in UEFI mode and have sound.
I don't have pulseaudio, just alsa. You should enable the alsa service, unlike systemd, runit does not enable services by default, THANKS FOR THAT!
Your issue with shutdown/reboot is also a service enabling away. But, this I don't care about, running on a window manager instead of a DE, I've just created a menu entry that executes 'sudo poweroff' or 'sudo reboot' without password by tweaking the sudoers file to allow this.
As for the poll, all the options are a reason to use Void.
9 • @4 - Artix (by Andy Prough on 2020-02-24 07:13:43 GMT from United States)
I am also a convert to Artix. It's unreal how well it runs and how much software is available. I thought Debian was the king of software, but Artix with the Arch and AUR repositories is in an entirely different league.
You said openRC is more archaic than run it, but I see that the openRC project began in 2007 whereas the runit project began 3 years earlier in 2004. Did you mean archaic in terms of age, or more in terms of structure or function? I'm trying the different versions. S6 seemed a bit unstable, but openRC seems to be the primary init system for Artix with the best stability and support. Let me know your thoughts if you have time.
I've also seen the occasional boot hang up. I figured the system may simply be too fast for bios on a regular basis. Boot times are typically in the range of 5 seconds on Artix with my had which is kind of crazy.
10 • Artix Boot & Re-Boot Hanging Issue (by David on 2020-02-24 08:02:25 GMT from United States)
@9
These are the BIOS settings that I'm testing to possibly resolve the boot/re-boot hanging issue in Artix Linux /Runit - YMMV, in accordance with your CPU/BIOS/motherboard generation.
(1) After entering Set-up, scroll over to Devices, and down to Hard Disk Pre-Delay, hit Enter. You can set the number of seconds for your drive initialization, which may not be given sufficient time by default after the Artix install. I have mine set at 6 seconds presently, but experiment with this setting.
(2) Experiment with Boot Priority in the Start settings, either UEFI or Legacy.
(3) Experiment with Quick Boot, either Enabled or Disabled.
My test box is a Lenovo /Intel i3-530 most of the time, though I'm testing on an i5-4590 as well. Their BIOS set-ups are different, and AMD CPU's are a completely different snarling, hairy beast that sends me screaming into the night.
My understanding of OpenRC is that it is a management layer that sits on top of, and integrates with Sysvinit, which is an "ancestor" init sytem with no process supervision. The OpenRC framework introduces additional complexity as it fills the system management gaps in the outdated Sysvinit functionality.
Runit was built from the ground up to simplify the init function with as few lines of code as are needed.
I read somewhere that SystemD represents One Million+ lines of code, in comparison to about 1,600 lines of code for Runit. Please, anyone, feel free to correct me if I'm wrong on any of these points. I'm still near the bottom of the Linux learning curve .
JMHO
11 • Installing from the web (by SuperOscar on 2020-02-24 09:49:56 GMT from Finland)
From the Manjaro news: “In a future version we will enable also installation from web.” Well isn’t that nice. After all these years advocating the Linux model of a centralized repository instead of scouring-and-installing trash from the world wide web, we are now getting back to square one!
12 • void (by blargle on 2020-02-24 10:40:32 GMT from United States)
imagine reinventing several wheels just because it's popular to dislike systemd
13 • @12 (by pin on 2020-02-24 11:05:06 GMT from Sweden)
It ain't all about systemd and BTW is was systemd that reinvented the wheel, not the otherway.
UNIX doesn't need systemd.
14 • VOID (by m3city on 2020-02-24 11:12:37 GMT from Poland)
I have considered checking this distro. It says "Void is a general purpose operating system" on its homepage. But when I read that screenshot key is assigned, but it does not work, and there is a link for email app, but it's not even installed.... that is laughable.
15 • Manjaro (by m3city on 2020-02-24 11:17:20 GMT from Poland)
@11
It's not exactly the case (I guess web app store would be still pointing to sources lists, like ppa). BUT it was kind of funny to read about Gobolinux few days ago here on DW, which basicly turns clutter of linux system layout to MS Windows like structure <-- clean, readable, easy to access and modify.
16 • @12 Void (by Hoos on 2020-02-24 11:17:32 GMT from Singapore)
What wheels have been reinvented by Void? Have you actually tried Void?
I quite like it even though it's not for newcomers and requires some manual setup of services.
Surprisingly for a rolling distro, you can go literally months on end without updating, yet still carry out your next update quickly and trouble-free.
I installed an older iso image that came with cinnamon desktop, which was about 6-7 months out of date, and then proceeded to upgrade it. No issues despite the huge amount of updates. It's still ticking away nicely a few years later.
So once it's set up, it's quite easy to maintain.
17 • @10 OpenRC (by dxrobertson on 2020-02-24 11:23:08 GMT from United States)
"My understanding of OpenRC is that it is a management layer that sits on top of, and integrates with Sysvinit, which is an "ancestor" init sytem with no process supervision. The OpenRC framework introduces additional complexity as it fills the system management gaps in the outdated Sysvinit functionality."
It depends on the implementation. That is true in Debian/Devuan OpendRC; OpenRC has been modified for LSB support. It doesnt use openrc-init, uses initab, and uses sysvinit scripts.
Not so in Artix OpenRC. Its a full OpenRC implementation; uses openrc-init and OpenRC init scripts in /etc/init.d.
18 • @6: GUI frontend for Void package installation (by Uncle Slacky on 2020-02-24 12:26:51 GMT from United States)
Void does have octoxbps available in its repos - it's like octopkg for BSD: https://github.com/void-linux/void-packages/tree/master/srcpkgs/octoxbps
19 • Void - package search, octoxbps (by Hoos on 2020-02-24 12:52:31 GMT from Singapore)
Void also has a useful web page where you can make package searches, even if you don't use a graphical frontend like octoxbps:
https://voidlinux.org/packages/
For run of the mill usage, I don't really find it lacking in packages.
20 • Void is the Best (by mcg on 2020-02-24 13:52:23 GMT from Finland)
Void Linux is all Linux user needs who knows what he wants and doing. One can find it difficult then use a distro which is windows like or study Linux and then come back to Void. Reviewer has forgotten to mention that Void Linux uses LibreSSL instead of OpenSSL. Long live Void! Thank you yo developers! Have a nice day!
21 • Poll options (by Friar Tux on 2020-02-24 13:58:24 GMT from Canada)
I picked the last one - "None of the above." as it doesn't really matter to me so long as the OS works flawlessly. That's about the only "preference" I have. I hate post-install fiddling to get an OS working. I hate having to "maintain" an OS to keep it working. That's why I prefer a general purpose OS with a good development team behind it (I use Linux Mint/Cinnamon). While Void, and similar projects are great, some of us just want to get our stuff done with as little fuss as possible. Note to systemd haters: seems to me that systemd is working great on a lot of OS's, more so than the other init systems. All the systemd-run OS's I've run seemed to do just fine. And, since I value experience more than opinion I'll stick with what I find works best.
22 • @10--There's only one VERY LARGE problem with *systemd* (by R. Cain on 2020-02-24 14:05:20 GMT from United States)
@ 10 --
According to "*The Register*" on 6 January, '20, SYSTEMD consisted of a paltry 1.3 MILLION LINES of code. And that was over longer than one month ago. It's probably up to 1.4 million lines, by now.
https://www.theregister.co.uk/2020/01/06/linux_2020_kernel_systemd_code/
...and the question still gets asked, "Why don't you like 'systemd'?
Let me count the 1.3 (10⁶) ways...
23 • Artix Linux & OpenRC (by David on 2020-02-24 16:22:43 GMT from United States)
@17
Thanks for the enlightened clarification about the Artix OpenRC implementation. I'm going to download the ISO and install it on my demo PC this week-end. The Runit boot/re-boot hanging issue persists for me, despite all my BIOS setting-tweaking efforts. That stability conundrum makes me nervous about deploying Artix as my daily production driver, so I'll be testing the OpenRC version soon.
I keep hoping that the next relevant package or kernel update will solve the boot hang dilemma, but it hasn't happened yet.
@22
Here's an interesting link as well - "6 Best Linux init systems as of 2020" - https://www.slant.co/topics/4663/~linux-init-systems
Reading through the Pro's and Con's of SystemD taught me that SystemD "phones home " to Google DNS servers by default, which may or may not be of concern to any given user.
As much as I love pure, plain vanilla Arch, if I can ditch the insidious & expanding bloat of SystemD, I'll be working to make it so. I don't hate SystemD, but its system encroachment is a source of concern for a KISS advocate such as myself.
JMHO
24 • Void Linux (by Voiduser on 2020-02-24 16:42:46 GMT from United States)
Void doesn't use systemD because systemD is incompatible with musl libc. One of the goals of the project is to support glibc and musl libc on multiple architectures, so an init system that can build/link against musl had to be selected. A lot of anti-systemD people flock to Void because of runit - not realizing that Void was originally an early adopter of systemD.
Regardless, one key thing to keep in mind with Void is that package dependencies are kept to a minimum. This is to avoid the trap that Ubuntu, Arch and others fall into with an innocuous package dragging in dozens and dozens of soft dependencies. If you want a screen-shot tool for XFCE - install one.
25 • Artix + Runit hanging (by nanome on 2020-02-24 18:00:28 GMT from United Kingdom)
@10: I couldn't boot the Artix/Runit lxde ISO on my spare machine, but I will try to help with the [re]boot issue. First, the runit init scripts on Void are totally different from the G. Pape originals [smarden.org/runit], and so the Artix scripts probably are different again. However, the sh-scripts are in /etc/runit/{1,2,3}, so you might be able to work out where it is hanging provided you can get the init output to the terminal [try ctrl-alt-1?]. The Atrix forum appears lively, so you should ask a question there. There must be a way to boot Artix in terminal mode [or to install it without graphs. Beyond that, Arch linux was always a dead end for me..
26 • Void (by Cynic on 2020-02-24 18:31:45 GMT from Ghana)
I used void a few months..
Wasn't bad but ended up going back to Slackware after an update broke some software.. found out there was no way to "downgrade" to the last (stable) package. That is an issue in my mind.. updates may not be "forced" but once they're installed, that's it.
I'm also not sure how "general purpose" a system can be when having all the sound issues mentioned.
The community was also unwavering in their support of Voids lack of "package downgrades", almost to the point of being rude when calling it out as an issue. To me that indicates a serious lack of vision and flexibility. I doubt "server" would also fit under their definition of "general purpose".. as breaking it would not be easily undone die to its design.
27 • Void+Sound (by nanome on 2020-02-24 19:51:59 GMT from United Kingdom)
@26: I would briefly say that sound just started working on my Void machine! Nothing that I did, although I recently brought the XBPS packages up to date. I just have to press the "Sound Off" button to avoid hearing voices.
28 • Void (by Roger on 2020-02-24 20:06:32 GMT from Belgium)
The reason I like Linux is the stability it has, a thing that is severely lacking at windows 10.
No drastic changes, evolution and not messing around like MS is doing.
My choice is Debian based OS, Linux Mint Mate my main one and keeping an eye on Ubuntu Mate and other Debian based ones.
For that reason I will not in the near future test Void, just follow the news and maybe one day.
29 • Artix & Openrc, etc (by Martin on 2020-02-24 21:17:00 GMT from United Kingdom)
@10 Thanks for those tips, I will be saving your post as I have experienced difficulty booting occasionally with Artix -Openrc.
@23 Thanks for the link on init systems, it confirms my fear that Systemd is unnecessarily heavy on resources, which I strive to avoid. I can thoroughly recommend Artix btw, great distro and helpful community.
30 • LOC is a bad measure of poor design (by CS on 2020-02-24 23:31:58 GMT from United States)
You can't innovate without writing a few lines of code. How's that cgroups implemetation in init.d coming along? Not at all you say?
31 • 'runit' is fabulous (by Unknown on 2020-02-24 23:54:45 GMT from Brazil)
.
>> I do wish more projects considered runit seriously though, it is a gem of an init system, very light, easy to understand, and flexible. I would be happy to see it adopted elsewhere. <<
Years ago, I tried VOID and didn't like it because of some disappointing issues. But it's true that 'runit' impressed me a lot. Then I also think this great init system should really be adopted by other Linux developers, starting by Pat Volkerding.
The main systemd-free communities (Slackware, antiX, MX, Devuan, PCLinuxOS) can make it grow (not in size, I wish :) and strongly react against Mr. Poettering's evil empire. More than a million and three hundred code lines just to boot a distro is a little too much, isn't it?
.
32 • New definition for "FEW": one-million, three hundred thousand. (by R. Cain on 2020-02-25 02:00:53 GMT from United States)
@ 30 --
Absolutely implicit in what you're saying is that one can NOT innovate without writing AT LEAST one million, three-hundred-thousand lines of code, where 25,000 would be much more than adequate..
This is a technical forum; not a political venue--
Stating that "You can't innovate without writing A FEW LINES OF CODE..." is about as transparent and vacuous as you could get as far as TRYING to make your point, particularly when it has been pointed out, in no uncertain terms, that your "...few lines of code..." are ONLY 1,300,000. Try harder.
I'm curious: just exactly WHAT do you consider a "LARGE amount of code"?
33 • Artix Runit & OpenRC Boot Issues Unresolved (by David on 2020-02-25 02:10:50 GMT from United States)
@ 29
I made a slight error in the first tip.
In your Set-up menu, you should scroll over to Devices, then scroll down to ATA Drive, hit Enter to find the Hard Disk Pre-Delay settings in increments of three seconds each.
I wouldn't necessarily continue to be advising or promoting any of the steps that I've outlined, since as I said in @23, the problem still persists, and it's distressing to hear that you've had a similar malfunction with the Artix/OpenRC version. But I certainly wouldn't discourage your attempts to fix the problem with BIOS setting manipulation.
It would appear that there is fundamental a coding error in that exists in the Artix implementations of both init systems. It is not an uncommon complaint, as I've found the issue discussed in the Artix forums as far back as 2018, and my reading also suggests that it remains a largely unresolved malfunction.
I read that it most commonly affects older hardware, so it may be that my PC's are the source of the incompatibility issue. It's not a deal breaker, as I do have hopes that the problem will ultimately be resolved.
I do prefer the lean and mean Runit over the ballooning SystemD code bloat by a country mile, so I'll continue to work with it.
By the way, I've tried to install Void a couple of times, and it failed to boot on each attempt. I'll stick with the Arch branch of the Linux tree, which I've installed and run easily on thirteen year-old hardware.
JMHO
34 • Void Linux (by Otis on 2020-02-25 02:33:07 GMT from United States)
I love the approach! The choices. Reading about Void restores more of my faith in Linux all around. No, I have not tried it, but do have Trident on another machine as an experiment. This whole thing is very interesting to me.
35 • cgroups and init (by Jesse on 2020-02-25 02:49:22 GMT from Canada)
@30: "How's that cgroups implemetation in init.d coming along? Not at all you say?"
I'd like to point out two things with regards to this idea. The first is that cgroups can be handled in many cases by using shell commands, meaning the implementation has always been there. Whether people use it when they write their initscripts is another matter. So implementing cgroups in SysV init takes zero lines of code. It just takes a handful of lines in the respective start-up scripts in distros that want to use cgroups. In other words, it isn't handled upstream in init, it's handled by the distros/services which use init.
The second point I'd like to make is that things like cgroups is something that, for philosophical reasons, would not be added to classic init implementations (like sysvinit, runit, etc) because they follow the UNIX Philosophy of doing one thing well, being small, and having a specific focus. Things like cgroup management can be tacked on top of classic inits, in an add-on layer, but it would not be added to init itself as that would be considered (from their point of view) poor design.
In summary, nothing prevents distros from using cgroups with classic inits, it is just that the implementation needs to happen at a different layer. With systemd everything is "baked in" while with classic inits new features are added as optional add-on modules.
36 • Void - Frustration (by Michael on 2020-02-25 05:25:01 GMT from Australia)
I tried void with Cinnamon desktop and was impressed with it finding my wifi connection and my Epson wifi printer. It installed in 5 minutes and boots on an old Core-2 machine in 35 seconds. Now the frustration. I used the commands in the review for XBPS and they failed to work, The problem was no repositories were set up. To set up a repo you create a file in /etc/xbps.d but there is no text editor to write to a file, not even nano or vim. So I download nano in a .tar.gz format but there is no Archive manager to extract the file.
It seems you need to a second computer to do a lot of the work and then copy files over to the Void machine. Surely they should provide at least the basic tools to set up a repo so we can install some software. The only software included, apart from setup tools, is Firefox.
I also found the sound problem in Cinnamon but not the "Policy Kit" problem mentioned in the review.
37 • Li/e/s and half truths (by Another Del/e/ted Person on 2020-02-25 06:17:55 GMT from Austria)
Installing popular, play store apps on a "degoogled" device with microg just "re-googles" the device. Pretending otherwise is folly and false advertising.
38 • GalliumOS (by hotdiggettydog on 2020-02-25 06:45:11 GMT from Canada)
I'm surprised to see Gallium on the waiting list. It should have been listed long ago.
I'm using it on 2 chromebooks. Other distros will install and run but Gallium supports hardware specific to chromebooks. Sound on my machines only work properly with Gallium for example.
It's pretty much Xubuntu setup for chromebooks. They do a decent job.
39 • Isn't /e/ phone just LineageOS? (by Matt on 2020-02-25 06:47:57 GMT from United States)
I don't see how this /e/ phone OS is any different than installing LineageOS without the Gapps packages. That option has been around for years, back when LineageOS was called cyanogenmod. Living without the Google Play Store is difficult, and as soon as you have Google Play services running, Google owns your phone completely. Even without Gapps installed LineageOS includes a bunch of binary firmware code that is not open source.
If you really are hard core about privacy and fully open source, then you could use the Replicant OS that has all the closed source stuff removed. However, that probably means that your GPS, bluetooth, and cellular modem no longer work. If you really care about privacy, you simply cannot use a cellular phone today.
40 • @39 Avoid /e/ at all costs (by machete_Badger on 2020-02-25 07:52:43 GMT from South Africa)
Yes you're correct, in actuality this is more like the spin called microg LineageOS, which does exactly what /e/ set out to do but with better intentions and saner development.
I'm mostly disappointed that this rubbish is getting coverage on this site, when it should be avoid at all costs necessary, anyone can read up on the controversies here: https://ewwlo.xyz/evil.html
Just stick to Lineage with/without microG and you're all set.
41 • @14 (by Jimothy on 2020-02-25 11:07:37 GMT from United States)
" But when I read that screenshot key is assigned, but it does not work, and there is a link for email app, but it's not even installed.... that is laughable. "
Xfce's default config assigns those things. If you want them installed, install them.
42 • @36 (by Jimothy on 2020-02-25 11:11:23 GMT from United States)
Void ships with vim as the default text editor. You could have installed nano during the installation process. It also comes with the default Finland alpha repo installed and enabled. You most likely failed to properly set up and configure your network. You can edit your xbps.d config file in vim and configure your network properly to get access to the software repos. But to be clear, this is something you broke, not something the installation didn't provide you.
43 • Void Linux and Project Trident (by Barnabyh on 2020-02-25 16:39:49 GMT from United Kingdom)
^ The Google Translate extension in really handy to have installed right now if you're reading this in Chrome.
Apart from this, the only comment I have to make this week is that I have installed both Void and Trident in the last few days. Trident would be my preferred avenue to get Void onto my machines, it was immensely fast, less than three minutes to install, and worked. With Void something went wrong at the boot loader stage but I haven't had the time to look into and troubleshoot it. Just rough, early impressions. Will try again.
Have a good week all.
44 • void (by koolaid guzzler on 2020-02-25 17:03:30 GMT from United States)
Not a fan of void. Some of the earliest systemd pushers and the project is a mess. It's not a surprise though because of the people running it. They should call it systemdvoid because so many involved in the project seem to be systemdvoid of morality. I don't care if they don't use it anymore. They have OTHER problems I want to stay far away from.
45 • void and morality @45 (by nanome on 2020-02-25 19:21:05 GMT from United Kingdom)
@44: please do tell us all about void "morality" issues.
46 • distro choices (by Andre on 2020-02-25 22:36:39 GMT from New Zealand)
A distro needs simply to get a job done. I went through a stage of trying up to ten distros a month. Now I maybe glance at one or two out of curiosity - just in case something noteworthy has changed (usually not). My main production workflow machines are on: (i) Mint 19.3 cinnamon and (ii) Manjaro cinnamon. Hmm, I like that cinnamon desktop :) Two workhorse that try to melt their CPUs for science are on MX Linux, but that is flaky and I just converted one to Solus 4.1. Now it runs perfectly and laptop #2 is now due for its upgrade away from MX for which I'm considering KDE neon. And because each of us has different use cases and needs all these distros have a place. YMWVFM - your mileage will vary from mine, always.
47 • Init system (by Eric vidal on 2020-02-26 03:26:37 GMT from New Caledonia)
You want a complete different init system than systemd with the "same" features but only doing init and service management with no more than 30 thousand lines of code?
s6: https://skarnet.org/software/s6/
s6-rc: https://skarnet.org/software/s6-rc
66: http://web.obarun.org/software/66
This set of program provide:
- Init
- PID 1
- Supervisor
- Service management
Really fast, secure, reliable, works from 11 years now (not for 66 which is younger).
Bugs (if any) are considered and fixed quickly (no "not a bug" fallacious arguments).
Can be build with glibc or musl.
Works out of the box: Many POC was made on Funtoo, Void, Antix, Arch, Devuan, KISS linux,... (see thread: s6 and 66 does it works, does it boot https://forum.obarun.org/viewforum.php?id=10)
Provide feature like:
- Frontend service file declaration with a style like INI format (easy to understand and write)
- Nested supervision tree (classic user can deal with service)
- Instantiated service
- Automatic logger creation (each service have they own logger)
- Easy change of the service configuration file
- Concept of a tree web.obarun.org/software/66/66-tree.html (AFAIK this is the only init supervision system that provide this kind of option)
- Easy to see the state of a service even the associated log file (no binary, all log are readable by human)
- ...
One time you use it you will never come back on any other init system... or not...
Try it and you will see
48 • Void (by Andy Figueroa on 2020-02-26 05:15:55 GMT from United States)
I fail to see the attraction of another fairly unique Linux distribution supported by a small team of volunteers. I'm quite happy with Gentoo, OpenRC, and OpenSSL.
49 • alt init systems (by nanome on 2020-02-26 09:50:04 GMT from United Kingdom)
@47: why did you not include Runit in your list: 6k sloC, service managment, etc. Whllst only Void, Artix and Trident use it, it can be installed on other distros [I know, I installed it on Devuan at one time].
50 • runit (by anticapitalista on 2020-02-26 15:44:53 GMT from Greece)
@49
antiX also has a runit version.
http://iso.mxrepo.com/Downloads/Final/antiX-19/
51 • Many things brought up as responses to the poorly researched review (by Signoftheantigod on 2020-02-26 16:46:36 GMT from Greece)
1st, just yesterday I attended this friends neglected old 2core amd machine that I had set up 2 years ago. The system was cloned and used today without problems, she needed a home theater machine. It had void installed last logged in May2018 with linux4.16 on it. It booted fine and the desktop opened up like it was yesterday. I upgraded everything and rebooted, if anything changed it got faster. That was void-musl on AMD 2core. No efi, just bios.
2nd If there is any criticism in the review that holds water is the poor and sloppy live-image put together by less experienced team members. Not having an easy console based editor, other than vi, is a serious mistake (despite of the bitter negation by vi fanatics). If one looks at the void buildbot one can tell that the void team is enormous. Which brings a question to organization of all those people that contribute to void. There has never been any disclosure of how void works, apart from a group of friends that work in secret. A founder vanished, the project almost fell apart, it recovered and stood on its feet, then the phantom is back in unclear relation to the team. How can this unreliable entity regain control of a distribution when his own actions nearly killed it?
3rd The void project is very well documented, one of the best, this is where most of distributions are lacking. It doesn't deserve this. If one was to engage in a serious review of a distribution one needs to go a little deeper than a half hour quick glance. Arch-Linux, by comparison, is a tiny midget in comparison, even though Arch-based distros are very popular, clones and forks of the midget.
Show some respect, there are only a handful of true distributions based on Linux, and nearly all have been consumed by IBM's, google's, oracle's, HP's, facebook's commercial interests. Gentoo and Void are among the few that provide some little hope on linux, otherwise the open and free software is restricted to clunky BSD-land, which feels like 20yo linux.
Void deserves better than this, it may not be perfect, but it is as close as you get while resisting the proprietary invasion.
PS Utilizing a slap on the face of Void's maintainers and developers to advertise other distros is not really a good idea. Some of those advertised here have also received a similar slap in the face. Grow up and stop being cannibals.
52 • @49 and @51 (by Andy Prough on 2020-02-26 18:51:16 GMT from United States)
@49:
> antiX also has a runit version. http://iso.mxrepo.com/Downloads/Final/antiX-19/
I'm surprised you aren't promoting your latest work, anticapitalista. antiX 19.1 is also available with runit: http://iso.mxrepo.com/Downloads/Final/antiX-19.1/
@51:
> Arch-Linux, by comparison, is a tiny midget in comparison
This gave me a good laugh.
53 • re: Many things brought up as responses to the poorly researched review (by nanome on 2020-02-26 19:11:45 GMT from United Kingdom)
@51 "Signoftheantigod": your remarks on the Void linux project come on the back of lurid attacks by "koolaid guzzler" @44 on the morality of its previous leader [I will not include personal information here].
I was aware of the chaotic way in which the project emerged from the founders departure, but I was pleased to find the excellent paper by Michael Aldridge [michaelwashere.net/post/2018-11-28-enobdfl] which sets out the historical facts. It explains the difficulties faced by the individual creators of an international linux distribution when the central figures walk away.
A few years back, I wanted to contribute actual money to the Void project, but couldn't. It sounds like you have information about the return of the "phantom" to take control over Void linux: please tell us more.
I prefer writing about technology, but felt the need to express my concern over the tone of the comments here. [sorry Jesse].
54 • Void (by cykodrone on 2020-02-26 19:50:54 GMT from Germany)
@22 lol xD SystemD(epartmentOfBigBroSpyware), the second they gave systemd networking, was like fully extended arm, pinched nose holding a dirty diaper.
Void sounds pretty cool, actually, never tried it nbut intrigued. All the 'not friendly' whining doesn't scare me, tinkering is fun. Thanks for the nice review and screenshots.
55 • Void (by mmphosis on 2020-02-27 12:37:06 GMT from Canada)
Thanks Jesse. This is the review I've been waiting for.
As a result, I installed 64-bit Xfce edition with the musl library, and I am using Void now. This is my first time, successfully, using a rolling release Linux distribution. I do like to hold off on the bleeding edge, but there is a lot to like in rolling release: XFCE 4.14 with many nice little fixes and advantages over 4.12. I installed elogind and it has cleared up the Xfce PolicyKit Agent error, and as a result the Restart and Shutdown menu items are now enabled. Switch User is still disabled but I've had these issues before with XFCE, so seeing them in Void is nothing new.
Runit seems very lightweight and simple. I have no problem with systemd, but my PC needs all the help it can get in the speed department otherwise I would call it a day and use Linux Mint and stop all this futzing around with configuration. Void seems very fast, not just because of the init system, but musl and the slimmed down approach to the point of some things being broken/missing like sound. I installed alsa, pulse audio, pavucontrol to get sound and volume keys working. Parole crashed for me too, so I installed VLC.
Void has had some good results over in the PowerPC world of old PowerPC Macs and also for newer Talos machines. https://www.talospace.com/2020/01/bonuses-for-big-endian.html
I hope to make Void my "usual" distro. Thanks again for the feature story.
56 • Void (by Justin on 2020-02-27 15:57:55 GMT from United States)
My experience with Void has been different. I originally used Archbang OpenRC on an old netbook. I wanted all the speed I could get and found it booted faster than the systemd variant. Archbang was great until the Artix migration of Arch OpenRC. They dropped policykit support, and I couldn't make elogind work the way they expected. The last straw was mkinitcpio never being able to build a bootable image again.
So, I switched to Void running LXLE. I also chose the musl version for similar reasons to @55. I found Void to work all right, but either it or LXLE or both were just not as snappy as Archbang. I tried to optimize the boot time with runit and found that that is not a good idea. The init system is a simple shell script, but it lacks any smarts. I ended up making my own version to spawn processes together and then spent hours trying to figure out which can start together and which need to wait. On my machine, each shell script that launches takes an extra 1s of boot time. I don't use startx for that reason, and I started globbing all the init scripts together to save time.
Long story short, I moved on. I longed for the snappier days of Arch, so I tried making my own Arch spin using shell scripts to install and configure my version, essentially rebuilding Archbang. I realized with all that hacking that I wanted dependency resolution, which is one thing systemd offers, so I bit the bullet and went that direction. It generally works fine except for some issues systemd-logind has that prevents X from starting. I could file a bug report but I expect @47's "that's not a bug, don't use feature X with Y" response.
57 • runit (by Martin on 2020-02-27 19:33:49 GMT from United Kingdom)
@50 I didn't know that anti! I have been using AntiX for years and had never heard of the runit version, must pay more attention.....!
58 • reinventing the wheel (by Gary W on 2020-02-28 00:49:37 GMT from Australia)
@13 Indeed! It always seemed to me that systemd was/is a solution desperately in search of a problem. There may come a day when systemd is thought of as a problem rather than a solution. Continuing development of alternatives (other than sysvinit of course, which could be called "fully developed") leads one to think that there are people who already see systemd as a problem.
59 • Strip Initramfs for Boot Speed (by Embedded Systems Engineer on 2020-02-28 01:23:07 GMT from United States)
@56 Justin - That's not moving on, but circling aimlessly. Anyone so willing to hack boot for speed has one answer: strip initramfs. Compile a kernel with driver modules needed. Boot straight into it from your bootloader. This method works in any distro. Void is a good bet, as it's used in embedded systems this way.
Stripping has nada to do with init scripts. It's about kernels and GRUB and such. For init scripting, look into s6 and 66, available in Void repos. They handle complex dependencies, if you have any. Those dependencies are, like said kernel, precompiled. Coming from Arch, you could try Obarun, which ships s6+66 out of the box, leaving only initramfs stripping to accomplish.
60 • Boot Speeds (by Cynic on 2020-02-28 03:29:42 GMT from Ghana)
I am still trying to understand why there is such a concern with boot speeds.. especially on a system which shouldn't require daily boots to begin with.
As long as it doesn't take MS server startup times, it doesn't bother me.
What does matter to me:
1. Does it always boot or do random issues occur?
2. Is it fast once booted?
A fast boot into a slow system seems to give people the misconception that faster boot equates to faster "runtimes" in the OS.. this is a falicy.
My two cents..
61 • @ 60 Boot Speeds (by OstroL on 2020-02-28 08:51:52 GMT from Poland)
These days, boot speeds are a concern. Right now, Linux distros are somewhat slow at booting. I have a Windows 10 2 in 1 with Pentium N4200 @1.1GHz, which boots practically immediately. It is the same with Samsung Tab S5e. But, my Linux laptop with much faster processor takes some time to boot.
62 • @61 - Try Solus! (by Uncle Slacky on 2020-02-28 11:00:29 GMT from United States)
If you want fast booting, try Solus. The developers have done a lot of boot time optimisation work on it. It boots in a few seconds, even on my Pentium N5000 laptop (though it does have an SSD).
63 • @59, @60 (by Justin on 2020-02-28 15:23:46 GMT from India)
@60: "especially on a system which shouldn't require daily boots to begin with"
If that were the case, I might agree. I use the netbook sparingly for quick browsing where I need more than a phone and more portability than a desktop. If I can wait 10s instead of 30s, why shouldn't I? It fits my use case where I might use it once or twice a day and then not at all for a week.
@59: I don't know if it's "aimless" circling, but it is circling. :) At the time, I stripped initramfs and saved 0.5s. If I switched "startx" for "startx /usr/bin/openbox" I saved ~1s and embedding startx into my .bashrc saved another 1s (they were in the critical path where everything was waiting on them to complete). I used bootchart and now systemd-bootchart to measure timings. I could save another 2s if Xorg could stop blocking while waiting to discover my keyboard, but I'm not hacking Xorg. I took a lot of tips from the "boot Linux in 5 seconds" article, so I had goals and budgets. The netbook requires udev to boot because of the quirky emmc (I followed Arch's article). Without compiling my own code, which I thought about with Gentoo, I pushed it about as far as I could go.
The snappiness I referred to was overall perceived desktop speed, not boot time. I don't know a way to measure UI responsiveness quantitatively (if someone does, please comment next week). I felt Arch's openbox + tint2 was faster than Void's LXDE built on openbox.
I'll take a look at Obarun. I found it after I had put in the work. The complex dependencies really are from looking at bootchart and wanting my processor and I/O to max out during all phases of the boot. Again, refer to that booting in 5 seconds article. Having an idle processor waiting on a timeout is wasteful, so I'd rather have 20 processes like that trying to run and fill in all the gaps. That's why threading brings benefits even on single core CPUs.
64 • @62 (by OstroL on 2020-02-28 15:24:21 GMT from Poland)
Solus is also slow at booting, just like all other Linux distros. The thing is, it takes some time to start all services, before coming to the login screen. Android Tab must be always on to boot up so fast, just after tapping the screen and touching the fingerprint scanner. Windows 10 2 in 1 is not always on, but boots up quite fast, after pushing the start button and the fingerprint scanner. Don't know how Windows does it, but quite interesting. Maybe, the Linux distro devs should dual boot with Windows to find out how (instead of using Macbooks).
Solus' Budgie is stuck in 10.5.1, I suppose, since Ikey left, so not that interesting any more.
65 • @64 (by Cynic on 2020-02-28 16:48:33 GMT from Ghana)
Most likely you don't have full shutdown enabled. Windows 10 by default does not do a "traditional" shutdown, but rather makes it look like it did. This option must be disabled in order to mount the drive/partition outside of windows. When "coldbooting" windows 10, it is rarely faster than the average Linux.
In regards to shaving seconds off or a 10s vs 30s boot, I would have to ask if the 20 seconds really makes that much of a difference.. unless of course you're Elon Musk and just wasted a chunk of your 5 minute schedule segment :)
I still see no point in having a fast boot, especially if booting into a system which may be buggier or open apps slower.. I tend to worry more about the speed of what I'm doing rather than the 30s it took to boot..
66 • @64 - Win10 boot times (by Andy Prough on 2020-02-28 21:32:39 GMT from United States)
@65 is correct - Win10 "achieves fast boot times" (which aren't really all that fast) by not actually shutting down. In order to shut down, you need to tell it to shut down, watch it shut down, and then hold the power button for several seconds to get it to post and shut down again. At that point it is actually shut down.
The Artix distro with openRC or runit or S6 boots even faster than "fast-boot" Win10.
Number of Comments: 66
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 1159 (2026-02-09): Sharing files on a network, isolating processes on Linux, LFS to focus on systemd, openSUSE polishes atomic updates, NetBSD not likely to adopt Rust code, COSMIC roadmap |
| • Issue 1158 (2026-02-02): Manjaro 26.0, fastest filesystem, postmarketOS progress report, Xfce begins developing its own Wayland window manager, Bazzite founder interviewed |
| • Issue 1157 (2026-01-26): Setting up a home server, what happened to convergence, malicious software entering the Snap store, postmarketOS automates hardware tests, KDE's login manager works with systemd only |
| • Issue 1156 (2026-01-19): Chimera Linux's new installer, using the DistroWatch Torrent Corner, new package tools for Arch, Haiku improves EFI support, Redcore streamlines branches, Synex introduces install-time ZFS options |
| • Issue 1155 (2026-01-12): MenuetOS, CDE on Sparky, iDeal OS 2025.12.07, recommended flavour of BSD, Debian seeks new Data Protection Team, Ubuntu 25.04 nears its end of life, Google limits Android source code releases, Fedora plans to replace SDDM, Budgie migrates to Wayland |
| • Issue 1154 (2026-01-05): postmarketOS 25.06/25.12, switching to Linux and educational resources, FreeBSD improving laptop support, Unix v4 available for download, new X11 server in development, CachyOS team plans server edtion |
| • Issue 1153 (2025-12-22): Best projects of 2025, is software ever truly finished?, Firefox to adopt AI components, Asahi works on improving the install experience, Mageia presents plans for version 10 |
| • Issue 1152 (2025-12-15): OpenBSD 7.8, filtering websites, Jolla working on a Linux phone, Germany saves money with Linux, Ubuntu to package AMD tools, Fedora demonstrates AI troubleshooting, Haiku packages Go language |
| • Issue 1151 (2025-12-08): FreeBSD 15.0, fun command line tricks, Canonical presents plans for Ubutnu 26.04, SparkyLinux updates CDE packages, Redox OS gets modesetting driver |
| • Issue 1150 (2025-12-01): Gnoppix 25_10, exploring if distributions matter, openSUSE updates tumbleweed's boot loader, Fedora plans better handling of broken packages, Plasma to become Wayland-only, FreeBSD publishes status report |
| • Issue 1149 (2025-11-24): MX Linux 25, why are video drivers special, systemd experiments with musl, Debian Libre Live publishes new media, Xubuntu reviews website hack |
| • Issue 1148 (2025-11-17): Zorin OS 18, deleting a file with an unusual name, NetBSD experiments with sandboxing, postmarketOS unifies its documentation, OpenBSD refines upgrades, Canonical offers 15 years of support for Ubuntu |
| • Issue 1147 (2025-11-10): Fedora 43, the size and stability of the Linux kernel, Debian introducing Rust to APT, Redox ports web engine, Kubuntu website off-line, Mint creates new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak development resumes |
| • Issue 1146 (2025-11-03): StartOS 0.4.0, testing piped commands, Ubuntu Unity seeks help, Canonical offers Ubuntu credentials, Red Hat partners with NVIDIA, SUSE to bundle AI agent with SLE 16 |
| • Issue 1145 (2025-10-27): Linux Mint 7 "LMDE", advice for new Linux users, AlmaLinux to offer Btrfs, KDE launches Plasma 6.5, Fedora accepts contributions written by AI, Ubuntu 25.10 fails to install automatic updates |
| • Issue 1144 (2025-10-20): Kubuntu 25.10, creating and restoring encrypted backups, Fedora team debates AI, FSF plans free software for phones, ReactOS addresses newer drivers, Xubuntu reacts to website attack |
| • Issue 1143 (2025-10-13): openSUSE 16.0 Leap, safest source for new applications, Redox introduces performance improvements, TrueNAS Connect available for testing, Flatpaks do not work on Ubuntu 25.10, Kamarada plans to switch its base, Solus enters new epoch, Frugalware discontinued |
| • Issue 1142 (2025-10-06): Linux Kamarada 15.6, managing ZIP files with SQLite, F-Droid warns of impact of Android lockdown, Alpine moves ahead with merged /usr, Cinnamon gets a redesigned application menu |
| • Issue 1141 (2025-09-29): KDE Linux and GNOME OS, finding mobile flavours of Linux, Murena to offer phones with kill switches, Redox OS running on a smartphone, Artix drops GNOME |
| • Issue 1140 (2025-09-22): NetBSD 10.1, avoiding AI services, AlmaLinux enables CRB repository, Haiku improves disk access performance, Mageia addresses service outage, GNOME 49 released, Linux introduces multikernel support |
| • Issue 1139 (2025-09-15): EasyOS 7.0, Linux and central authority, FreeBSD running Plasma 6 on Wayland, GNOME restores X11 support temporarily, openSUSE dropping BCacheFS in new kernels |
| • Issue 1138 (2025-09-08): Shebang 25.8, LibreELEC 12.2.0, Debian GNU/Hurd 2025, the importance of software updates, AerynOS introduces package sets, postmarketOS encourages patching upstream, openSUSE extends Leap support, Debian refreshes Trixie media |
| • Issue 1137 (2025-09-01): Tribblix 0m37, malware scanners flagging Linux ISO files, KDE introduces first-run setup wizard, CalyxOS plans update prior to infrastructure overhaul, FreeBSD publishes status report |
| • Issue 1136 (2025-08-25): CalyxOS 6.8.20, distros for running containers, Arch Linux website under attack,illumos Cafe launched, CachyOS creates web dashboard for repositories |
| • Issue 1135 (2025-08-18): Debian 13, Proton, WINE, Wayland, and Wayback, Debian GNU/Hurd 2025, KDE gets advanced Liquid Glass, Haiku improves authentication tools |
| • Issue 1134 (2025-08-11): Rhino Linux 2025.3, thoughts on malware in the AUR, Fedora brings hammered websites back on-line, NetBSD reveals features for version 11, Ubuntu swaps some command line tools for 25.10, AlmaLinux improves NVIDIA support |
| • Issue 1133 (2025-08-04): Expirion Linux 6.0, running Plasma on Linux Mint, finding distros which support X11, Debian addresses 22 year old bug, FreeBSD discusses potential issues with pkgbase, CDE ported to OpenBSD, Btrfs corruption bug hitting Fedora users, more malware found in Arch User Repository |
| • Issue 1132 (2025-07-28): deepin 25, wars in the open source community, proposal to have Fedora enable Flathub repository, FreeBSD plans desktop install option, Wayback gets its first release |
| • Issue 1131 (2025-07-21): HeliumOS 10.0, settling on one distro, Mint plans new releases, Arch discovers malware in AUR, Plasma Bigscreen returns, Clear Linux discontinued |
| • Issue 1130 (2025-07-14): openSUSE MicroOS and RefreshOS, sharing aliases between computers, Bazzite makes Bazaar its default Flatpak store, Alpine plans Wayback release, Wayland and X11 benchmarked, Red Hat offers additional developer licenses, openSUSE seeks feedback from ARM users, Ubuntu 24.10 reaches the end of its life |
| • Issue 1129 (2025-07-07): GLF OS Omnislash, the worst Linux distro, Alpine introduces Wayback, Fedora drops plans to stop i686 support, AlmaLinux builds EPEL repository for older CPUs, Ubuntu dropping existing RISC-V device support, Rhino partners with UBports, PCLinuxOS recovering from website outage |
| • Issue 1128 (2025-06-30): AxOS 25.06, AlmaLinux OS 10.0, transferring Flaptak bundles to off-line computers, Ubuntu to boost Intel graphics performance, Fedora considers dropping i686 packages, SDesk switches from SELinux to AppArmor |
| • Issue 1127 (2025-06-23): LastOSLinux 2025-05-25, most unique Linux distro, Haiku stabilises, KDE publishes Plasma 6.4, Arch splits Plasma packages, Slackware infrastructure migrating |
| • Issue 1126 (2025-06-16): SDesk 2025.05.06, renewed interest in Ubuntu Touch, a BASIC device running NetBSD, Ubuntu dropping X11 GNOME session, GNOME increases dependency on systemd, Google holding back Pixel source code, Nitrux changing its desktop, EFF turns 35 |
| • Issue 1125 (2025-06-09): RHEL 10, distributions likely to survive a decade, Murena partners with more hardware makers, GNOME tests its own distro on real hardware, Redox ports GTK and X11, Mint provides fingerprint authentication |
| • Issue 1124 (2025-06-02): Picking up a Pico, tips for protecting privacy, Rhino tests Plasma desktop, Arch installer supports snapshots, new features from UBports, Ubuntu tests monthly snapshots |
| • Issue 1123 (2025-05-26): CRUX 3.8, preventing a laptop from sleeping, FreeBSD improves laptop support, Fedora confirms GNOME X11 session being dropped, HardenedBSD introduces Rust in userland build, KDE developing a virtual machine manager |
| • Issue 1122 (2025-05-19): GoboLinux 017.01, RHEL 10.0 and Debian 12 updates, openSUSE retires YaST, running X11 apps on Wayland |
| • 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 |
| • 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 | 
LangitKetujuh OS
LangitKetujuh OS is an Indonesian desktop and multimedia Linux distribution based on Void. It uses the KDE Plasma desktop and is available in "Home" and "Studio" editions. Some of its main features include the use of Void's XBPS package manager, availability of builds compiled with glibc or musl libc C libraries, the runit init system, the Vulkan API, the latest LTS Linux kernel, use of the zram block device in RAM, and separate builds for AMD and Intel processors. The LangitKetujuh "Studio" edition offers a vast range of applications for digital illustration and painting, full-featured 2D/3D animation, desktop publishing and layout design, photography and image management, audio and video non-linear editing, as well as CAD and mechanical drawing.
Status: Active
|
| 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.
|
|
• 
• 
• 
• 
• 
• 
• 
