This is a long overdue, insignificant post on some wanderings I had while exploring some other distros based on Debian or Ubuntu. International events have delayed its writing.

It all started from “my little old Jap”

I know that “Jap” is considered “disparaging and offensive” in the US, and it might be the same in Japan, but this is only because of how this abbreviation has been used in the past by Americans. Per se, I can’t see why it can’t be a rather affectionate term. People are brain-damaged in their approach to words.

Either way, I made a reference to Gokuraku Haze in a post from Sept. 2021, when I posted two tables in which this guy compared the RAM usage of several distros: right after booting, then with Chrome launched (for some reason, Firefox is not to his taste). This Japanese tests all kinds of distros on some very old laptops, so bloatedness is something he can’t possibly appreciate. He generally prefers LXDE, but he also tries XFCE, LXQt. Back then, he found Kubuntu 21.04 to be less demanding in RAM than Linux Mint 20.2 XFCE!

Given that he always uses laptops for his tests, I can’t understand his preference for LXDE. OK, Debian 11 LXDE only needed 238 MB of RAM, I got this. And that’s because the “official” LXDE is still based on GTK2. The last time I checked (years ago), the GTK3-based LXDE was “almost ready” and fully functional, save for a couple of apps or plugins or something. But I can understand the preference for GTK2.

And yet, LXDE has a major flaw: it completely disregards the Fn brightness keys. In contrast, LXQt doubles down: it acts on the Fn brightness keys, and it even includes a GUI utility, lxqt-config-brightness (part of lxqt-config). Similarly, XFCE includes a brightness slider (which properly adjusts the backlight) in a panel plugin belonging to xfce4-power-manager.

Wait, XFCE actually duplicates this functionality, but I forgot to mention this in my post about “being stranded in MX Linux”! It has two different applets that can be used to adjust the backlight (what we call “brightness”):

  1. Once you enable “System tray icon” in the settings for the Power Manager (xfce4-power-magager-settings), another icon shows up on the panel. Right-click to adjust.
  2. The Power Manager Plugin (org.xfce.powermanager) that you need to manually add to the panel. Click to adjust.

Back to LXDE, there is zero support for brightness adjustment! Of course, some older laptops (including some ThinkPads, some HPs, and some ASUS models) expose brightness control through ACPI events that LXDE doesn’t need to manage because, in these rare cases, Fn keys work at the kernel level. Do our Japanese’s laptops fall into this category, or are their screens so dim that he likes them at 100%, which should be the default unless adjusted through software?

Revisiting Gokuraku Haze

As a side note, this guy constantly keeps his readers updated with the vagaries of his health, all related to a prostate cancer, its treatment, and side effects of the treatment. He’s been struggling with this rebellious cancer for more than 2 and a half years. This is why I added “old” to the previous subtitle: one can’t usually have prostate cancer at 40 years!

Here’s a list of the quick reviews he made on a number of distros in the last ~6 months. Use the automatic translation that your browser should be able to perform out-of-the-box if it’s Chrome-based; in Firefox, I use the TWP add-on. Tip: Open the screenshots you want to see in more detail in a new tab, then remove the resizing at the end of the URL: ?caw=800 (why do I need to state the obvious?)

Each review ends with a table with the RAM usage of the respective distro, followed by the corresponding values for other distros recently installed by him. In theory, I should have been able to only use the most recent table, supplemented by an older one for the distros that have “fallen off” the most recent table. Unfortunately, this guy is surprisingly messy for a Japanese, and he keeps removing or moving around lines in such tables, so I decided to include them all, because I cannot sort out the mess!

Curt comments on some of the above reviews.

● Kona Linux is a Japanese distro of no interest to the rest of the world. He tested its LXDE edition, but other editions are available: Cinnamon, GNOME, KDE, MATE, XFCE.

The live session was able to mount my (currently MX) installed /home partition to save screenshots. I never test a distro in a virtual machine, because I need to know how it behaves on real hardware, on “bare metal”!

● Basix is another Japanese distro based on Debian 13. I couldn’t understand why he chose to install version 4.0 when version 7.0 was available!

It’s one of those distros that, in their live session, are unable or unwilling to mount partitions from an installed Linux distro.

● In his review of Debian 13 netinstall, he first installed LXDE, then XFCE. However, no RAM measurements for XFCE!

Then, he shows GRUB Customizer, but it’s not clear that he used it (I guess he didn’t). Note what I wrote while discussing MX:

grub-customizer was removed in Ubuntu 22.04, and it never came back in Ubuntu.

Debian, despite Bug 1010165, has not decided to remove it from the repos, but it’s most likely dangerous.

● Lubuntu 25.10: He installed LXDE because he didn’t like LXQt! A surprise was waiting for him, though:

● Zorin OS and LMDE7 are rather bad choices:

