 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 2, value: US$16) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Debian Rust implementation/ Filtering options (by Keith S on 2025-11-10 02:05:25 GMT from United States)
I'm concerned enough about Debian's rewrite of APT in Rust that I'm thinking of switching from MX Linux and antiX to EndeavourOS or some other Arch spin. The mantra is that "It's memory-safe!" but rewrites are just new, untested code that is more likely to have bugs. You don't have to look farther than Ubuntu's new rewritten coreutils for evidence.
I tried the new filters under Release for news articles and love it. This is what continuous improvement looks like.
2 • Fedora 43 Review (by Slappy McGee on 2025-11-10 02:13:38 GMT from United States)
This is one of those times (and I've seen a few over time) when my experiences with a reviewed distro are nothing at all as reported in the review.
Installing and running Fedora 43 has been nothing but (cool) joy, and it's going to remain on this machine for the foreseeable future (which often means the next 6 month update.. hopefully not this time)... hoping that 44 does not mess things up.
I feel they uncorked a great one with 43. Everything installed and works as expected. Given I do not use the command line much for installation of packages etc; perhaps that's an area that I would feel differently about if I ran into the reviewer's description of how that went for him.
I don't know what else to say. :o)
3 • Which flavour of Fedora is your favourite? (by jorge on 2025-11-10 03:34:46 GMT from Argentina)
Anyone
4 • re: Debian Rust implementation/ Filtering options (by InvisibleInk on 2025-11-10 03:40:32 GMT from United States)
@ #1
I'm not too concerned about this, or really anything else they are up to. I'm sticking to stable Trixie, and I won't be running testing or sid, so none of this is likely to affect me.
I feel like, if they are going to do this, the earlier the better, and that they are will test the hell out of this before Forky is released sometime in late '27.
5 • Fedora 43 (by Rich on 2025-11-10 04:04:53 GMT from The Netherlands)
I have seen the same review about Fedora a couple of years ago, thats odd is it not?
6 • Don't force rust in apt (yet) (by no rush for rust on 2025-11-10 04:36:19 GMT from United States)
@ # 1
Rust coreutils is a big deal but one can always revert to the GNU coreutils.
The bigger issue is enforcing rust in apt within 6 months. Too fast is not good for debian. Not sure how long it will take to port rust to these platforms but 6 months seems too soon seeing that debian 13 was just released. They should delay the rust migration by 1 year, so users can choose between c-apt and rust-apt for debian 14. Then the devs can require rust-apt in debian 15. Dont rush the rust!
7 • Fedora's flavour (by Jyrki on 2025-11-10 04:54:46 GMT from Czechia)
Despite fact I started with Red Hat Linux 4.2 Biltmore way back in 1996, nothing could be more distant to my current taste than Red Hat and Fedora.
In fact, in my eyes, Red Hat is Microsoft of Linux world as they violitating it, taylor making for their own purpuse and needs and stealing it off from Linux community.
8 • Fedora 43 (by BlueIV on 2025-11-10 04:55:36 GMT from United States)
I think a component of varying experiences with any particular distro release is the large amount of different hardware that is being used. I have had different results than others sometime report and even on my different machines. This seems to happen more often with smaller distros but can even happen in larger projects (and between releases as I'm sure everyone has experienced).
9 • Distro review (by makosol on 2025-11-10 05:56:24 GMT from France)
It would be vert useful to mention which hardware was used for distro testing, as experience may vary very much with it.
10 • Fedora (by Fleck on 2025-11-10 06:07:47 GMT from Australia)
Jesse, in your opinion poll you should include the option; don't use fedora or never plan on using fedora or something like that
Regarding the Linux kernal 40 million lines of code; how much of that are binary blobs for devices?
The development of the kernel does not appear to be sustainable in the long term. At what point will we all realize that monolithic designs like this can't continue to grow exponentially.
Redox OS has the right idea; microkernel design which focus on user-space, unlike Monolithic kernels which focus on kernel-space.
Just waiting on Redox to hit a stable release before jumping the linux ship. Alternatively, perhaps Gentooize my linux experience and recompile the kernerl removing all the unecessary crud post install
11 • @9 -- He always lists his testbed hardware (by eco2geek on 2025-11-10 06:36:11 GMT from United States)
It's at the end of the review, e.g.
---
"Hardware used in this review
My physical test equipment for this review was an HP DY2048CA laptop with the following specifications:
Processor: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
Display: Intel integrated video
Storage: Western Digital 512GB solid state drive
Memory: 8GB of RAM
Wireless network device: Intel Wi-Fi 6 AX201 + BT Wireless network card"
---
12 • Rust in APT (by Josh Smith on 2025-11-10 07:00:20 GMT from Australia)
@6 I agree wholeheartedly. One of the main pros of Debian is its portability and it seems like the team is shooting itself in a place I'd rather not mention by adding Rust to APT with only 6 months' notice.
13 • Reboot after updates (by Nullbuddy on 2025-11-10 08:23:59 GMT from Germany)
@Jesse: Rebooting after updates is technical the right thing to do (TM). To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update.
Knowing above, it does not mean that I will reboot my system after non-kernel updates, or that I often run into trouble by not rebooting my system, but I am at least aware enough to restart my browsers or webservers/firewalls, if a component of them is updated.
OTOH I run Debian, so the deltas between an update should just be a security patch or a minor bugfix, where in Fedora one could jump a major version. Even in Fedora one can easily update the whole system via DNF from the CLI, w/o rebooting.
tl;dr: Asking for a reboot after a software update is IMHO the right thing to do and a good default for most users. Could we fix this in theory? We could, but I'd rather thave engineering energy invested in a lot of other areas first.
14 • Apt Rust (by Hank on 2025-11-10 08:24:03 GMT from Germany)
Mr julian klode is the Uuntu core developer / Debian dev who has announced he will
break apt for many devices by forcing a Rust Toolchain in to Debian.
Quote:
It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.
Thank you for your understanding.
Problem is in its core a statement by present Debian Leader.
if you think its right do it
That is capitulation not leadership
It has already led to problems for other distros who use alternatives to system D, they are yet again being hit despite a General Resolution to not do so.
At the core Debian is being ever more removed from its original core mission, being the universal operating system.
Notably the persons involved are systemD evangelists, IBM Rhel and Ubuntu deeply involved.
15 • MX Linux 25 KDE (by Tony Smith (UK) on 2025-11-10 09:37:16 GMT from United Kingdom)
Years and years ago, my first adventure into Linux was Mepis, and I was excited that MX had been released. I installed this after Distro-hopping around the world, learning that my preference is a Debian based Distro with KDE. Not being an expert, simplicity is important to me, so I was delighted to find the whole process smooth, fast and simple and MX meets all of my requirements, Debian-based and KDE. The distribution is both smooth and quick, and it is obvious that the developers have used their vast experience to bring a superb product to us.
Thank you so much for your thought and expertise and MX Linux is the best I have used.
16 • Tony Smith (by linuxseekers on 2025-11-10 09:59:36 GMT from Malaysia)
Mine all-time were Mandrake,
Red Hat 9, and Suse 6.1
I reviewed Mepis 20 years
ago because i really like its
slimness.
17 • Selectable systemd/sysv unofficial respin for MX available (by Uncle Slacky on 2025-11-10 10:54:40 GMT from France)
Apparently someone has managed to incorporate both inits in a single ISO (as in previous versions of MX) - it's unofficial for the moment at least: https://forum.mxlinux.org/viewtopic.php?t=86241
18 • Restart (by Jesse on 2025-11-10 11:35:27 GMT from Canada)
@13: > "Rebooting after updates is technical the right thing to do (TM)."
Why do you think that? There is no technical reason an operating system needs to reboot after applying updates, especially these days in the era of live kernel patching. At most, we need to restart a few services to get all the benefits of all new patches.
> "To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update."
openSUSE can do this. All the projects in the Debian family can do this. Fedora seems to be the only one pushing this idea a reboot is required. Which is especially strange since Red Hat (their downstream and sponsor) has been one of the biggest advocates of live patching to avoid system reboots.
19 • Hardware Fedora 43 Used On (by Slappy McGee on 2025-11-10 11:45:26 GMT from United States)
@9 inxi yields:
12Machine:
12Type Laptop 12System Acer 12product Aspire A517-52 12v V1.26 12serial
12Mobo TGL 12model Jasmine_TL 12v V1.26 12serial 12UEFI Insyde 12v 1.26
12date 03/14/2022
12Battery:
12ID-1 BAT1 12charge 33.5 Wh (95.4%) 12condition 35.1/48 Wh (73.1%)
12CPU:
12Info quad core 12model 11th Gen Intel Core i7-1165G7 12bits 64 12type MT MCP 12cache 12L2 5 MiB
12Speed (MHz) 12avg 4100 12min/max 400/4700 12cores 121 4100 122 4100 123 4100 124 4100 125 4100 126 4100 127 4100
128 4100
12Graphics:
12Device-1 Intel TigerLake-LP GT2 [Iris Xe Graphics] 12driver i915 12v kernel
12Device-2 Quanta HD User Facing 12driver uvcvideo 12type USB
12Display wayland 12server Xwayland 12v 24.1.9 12compositor kwin_wayland 12driver 12gpu i915
12resolution 1920x1080~60Hz
12API EGL 12v 1.5 12drivers iris,swrast 12platforms gbm,wayland,x11,surfaceless,device
12API OpenGL 12v 4.6 12compat-v 4.5 12vendor intel mesa 12v 25.2.6 12renderer Mesa Intel Iris Xe Graphics
(TGL GT2)
12API Vulkan 12v 1.4.321 12drivers intel,llvmpipe 12surfaces N/A
12Info 12Tools 12api clinfo, eglinfo, glxinfo, vulkaninfo 12de kscreen-console,kscreen-doctor
12wl wayland-info 12x11 xdriinfo, xdpyinfo, xprop, xrandr
12Audio:
12Device-1 Intel Tiger Lake-LP Smart Sound Audio 12driver sof-audio-pci-intel-tgl
12API ALSA 12v k6.17.7-300.fc43.x86_64 12status kernel-api
12Server-1 PipeWire 12v 1.4.9 12status active
12Network:
12Device-1 Intel Wi-Fi 6 AX201 12driver iwlwifi
12IF wlp0s20f3 12state up 12mac
12Device-2 Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet 12driver r8169
12IF enp1s0 12state down 12mac
20 • Fedora 43 KDE (by Aroldo on 2025-11-10 11:59:55 GMT from Italy)
Fortunately the "Everything ISO netinstaller" still has the old anaconda and it allows you to choose any of the available desktop environments.
21 • Reboot after updates (by Giacomo on 2025-11-10 12:04:31 GMT from Italy)
@13
"Asking for a reboot after a software update is IMHO the right thing to do and a good default for most users."
I also think so.
22 • Rust (by Keith S on 2025-11-10 13:57:40 GMT from United States)
It's interesting to me that The major distros are pushing Rust hard after it was shut out of the kernel. The reflexive conspiracy theorist in me wonders if it isn't another route to trying to force Rust into the colonel eventually. The supposed benefit of Rust is that it is memory safe, but well-written C is memory safe as well, and is easier to read. But if your goal is to eliminate human developers so that all your code can be written by AI, then Rust might be the better choice. Again, I admit that I am reflexively distrustful of projects that are controlled by billionaires, so this is just speculation.
23 • AI comments (by Keith S on 2025-11-10 14:00:10 GMT from United States)
Yes, my previous comment was written using AI voice recognition. But it is memory safe and I'm sure that humans can rewrite the errors in their minds to be able to understand it.
24 • Rust and apt (by DaveT on 2025-11-10 14:51:42 GMT from United Kingdom)
Does Julian Klode have the right to decide all by himself that he will introduce Rust dependencies into apt?
Surely that is a major decision that needs to be made by some committee or other.
I use Devuan - I hope they can manage to keep their own Rust free version of apt going...
25 • Rusty apt and debian derivatives (by A hobbit on 2025-11-10 16:10:55 GMT from Chile)
Im really interested in how are the many debian derivatives going to react to rust-apt. Devuan in particular, since I have a soft spot for the project and its origin.
26 • Reboot after updates (by Eric on 2025-11-10 16:53:25 GMT from Sweden)
@13
> To the best of my knowledge, there is no Linux system on the market which restarts the correct services/applications after an update.
There is a package for this purpose called "needrestart", it is used by default at least on Ubuntu Server AFAIK, it runs after update via a hook mechanism in dpkg or APT. There is also an older utility "checkrestart" in the "debian-goodies" package which can be run manually.
27 • @15 MX Linux 25 KDE (by Geo. on 2025-11-10 16:56:22 GMT from Canada)
Agreed Mepis was a wonderful breath of fresh air. I found the ease of installation, set-up, and everyday use to be top shelf. I'm so glad it came back as MX. Great team on that distro. Thank you, MX crew, for your dogged efforts.
28 • Fedora (by David on 2025-11-10 16:59:18 GMT from United Kingdom)
My favourite Fedora? Well, the first distro I installed for myself was Fedora 1, and that wasn't bad. The last one I used was Fedora 10, by which time I was tired of being used as a guinea pig.
29 • Memory safety (by Eric on 2025-11-10 17:35:15 GMT from Germany)
@22:
No, "well-written C" is not (usually) memory-safe. Memory safety is a property of language and its runtime environment, not of particular program or library. It must be impossible (by default, without using non-essential and optional "unsafe" constructs) for a memory-safe language to write a program which can (accidentally) corrupt an unrelated memory object when modifying a different one. It is possible to make C memory-safe by compiling with AddressSanitizer and UndefinedBehaviorSanitizer or similar runtime libraries, but this incurs a huge memory overhead, and execution speed also slows down roughly 2x or more.
The next C++ standard is going to include memory safety extensions, so it will be possible to rewrite APT in memory-safe C++ subset.
30 • Size and stability of the Linux kernel (by Eric on 2025-11-10 17:43:40 GMT from Germany)
Well, the Linux kernel IS actually incredibly buggy, just see a list of circa 100 vulnerabilities fixed in each Ubuntu kernel update every week. There are parts of code that nobody really understands. Remember why you cannot scroll back in virtual consoles anymore.
31 • Rust in Debian APT? (by JeffC on 2025-11-10 17:59:54 GMT from United States)
The biggest problem with Rust in Debian is that Rust is a fast moving target, the final specification for the Rust language has not yet been released.
Debian will end up supporting code long abandoned by upstream in their core package management system.
The response from the Rust devs will most likely be to tell them that they should update to a newer Rust, but Debian Stable cannot do this.
32 • APT (by Jesse on 2025-11-10 18:36:07 GMT from Canada)
@24: "Does Julian Klode have the right to decide all by himself that he will introduce Rust dependencies into apt?"
Yes, of course. The author of a project has the right to do whatever they want with it.
"Surely that is a major decision that needs to be made by some committee or other."
Debian has a committee which can decide whether to adopt the new version of APT. But they can't tell developers what to work on in their own time.
@25:
"Im really interested in how are the many debian derivatives going to react to rust-apt. "
That's easy: zero. Rust runs on almost all the architectures downstream distributions use.
33 • @13 Reboot after update (by Jeffrey on 2025-11-10 15:05:29 GMT from Austria)
> Rebooting after updates is technical the right thing to do (TM).
This is misleading at best, but definitely not true as-is. Only parts of the system that can't live-update need to be restarted, and if an update only carries configuration updates, you usually don't even need a service restart, only a config-reload (SIGHUP reload-config or whatever else).
> Asking for a reboot after a software update is IMHO the right thing to do
I'd agree, but you just moved the goalpost. Not to mention, `needrestart (1)` does exactly that, plus it offers you the choice of which (if any) of the services in need of a restart should be restarted. It can be automated, in Debian-based distros it integrates in the update methods (CLI or graphical), and you can run it manually as an administrator.
34 • @15 (by kc1di on 2025-11-10 19:46:36 GMT from United States)
I too used Mepis back in the day and MX25 is a good release well thought out and works fine for with the KDE DE. And I've use many distros over the years. MX is amoung my favorites.
35 • Rust implementation re: Apt (by Dan G on 2025-11-10 21:29:14 GMT from United States)
I thought the threat to developers that they would either put Rust hooks in their packages within 6 months or sunset their projects was such a nice touch (sarcasm).
It feels like the developer is trying to force the distribution as a whole, to switch to Rust (a new language that hasn't even been fully implemented, standardized, widely utilized, or even allowed in the kernel yet) by rewriting the one official package management app that literally is the lifeblood of the distribution in it, saying that all of the other packages will work with it or else they won't be able to be in the distribution. That sounds like crap.
The maintainer needs to make Apt so that it is compliant with the other software languages out there, or debian needs to provide an alternative to Apt that will make the need for it go away.
36 • Fedora 43 (by Wef on 2025-11-10 21:38:38 GMT from Australia)
About a year ago I finally tired of the endless 6-monthly re-installation chore with Fedora after something like 20 years of it: update the OS, reboot, specify the new version, wait for the 2-Gb download, reboot, look through the system for changed config files, diff and merge them, maybe reboot yet again. Then rinse and repeat for every system in the house. And then there was the growing corporatisation and enshitification of stuff. I jumped to Voidlinux on all my machines and now it's a simple and occasional update when I feel like it. No need to reboot unless I really need the new kernel. Joy! And no systemd.
37 • @36 (by wef on 2025-11-10 21:46:02 GMT from Australia)
oh and I forgot - the voidlinux package management (xbps) is so fast. It makes fedora's rpm look like a snail by comparison.
38 • New Fedora installer (by bsduck on 2025-11-10 23:02:40 GMT from Switzerland)
Jesse, there actually is an advanced partitioning tool in the new Fedora installer, but it's so well hidden that I'm not surprised you didn't find it. It can be launched from the three-dot menu on the top right edge of the installer.
39 • Alternatives to Apt-Rust (by Carl on 2025-11-11 01:22:37 GMT from United States)
Pixi.sh maybe Debian should adopt rather than rewriting apt. Pixi is written in Rust. My only quibble is Pixi's constant re-downloading of the remote index for seemingly every command. Pixi assumes super-fast Internet speeds.
The Rust ecosystem still lacks polish. Most Rust things lack man pages and shell completion files. Typical CMake setups include such targets. I suppose Rust stuff will get there. A lot of GitHub issues are just "Add man pages" or "Follow XDG standards."
Dependency constraint tracking seems better suited to a logic language like Mercury. A package manager in Mercury would be 10x fewer lines of code than Rust and run 75% as fast.
Even Julia language might work. It has a native packaging tool and very high-speed performance by design.
Void Linux I use and love. Yes the xbps suite is fast, but it's C language, and not much developed any more, like Pacman from Arch Linux, which always rejected improvement ideas. Void's xbps-query is confusing. It has taken third parties to develop GUI screens (fuzzypkg is handy). Sometimes I've had corrupt indices for whatever network reasons, and had to rm -rf /var/db/xbps/http* then resync. No error messages told me how or where to fix the problem. Another gotcha is autodeletion. If your network drops while downloading a Void package, then a partial package won't match its corresponding sig file, and proceeding to install phase, xbps deletes the partial file without asking. So I wrote a workaround script. If a download breaks, I restart the script. When it's done, I can install everything.
Recently a kernel failed to work over ZFS stuff I had deleted. Dracut could not emit an initramfs. Dracut reported the error, but xbps-install did not scan its return code. Upon reboot, the system hung in outer space with not even a "blue-screen" message, lacking an initramfs to load. The cause was ZFS package removal not removing a ZFS dracut config or at least checking dracut's return code. Overall, xbps has sharp burrs that the average user, and even developers may find frustrating. These could be polished.
40 • Which flavour of Fedora is your favourite? (by Just4fun on 2025-11-11 02:05:31 GMT from Sweden)
None!
Which was not (as usual) among the answer options
41 • Debian apt rust - Julian Klode (by Rally on 2025-11-11 02:38:25 GMT from Thailand)
In the Debian mailing list there is one answer to Julian Klodes announcement with that I agree 100%:
"I find this particular wording rather unpleasant and very unusual to
what I'm used to from Debian in the past. I have to admit that I'm a
bit disappointed that such a confrontational approach has been chosen.
Thanks,
Adrian"
42 • @29 Memory safety (by Keith S on 2025-11-11 03:32:25 GMT from United States)
Yes, there is a cost to writing code in C that is memory safe, but when I said "well-written," I was basically referring to something like OpenBSD source code, which has been fuzzed, analyzed, tested, attacked, and refined for 30 years. I have more confidence in the safety of that code than almost any other, regardless of language, unless the assertion is that Rust (or Java or other languages that claim memory safety) are incapable of coding errors that lead to vulnerabilities. Rust has a much smaller and less experienced base of developers, so guardrails for memory errors does not mean error-free. That was my only point. As others have mentioned, six months is a pretty short window for, what, 60,000 packages in the Debian repos? The approach is probably meant to drive laggards to the designated language that is believed to eliminate all vulns, but it is more than a little ham-handed and does not inspire trust.
43 • NOT user of Fedora (by Ano Sixtynine on 2025-11-11 08:47:18 GMT from Bulgaria)
There should be an option "I do not use FEDORA" in the pool.
This will give additional feedback on Fedora's popularity.
44 • @39 Alternatives to Apt-Rust (by picamanic on 2025-11-11 10:58:03 GMT from United Kingdom)
@39 Alternatives to Apt-Rust: I agree with what you say about Rust: Apt and its parent Dpkg have been around for 25-30 years. I cannot understand this constant need for active development of software that has become stable and useful: if obscure bugs are discovered, they can be fixed. Rewriting Apt in Rust would be, in my opinion, be a monumental waste of time and resources, and dangerous, despite Rusts memory safety.
For new projects, modern languages like Zig or Julia might be better. I only write small programs these days, and prefer C over C++, or anything more exotic.
I have used "stock" Void Linux and XBPS for many years on an unreliable 600kbyte/s ADSL connection, and have not encountered the serious problems you describe. Maybe your use ZFS has made the file system less reliable than simpler, more mature file systems [I only use ext2!].
45 • Fedora poll (by Alan on 2025-11-11 14:02:30 GMT from United Kingdom)
Having read and re-read this weeks poll, I simply ignored it. As I never use Fedora, I understood that it wasn't aimed at users like myself.
Maybe people are feeling left out if the weekly poll questions don't apply to them?
46 • Rust solve a license problem (by LinuxBackdoor on 2025-11-11 14:08:49 GMT from Argentina)
Rust coreutils implementation only solve a license issue from GNU Coreutils.
Again it's a violation to core freedoms from this evil companies/employees.
47 • My Fedora 43 experience (but will be brief) (by Kevin Alexander on 2025-11-11 14:42:03 GMT from United States)
I tried Fedora 43 after it came out but I chose the Fedora Everything iso. I have come to do this with Fedora and its last couple versions for the last few times I've installed and tried it out. With Fedora 43 Everything, there is NO new installer. It still installed with Anaconda (which was fine by me). I have installed Fedora enough times I breeze through Anaconda quite fast including customizing my petitions. So I personally do not mind Anaconda at all. Plus the Everything ISO really allows the maximum software customizing in my opinion, regardless of desktop. Now, lastly one thing that keeps me from sticking with Fedora is that ever since Fedora 42, the program Dnfdragora behaves differently. Specifically, it requires wildcard (i.e. the * symbol) in the front or behind a package name if you don't know the exact wording for a package but at least know some or most of just any of the keywords. It used to be I could just type "Libre" and it would list everything with those letters in its software name. If you do that since version 42, it will return no results. Thus you instead must type the wildcard * so Libre* will then list all the results. And the same for knowing the back half of the title and needing to put the * in the front of the partial or only word you know of the software for it to list it. Never before did you have to do this and Dnfdragora was and can be a great GUI for software, instead of Discover. So I just end up abandoning it and prefer openSUSE nowadays. And even openSUSE has the new Merlyn software GUI and it is just as good as YaST Software so that's good of them to retain that user friendly element. Thank you and have a great day.
48 • @42 Rust and APT (by Eric on 2025-11-11 16:07:41 GMT from Germany)
> As others have mentioned, six months is a pretty short window for, what, 60,000 packages in the Debian repos?
These 60000 packages are unaffected by the upcoming changes. The issue lies in availability of the Rust toolchain for obsolete hardware architectures.
> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.
I agree with this APT developer, but these parts seem not to be particularly performance-critical. They could be rewritten in Python without all this controversy.
> OpenBSD source code, which has been fuzzed, analyzed, tested, attacked, and refined for 30 years. I have more confidence in the safety of that code than almost any other, regardless of language
I agree, but have a look at https://security-tracker.debian.org/tracker/CVE-2024-6387. There is no strong guarantee unless formal verification methods are used.
49 • @44 APT and Dpkg (by Eric on 2025-11-11 16:17:43 GMT from Sweden)
> Apt and its parent Dpkg have been around for 25-30 years. I cannot understand this constant need for active development of software that has become stable and useful: if obscure bugs are discovered, they can be fixed.
I would appreciate if Debian dropped them in favour of Guix or something conceptually similar but I'm afraid that this is not going to happen in the next 30 years.
50 • Rust and APT (by Eric on 2025-11-11 19:06:36 GMT from Sweden)
By the way, Fedora adopted Rust-based GPG parsing in RPM over 2 years ago, in version 38.
51 • It's Impossible (by MattE on 2025-11-11 19:10:10 GMT from United States)
With 40,000,000 lines of code, bug free is statistically impractical. Sorting through all the possible bugs would more than a million year code freeze. Just like with modern CPUs with over 5 billion transistors, it is practically impossible to check every permutation. It all boils down to releasing with an acceptable level of risk.
BTW: If Bureau 121 wants to waste time hacking our little networked homes, they could do it in minutes. Be thankful we're small potatoes. Welcome to the internet.
52 • @48 OpenSSH vuln (by Keith S on 2025-11-11 19:15:06 GMT from United States)
Yes, that was potentially a dangerous vulnerability, but it did not affect OpenBSD (or Windows for that matter). It was a problem on Linux systems because of their implementation of OpenSSH. No code is perfect, but knowing that does not seem to create a real sense of caution leasing to sane (but possibly inconvenient) defaults in the Linux world.
53 • Fedora and poll (by Bobbie Sellers on 2025-11-11 19:25:12 GMT from United States)
Fedora is not my favorite distribution by any means.
There wes no choice in the voting that reflected my choice.
From the review I see many reasons to maintain my distance.
I looked at Fedora when I was starting out and it did not have ready
access to the tools i need to get on line then. I tried out a lot of
other distributions.
On the advice of a friend 20 years ago I took up with Mandriva the successor to
Mandrake and stuck with it until it would not run on my computer of the time. No
useful advice online for a user who paid for the distribution.
Then I looked for an acceptable fork and found it.
I do not care for systemd nor for Wayland which is adopted before it is
capable of replacing all the functions of X. I would hate to use a
distribution which made it the mandatory default.
bliss- Dell Precision 7730- PCLOS 2025.10 Linux 6.12.57-pclos1- KDE Plasma 6.5.2
54 • Rust (by Keith S on 2025-11-11 19:49:28 GMT from United States)
I promise this will be my last comment on the subject this week: if Rust is the cure-all for memory safety, and that is what drives the failed effort to include Rust in the kernel and now the rewriting of APT and coreutils and other key bits of the Linux infrastructure, why is there no discussion of rewriting systemd in Rust? As Dan G and Carl and picamanic have already pointed out above, there are probably better alternatives to Rust for rewriting APT, and doing so seems like a waste of effort and resources. Why not deal with systemd first, since it is written entirely in C and touches so many different parts of the system?
55 • Rust (by Jesse on 2025-11-11 20:06:08 GMT from Canada)
@54: " Why not deal with systemd first, since it is written entirely in C and touches so many different parts of the system?"
This shows a common misunderstanding of how open source development works, as opposed to commercial software development.
There is no central authority determining which projects are worthy or have priority. There is no one who decides what to "deal with" first.
Work doesn't get done, projects don't get rewritten, based on what makes sense from a big picture perspective. That's not a thing in open source - it doesn't exist.
Each project (the kernel, APT, systemd, etc) each has it own, separate, independent development team. Those individual developers decide what they want to work on and when and in what language.
If no one in the systemd project wants to write their code in Rust, then systemd will not be written in Rust. If one of the developers of APT wants to write in Rust, then their project will be written in Rust. (Or parts of it will.)
None of these projects answers to a central authority which determines which components will use which languages.
56 • which Fedora (by IPCop son on 2025-11-11 22:16:01 GMT from United Kingdom)
Fedora Security Lab is improving - it has SElinux running OTB in live mode (via ventoy) to stop pesky intruders. Nice to see, since most security distros want you to install before all security software is working.
57 • reboot required on Debian (by Cranky on 2025-11-12 17:48:40 GMT from Canada)
for those that may not know, on Debian if a reboot is required after an update, a file called reboot-required will appear magically in /run (or look in symlinked /var/run).
58 • reboot after update? (by David on 2025-11-13 01:23:19 GMT from United States)
Yes, Debian (Gnome) says "Reboot and Update" or words to that effect.
Siduction suggests/requires dropping out of init 5 (GUI) to update.
Fedora has a CLI alternative: dnf update. No reboot is required. But if the GUI update method is used, then the user will be prompted to reboot.
All of these situations suggest to me that there is some reason that a reboot is prudent even if it is not required.
59 • Reboot (by Jese on 2025-11-13 01:28:49 GMT from Canada)
@58: "Yes, Debian (Gnome) says "Reboot and Update" or words to that effect."
That's because GNOME is following Fedora's approach. If you use any other package manager (graphical or command line) on Debian it will not suggest a reboot.
"Siduction suggests/requires dropping out of init 5 (GUI) to update."
This has nothing to do with rebooting. Switching from runlevel 5 to runlevel 3 switches from desktop mode to command line. It prevents graphical libraries/desktop components from running into conflicts during the update. You can switch back to runlevel 5 after the update without a reboot.
"ll of these situations suggest to me that there is some reason that a reboot is prudent even if it is not required."
It is neither prudent or required.
60 • Which flavor of Fedora is my favorite? (by Fedora? Fed-d-d-d-d-d-deported on 2025-11-14 04:13:27 GMT from United States)
Springdale Linux? Miracle Linux? Qubes OS? OK, definitely not Qubes anymore since... "the incident". LOL.
61 • Which flavor of Fedora is my favorite? (by Broderick on 2025-11-14 13:43:57 GMT from Italy)
I use Fedora LXDE spin: less is better. X11 works well (for now).
62 • favourite fedora version (by rhtoras on 2025-11-14 15:54:25 GMT from Greece)
Well NONE. Ask poettering... he knows...
63 • Rebooting after updates (by Eric on 2025-11-14 16:20:46 GMT from Sweden)
https://freedesktop.org/wiki/Software/systemd/SystemUpdates/ - this change was introduced in Fedora 18 in 2013: https://fedoraproject.org/wiki/Releases/18/FeatureList.
64 • Rebooting after updates (by Eric on 2025-11-14 16:56:10 GMT from United States)
The proposed rationale and discussion: https://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/.
65 • @62 (by Keith S on 2025-11-14 17:31:36 GMT from United States)
Poettering is now at Microsoft, so he can know a lot more about us than which Fedora we prefer.
66 • Reboot after updates (by Eric on 2025-11-14 18:03:44 GMT from Sweden)
According to https://docs.fedoraproject.org/en-US/kde/offlineupdates/, it is possible to disable this behaviour in KDE System Settings.
67 • Benevloent Dictators for Life (BDFLs) (by Carl on 2025-11-14 21:21:06 GMT from United States)
This term emerged as open source slang. BDFLs exercise veto powers at minimum. Other projects have governance boards, plebiscites, etc. So, devs don't do what they want in all cases.
DW discussions need not influence developers. Articles and comments carry their own value. I learn from experiences, opinions, and distro evals. That said, DW may inspire some not yet developing to start or join projects.
Debian markets itself as stable. The apt rewrite I learned from DW. The value to me is knowing not to use Debian for some years. Rust is a systems language like C, more suited for kernel code. I expect apt-next will take 2-4 years to stabilize, as early systemd did.
Number of Comments: 67
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.
|
| *NEW* NovaCustom |
NovaCustom PrivacyGuard Laptops - Escape from Big Tech
The NovaCustom PrivacyGuard Laptop is ideal for anyone who prioritizes privacy. Comes with Dasharo coreboot open source firmware and Zorin OS Pro, free from influence of Big Tech.
|
| Archives |
| • Issue 1173 (2026-05-18): Sylve on FreeBSD, the benefit of BleachBit, Debian commits to reproducible builds, Debian publishes updated install media, Haiku introduces SMP support on ARM64 processors, Rocky Linux creates opt-in security repository, Fedora reconsiders AI tools, KDE receives generous donation |
| • Issue 1172 (2026-05-11): Fedora 44, dealing with extra fonts, Fedora plans to provide AI tools, problems with Ubuntu's new coreutils, TrueNAS extends its development cycle, postmarktetOS improves the boot splash screen, Redox ports tmux |
| • Issue 1171 (2026-05-04): Xubuntu 26.04, extending memory with VRAM, Ubuntu plans AI features, Devuan developer forks GTK2, Mint introduces hardware enablement builds, Linux running on a PlayStation 5, local kernel exploit found in Linux |
| • Issue 1170 (2026-04-27): ENux 5.2.1, picking a second distro, AlmaLinux expands CPU support, FreeBSD publishes Status Report, Ubuntu MATE skips 26.04 release |
| • Issue 1169 (2026-04-20): Lakka 6.1, free software and source-based distributions, FreeBSD Foundation publishes compatible laptop list, Debian holds Project Leader election, Haiku progresses ARM64 port, Mint to extend development cycle, Linux 7.0 released |
| • Issue 1168 (2026-04-13): pearOS 2026.03, EndeavourOS 2026.03.06, which distros are adopting age verification, Arch adjusts its firewall packages, Linux dropping i486 support, Red Hat extends its release cycle, Debian's APT introduces rollbacks, Redox improves its scheduler |
| • Issue 1167 (2026-04-06): Origami Linux 2026.03, answering questions for Linux newcomers, Ubuntu MATE seeking new contributors, Ubuntu software centre is expanding Deb support, FreeBSD fixes forum exploit, openSUSE 15 Leap nears its end of life |
| • Issue 1166 (2026-03-30): NetBSD jails, publishing software for Linux, Ubuntu joins Rust Foundation, Canonical plans to trim GRUB features, Peppermint works on new utilities, PINE64 shows off open hardware capabilities |
| • Issue 1165 (2026-03-23): Argent Linux 1.5.3, disk space required by Linux, Manjaro team goes on strike, AlmaLinux improves NVIDIA driver support and builds RISC-V packages, systemd introduces age tracking |
| • Issue 1164 (2026-03-16): d77void, age verification laws and Linux, SUSE may be for sale, TrueNAS takes its build system private, Debian publishes updated Trixie media, MidnightBSD and System76 respond to age verification laws |
| • Issue 1163 (2026-03-09): KaOS 2026.02, TinyCore 17.0, NuTyX 26.02.2, Would one big collection of packages help?, Guix offers 64-bit Hurd options, Linux communities discuss age delcaration laws, Mint unveils new screensaver for Cinnamon, Redox ports new COSMIC features |
| • Issue 1162 (2026-03-02): AerynOS 2026.01, anti-virus and firewall tools, Manjaro fixes website certificate, Ubuntu splits firmware package, jails for NetBSD, extended support for some Linux kernel releases, Murena creating a map app |
| • Issue 1161 (2026-02-23): The Guix package manager, quick Q&As, Gentoo migrating its mirrors, Fedora considers more informative kernel panic screens, GhostBSD testing alternative X11 implementation, Asahi makes progress with Apple M3, NetBSD userland ported, FreeBSD improves web-based system management |
| • Issue 1160 (2026-02-16): Noid and AgarimOS, command line tips, KDE Linux introduces delta updates, Redox OS hits development milestone, Linux Mint develops a desktop-neutral account manager, sudo developer seeks sponsorship |
| • 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 |
| • 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 | 
MiniOS
MiniOS is a Debian-based Linux distribution which strives to be lightweight, modular, versatile and customisable. It comes in three editions, "Standard", "Toolbox" and "Ultra". MiniOS "Standard" is a compact system designed for everyday computing tasks, while "Toolbox" is designed for maintenance, diagnostics and recovery of computer systems; it provides a rich set of graphical and console tools for working with disks and partitions, network diagnostics and administration, data security, data and password recovery, hardware fault diagnosis and testing, as well as other utilities. Finally, the "Ultra" variant of MiniOS provides an extensive set of software tools designed both for maintenance and diagnostics of computer systems and for solving a wide range of general office tasks.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
