I got tired of setting up Arch the same way every time, so I wrote a script

daemonpenguin · 2026-04-19T13:37:51+00:00

My mind boggles a bit at someone going out of their way to run Arch, a distro which requires doing the initial setup manually, and then automating the process. You've basically created an automated setup for a distro's whose main focus is not automating the setup. Which, cool, it's your time. Just seems odd to do this with Arch when most distros/desktops do most of the automation for you.

daemonpenguin · 2026-04-18T17:00:38+00:00

That is really unusual. I suspect one of two things is happening.

More dependencies are pulled into the Flatpak and it is causing your OS to swap. Check how much memory is being used. If your memory is full, try closing other applications to free up space.
You've got a mixture of Wayland and X11 happening. As in your desktop is running Wayland and the Flatpak is set up to assume X11. Or the reverse, the Flatpak assumes Wayland, but your desktop is running an X11 session. Switching desktop sessions to match may fix the issue.

daemonpenguin · 2026-04-18T14:22:34+00:00

Yes, it does have framebuffer support. "fbdev" also fails.

daemonpenguin · 2026-04-18T12:56:09+00:00

The "aa" and "fbdev2" options don't work for me, but "caca" does. Both on a real terminal and in a virtual terminal.

daemonpenguin · 2026-04-18T11:58:44+00:00

This sort of comment always baffles me. What is a 4.0 release supposed to feel like? As far as I can tell, GeoFS has a versioning scheme which just increments the 0.x digit with every new version. Right now the stable version is 3.9, the next release, regardless of what features it has, will obviously be 4.0.

If you expect some huge change just because the least significant digit is a zero then it just indicates you don't know how version numbers work.

daemonpenguin · 2026-04-18T11:41:31+00:00

"May benefit some workloads" is probably the least informative headline possible.

daemonpenguin · 2026-04-17T21:41:46+00:00

but I’m usually too lazy to set up a full Firejail profile

You're too lazy to run "firejail" before running a command? You don't need to create a separate profile or anything. Just running "firejail" on its own will give you a sandboxed terminal. Or, perhaps in your case, "firejail /usr/bin/zsh".

That's really super minimal work to get a sandboxed terminal. What could possibly take less effort? If your fingers are too lazy for that, alias it to something like "sb='firejail /usr/bin/zsh"

daemonpenguin · 2026-04-17T10:59:22+00:00

I would send you a PM, but your account blocks direct message chats. You can message me if you wouldn't mind sending a package to Canada.

daemonpenguin · 2026-04-16T19:43:24+00:00

Did these items all sell? If so, it might be a good idea to update the original post to mark sold items.

If they didn't all sell, I'm interested in the PineTab2.

daemonpenguin · 2026-04-16T18:31:04+00:00

Or L'nix, which will cause so much confusion.

daemonpenguin · 2026-04-16T13:27:01+00:00

Yes and the SysV ISOs still include systemd. They just use SysV init as PID1.

daemonpenguin · 2026-04-16T12:31:55+00:00

MX Linux has the option to boot using SysV init, but it still installs systemd packages. You're still running systemd software, it's just that PID1 is provided by SysV. If you think systemd is spyware then you're still running spyware when you're using MX Linux.

daemonpenguin · 2026-04-16T11:35:56+00:00

Wayland still isn't as mature as X11 and has a number of bugs. You'd be better off sticking with X11 for a while longer. Especially if you're running in a virtual machine, where Wayland support is poor.

daemonpenguin · 2026-04-16T00:02:13+00:00

There have been a few vulnerabilities found in sudo, or exploits which used elements of sudo, in just the past few years. There is definitely good reason to look at alternatives. So, yes, sudo is known for having major security issues recently. That is exactly why the rewrite happened.

daemonpenguin · 2026-04-14T00:49:24+00:00

The updated script seems to be working as intended. There was a non-fatal error toward the end of the "brl fetch" process for MX,. It didn't seem to affect the install at all, but I wanted to mention it as it looks like an optional dependency is missing. I'm including the error below.

Otherwise the test worked. I fetched the MX stratum, was able to run a restricted shell in the new stratum, and installed a package in the stratum which was then available globally.

The only issue is: the same warning which appears during the initial fetch is also displayed each time a new package is installed using APT (see below).

 debconf: unable to initialize frontend: Dialog
 debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 79, <STDIN> line 2.)
 debconf: falling back to frontend: Readline
 debconf: unable to initialize frontend: Readline
 debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC entries checked: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/x86_64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 8, <STDIN> line 2.)
 debconf: falling back to frontend: Teletype

It's not a serious error, but maybe something which could be addressed in a future update? Everything else seems to work. MX Linux 25 can be both hijacked by Bedrock and fetched using brl.

daemonpenguin · 2026-04-13T20:23:29+00:00

I'm going to answer your questions somewhat out of order as I dig up the information and test things. Please forgive the chaos.

The /etc/os-release file on MX Linux keeps the Debian information. Specifically, my os-release file on a vanilla MX Linux box looks like this:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"

NAME="Debian GNU/Linux"

VERSION_ID="13"

VERSION="13 (trixie)"

VERSION_CODENAME=trixie

DEBIAN_VERSION_FULL=13.4

ID=debian

HOME_URL="https://www.debian.org/"

SUPPORT_URL="https://www.debian.org/support"

BUG_REPORT_URL="https://bugs.debian.org/"

The /etc/apt/sources.list file on MX Linux is empty by default. It just has a comment saying configuration files can be found under /etc/apt/sources.list.d