● MX Linux 25 gave him installation issues twice, not once! Well, I said that “plain” Debian is less buggy, didn’t I? I also said that GRUB2 is an abomination. People are too focused on systemd to realize that GRUB is a complete mess.

● natureOS is another Japanese distro. Being Basix-based makes it Debian-based. It uses XFCE. Once again, why did he install version 1.0 instead of version 7.0?

Just like Basix, the live session refused to mount my installed /home partition.

● Q4OS-6.4-Trinity: He also tested, from XPQ4 – Windows look’n feel for Q4OS desktop, Free10 and FreeXP.

I’m not tempted by any of them! When I was using WinXP, I always configured it to have that Win95/98/2k look, because XP’s default theming was designed for kids. Then, Trinity being KDE3, I suppose it cannot integrate anything more “modern” into its system tray, and I would also need to use a more capable file manager and more powerful accessories, too, and they would all pull dependencies. So what’s the purpose of Trinity?

🇯🇵 Either way, I take it that Debian is huge in Japan, and they prefer Debian derivatives to Ubuntu derivatives! Cool.

More wanderings

❶ I also tried a Chinese distro, GXDE-OS 25.3.

GXDE OS (DistroWatch) is a Debian-based distro supposed to offer a Deepin Desktop Environment (DDE) that looks slightly different from the one distributed by the deepin distro (DistroWatch). But the most interesting part is that GXDE OS 25 is based on Debian 13, whereas deepin 25 is based on Debian 12!

Unfortunately, I didn’t save any screenshots, because there’s no point in a distro that uses a desktop environment whose file manager, Deepin File Manager (dde-file-manager), is mimicking the worst file manager in history, GNOME’s Files, and therefore only has two views: icons and detailed file list.

The file manager aside, GXDE isn’t that bad. You can find screenshots on the official website, in this review from 2024 of the older version 15 (the original in Spanish), and probably elsewhere as well.

Downloading GXDE-OS_25.3_amd64.iso is painfully slow from outside China. Note that SourceForge only has version 25.2.1 at the time of writing, not 25.3. You might want to read about the code names if you’re really interested in this distro.

This distro includes a GUI (but also a CLI utility) for the so-called Spark Store, which can only interest people from China.

The language-agnostic apps offered by Spark are repackaged upstream packages such as Blender, GIMP, Inkscape, Lutris, Steam, VSCodium, Docker Desktop, etc. There are also “bottles” with Notepad++, 7-Zip, Everything (by voidtools), MS Office 2016 Viewer, Adobe Photoshop CS6.

Spark also offers Chinese commercial apps with geo-block or license-forbid redistribution (WeChat Win32, TIM, QQ, Baidu NetDisk, Youdao, etc.) and vendor blobs that ship as .spk because they are technically illegal to redistribute in the West (MTK SP-Flash-Tool-v5, Qualcomm QFIL-lite and QCN + QPST libraries, Xiaomi anti-rollback bundles, Huawei HiSuite proxy-loader, Broadcom BCM GPS almanac injector, Lenovo BIOS, Dell PFS Extractor, ASUS WinFlash split-tool, Dolby Atmos UWP runtime, Sony DSEE HX™ plug-in, DTS Headphone:X).

Some other gray-area blobs in Spark: Altium CircuitMaker (free, but Altium no longer provides download links), Autodesk EAGLE 9.6 (the last non-subscription build), Mentor Graphics PADS Viewer.

I expect Chinese users from the PRC to be mostly split between deepin, GXDE OS, and openKylin.

❷ Linux Lite 7.8-rc1 was another distro I explored. I found it as buggy as always! The only improvement is that Chrome actually works in the live session.

The “Welcome” app cannot be themed in dark:

Mousepad still has white line numbers on a white background when the theme is dark. Really, Jerry Bezencon, WTF are you doing there, you retard? This is such an old bug!

Somewhat similarly to MX, albeit much more limited, Lite has two places where one can find its sets of utilities (they might be rewritten in Python for 8.0): one is in Lite Tweaks…

…and the other one is in XFCE’s Settings, to which a few additions have been made…

…such as this completely useless Lite Desktop, whose only original contribution consists of three links: This PC, Networks, and Linux Lite Wiki. The others can be configured by XFCE via right-click, Desktop Settings…, File/Launcher Icons (tab moved outside Desktop Icons in XFCE 4.20).

The live session can’t mount my installed /home partition.

I see no reason why anyone would want to use Linux Lite.

❸ Xebian was the last distro I tried. DistroWatch claims that it’s «based on Debian’s “Unstable” branch,» but this is not always true. While the direct download link offers xebian-unstable-amd64.hybrid.iso, should you take a look into the “pending” folder, you’ll find this:

Cool, eh? And they seem to be periodically updated. I have downloaded ISO files dated Dec. 29, but currently the ISO based on Debian 13 “Trixie” has been updated to Jan. 5!

As a side note, both use “unmodernized” repo files, and the stable one has the backports enabled:

Now, here’s the unexpected bonus with Xebian: while they state that “The goal of this project is to make an Xfce Debian based system that is much like Xubuntu,” in practice that means that their layout lacks the dock that comes by default in most XFCE-based distro. Therefore, if you move the panel from top to bottom, you get the traditional Win95/98/2k metaphor with everything on a single panel, including icons with text for the open windows! ✌️

If you also consider the modest size of the ISO, you might choose Xebian (in its “Trixie” version) as possibly the best way to install a bloat-free XFCE Debian! 🏆

These are all the GUI apps preinstalled in Xebian, including everything that’s in XFCE Settings Manager:

Not bad, and not bloated. Note that KDE System Settings is useful to theme Qt-based apps. MX doesn’t install it!

If I ever install Debian XFCE again, I won’t choose MX, not even the unofficial MX 25 XFCE “non-free” respin, because MX’s tools are themselves bloatware, and they introduce new bugs! Xebian FTW! 🎉

Bonus knowledge regarding Ventoy

When you boot a Linux distro from an ISO on a Ventoy stick, there are always 2 options: “In normal mode” and “In GRUB2 mode.” Most distros work in normal mode, despite everything always being GRUB2! But a few only boot in GRUB2 mode. What’s Ventoy actually doing differently?

Well, in brief:

  1. “In normal mode,” Ventoy boots the ISO without using its GRUB. Ventoy reads the ISO’s boot structure and launches the kernel itself.
  2. “In GRUB2 mode,” Ventoy chainloads the ISO’s own GRUB. In theory, this is a fallback mode for problematic ISOs. It literally boots the ISO’s own GRUB2 directly.

While most distros boot “in normal mode,” I find it illogical for this mode to be the default one. Why not trust an ISO’s own GRUB?

Here’s what Claude answered:

Claude: You’ve touched on a really interesting design decision! The logic behind making “normal mode” the default actually makes a lot of sense once you consider what Ventoy is trying to accomplish.

Why “normal mode” is the default:

  1. Speed and efficiency – Direct kernel boot is significantly faster. Chainloading GRUB2 adds an extra boot stage, which means more time staring at boot screens. For most ISOs, this extra step is unnecessary overhead.
  2. Consistency across ISOs – In normal mode, Ventoy provides a unified boot experience. You’re using Ventoy’s boot logic for everything, which means fewer variables and more predictable behavior. In GRUB2 mode, you’re at the mercy of however each distro configured their GRUB, which can vary wildly.
  3. Less complexity – Chainloading GRUB introduces another layer where things can go wrong. The ISO’s GRUB might not expect to be booted from a USB stick, might have hardcoded paths, or might make assumptions about the boot environment that don’t hold true in Ventoy’s context.
  4. Feature compatibility – Ventoy has special features (persistence, encryption, menu customization) that integrate better when it maintains control of the boot process. Handing off to the ISO’s GRUB can break these features.

When do ISOs actually need GRUB2 mode?

Usually when they have unusual boot configurations, custom GRUB modules, or boot scripts that expect specific GRUB environment variables. Some distros also use GRUB as part of their installation process verification.

So while it might seem more “pure” to always use the ISO’s own bootloader, Ventoy’s approach is pragmatic: use the faster, more reliable method by default, and keep chainloading as a compatibility fallback.

Me: You said, “use the faster, more reliable method by default.” But being one second faster is irrelevant. As for “more reliable,” it’s quite the contrary: the most reliable method is to use the original GRUB, specially crafted for the respective ISO!

Claude: You’re absolutely right to push back on that – I was being too glib about “reliability.”

You make a compelling point: the ISO’s GRUB was specifically configured and tested by the distro maintainers for that exact ISO. It should, in theory, be the most reliable option since it’s the canonical boot path.

The counterargument would be that Ventoy’s “normal mode” has proven reliable in practice for the vast majority of ISOs – it’s been battle-tested across thousands of distros and edge cases. But you’re correct that this is empirical reliability rather than guaranteed reliability. When an ISO does fail in normal mode, it’s often because Ventoy’s boot logic made incorrect assumptions about the ISO’s structure.

So why is normal mode still default? I think the real reasons are more prosaic:

  1. It works for most ISOs – probably 90%+ of common distros boot fine this way, so it minimizes the need for users to understand the distinction
  2. Ventoy features – as I mentioned, some of Ventoy’s own features (like persistence) integrate better when it controls the boot process
  3. Historical momentum – Ventoy established this as default early on, and changing defaults breaks user expectations

But your fundamental point stands: there’s something philosophically backwards about a tool that boots ISOs not defaulting to the boot method the ISO creators intended. It’s pragmatic, but you’re right that it’s arguably illogical.

Persistence might be the only compelling argument, but I never bothered to learn how to use it with Ventoy because I assumed it’s Ventoy-specific. The persistence I was used to required an entire flash drive to be dedicated to a distro. And I never used that one either!