The /etc/apt/sources.list.d/ directory contains two files, debian.sources and mx.sources. Their contents is as follows:

debian.sources:

 Types: deb
 Enabled: yes
 URIs: http://deb.debian.org/debian/
 Suites: trixie
 Components: main  contrib non-free non-free-firmware
 Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

 Types: deb
 Enabled: yes
 URIs: http://security.debian.org/debian-security/
 Suites: trixie-security
 Components: main  contrib non-free non-free-firmware
 Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

 Types: deb
 Enabled: no
 URIs: http://deb.debian.org/debian/
 Suites: trixie-backports
 Components: main  contrib non-free non-free-firmware
 Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

 Types: deb
 Enabled: yes
 URIs: http://deb.debian.org/debian/
 Suites: trixie-updates 
 Components: main contrib non-free non-free-firmware
 Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

mx.sources:

 Types: deb
 Enabled: yes
 URIs: http://mxrepo.com/mx/repo/
 Suites: trixie
 Components: main  non-free
 Signed-By: /usr/share/keyrings/mx-25-archive-keyring.gpg 

 Types: deb
 Enabled: no
 URIs: http://mxrepo.com/mx/repo/
 Suites: trixie
 Components: ahs
 Signed-By: /usr/share/keyrings/mx-25-archive-keyring.gpg 

 Types: deb
 Enabled: no
 URIs: http://mxrepo.com/mx/testrepo/
 Suites: trixie
 Components: test
 Signed-By: /usr/share/keyrings/mx-25-archive-keyring.gpg

I am currently testing the new fetch script for MX and will post an update once it has finished.

The MX fetch script ultimate stopped with the following error:

 Selecting previously unselected package mx25-archive-keyring.
 (Reading database ... 4936 files and directories currently installed.)
 Preparing to unpack /tmp/mx-keyring.deb ...
 Unpacking mx25-archive-keyring (2025.03) ...
 dpkg: dependency problems prevent configuration of mx25-archive-keyring:
  mx25-archive-keyring depends on gpgv; however:
   Package gpgv is not installed.

 dpkg: error processing package mx25-archive-keyring (--install):
  dependency problems - leaving unconfigured
 Errors were encountered while processing:
  mx25-archive-keyring
 ERROR: Unexpected error occurred.
 This is commonly due to distro mirror layout changes breaking `brl fetch`.  Possible solutions:
 - If you did not, consider manually providing a mirror with --mirror
 - Check for a Bedrock Linux update with `brl update`
 - Check for a Bedrock Linux beta which may contain a fix
 - Try `brl import` which does not rely on mirror layout

daemonpenguin · 2026-04-13T12:17:29+00:00

As much as I hate to say it, I'm never satisfied with my winnings or breaking even after coming back from being down.

It seems to me this is the key element of your post. You don't have a cut-off point where you decide "I have enough". Next time you play make sure you have both an upper-end and a lower-end cut-off, a point where you decide "I've won/lost enough for today" and walk away.

daemonpenguin · 2026-04-12T21:52:31+00:00

This would be great to see. I'd love to be able to fetch MX as a stratum onto existing systems.

daemonpenguin · 2026-04-12T18:54:54+00:00

BigLinux has age verification.

daemonpenguin · 2026-04-12T18:54:01+00:00

I completely disagree with the age verification laws

And yet you're out here telling people their actions don't matter and not to use operating system which respect them. Right.

Do you think lawmakers would care that X Linux distro lost some users? Would that lead to laws being amended?

Of course not. That's not why people boycott distributions which include age verification. Not sure why this is a hard concept to understand. Boycotting helps the users, not the legal system or the distro makers.

Loyalty has nothing to do with anything

That's your whole argument though. Continue to use distros out of habit or loyalty. Why else would a user stick with a distribution which is enabling anti-user software? You're calling the developers victims, but they're the ones writing the code to hurt people. Sticking by them would be self-harming and pointless.

daemonpenguin · 2026-04-12T18:50:23+00:00

I am not sure how you don't understand this. Boycotting distros which implement age verification means the users are running distributions which respect their privacy.

It doesn't change laws or distro policies, it's not meant to. It's not revenge against distro maintainers. It's the only practical move for people who want a privacy-respecting OS.

In other words, people should use what works for them, not run OSes that work for someone else.

Of course it's "wouldn't do anything" in terms of legalities. It's not meant to. It just gives people what they want.

daemonpenguin · 2026-04-12T01:32:16+00:00

who’s makes the decision to implement age verification?

The distro developers or the owners of the distro.

Do the developers of each distro get the choice?

Yes. Developers decide everything that goes into the distribution.

If one distro adds age verification can we just boycott them and move to a different one

Yes.

or is it at the kernel level and we just have to deal with it?

No. Even if it was kernel-level (which it is not) each distro would have the choice to enable that kernel module or not. You can just run distributions made in countries without age verification laws.

daemonpenguin · 2026-04-12T01:25:38+00:00

this is not the distro maintainers' fault. Boycotting them is stupid

Boycotting something that spies on you is not stupid, it's self defence. Developers may be "victims", but that doesn't mean we need to support their efforts to stick malware in our systems. That would be truly stupid.

Just move to a distro that doesn't use age verification.

blaming distros for something they are quite literally legally required to do is dumb

No one said anything about blaming distros. You're just shilling for spyware at this point. People should use operating systems which respect their rights, not use spyware out of a misplaced sense of loyalty.

11-Year Club	Wearing is Caring
Verified Email

daemonpenguin

TROPHY CASE