What have you found bad about bash arrays? I have some simple usage of those (in bash) and they work fine.
Linux, C, DOS, Vim, networking. he/him
What have you found bad about bash arrays? I have some simple usage of those (in bash) and they work fine.
No worries! I hope this helps you enjoy Flatpak :)
You added the Flatpak repo as a “system” repo with:
flatpak remote-add flathub https://dl.flathub.org/repo/flathub.flatpakrepo
As such, the downloaded applications are stored by the system in /var
like you said.
If you run installs as user installs, eg:
flatpak --user install com.example.appname
Then the application is stored in your home directory, not in /var
.
You can also add the Flatpak repo as a “user” repo, eg:
flatpak --user remote-add flathub https://dl.flathub.org/repo/flathub.flatpakrepo
Now all installs will behave as if you passed --user
to the install command. All installs will go to your home directory, none will go to /var
The installer lets you do a custom partition layout.
It’s fine. I give my systems a 20G or 30G root file system.
If you use Flatpak then make sure you do user installs. If you add the remote as a user remote then all installs are user installs.
If you use VMs then create a storage pool for the disks in your home filesystem. I create a /home/libvirt/
for this.
Basically just be mindful not to fill your root filesystem.
I love XFCE but I use MATE’s Caja file manager on mine.
Yes. All Flatpak apps can be used on any distro.
I’m using the Fedora Flatpak Firefox on Debian, because Fedora’s Flatpak runtime supports Kerberos authentication, the Flathub runtime doesn’t.
No. Neither Intel or AMD provide microcode which meets Debian’s definition of “free” so CPU microcode is non-free:
https://wiki.debian.org/Microcode
You might consider that your CPU is already running non-free microcode provided by your non-free motherboard BIOS.
If you have one of these CPUs, it’s literally impossible for you not to run some non-free components.
All you’re doing is exposing yourself to vulnerabilities in old microcode.
It means 6.4.4.
The 0 can be ignored, so you can think of this as “linux-image-6.4” then if you want the actual revision you look after the arch and see “6.4.4”.
This is explained in the Debian kernel handbook:
https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-versions.html
For compatibility, the official kernel packages currently add ‘.0’ to the upstream version.
Every Flatpak vendor
So who’s that? Flathub and Fedora, the latter of who automate the Flatpak builds from distro packages anyway.
If you’re using a smaller distro which is not backed by a huge security team then this is probably an advantage of using Flatpak, not a negative.
aiui apt will compare downloads from repositories against the repository signing key, whereas downloading a deb and installing it manually with dpkg bypasses that.
So theoretically the Debian website could get compromised and provide you a malicious deb package. That has happened to other Linux distros before so it’s not entirely unrealistic.
Practically I think that’s very unlikely.
I know apt has the --download
option if you’d like to fetch deb packages on the commandline, though I’m not sure if apt compares the package with the key during this process. I hope it does. You could probably run apt in verbose mode and hopefully see this happen.
Some references:
The live installer sucks.
It is called Calamares, it is not well maintained upstream, and it doesn’t support even trivial complexity like LVM or Encryption.
Use the regular install DVD or Netinst. You get to choose your desktop environment in the process.
Make one with a bunch of arcade buttons and an RP2040 running the GP2040 firmware:
However, having done this, you will learn NOT to cheap out on buttons. Cheap Chinese clone buttons absolutely suck. Once you buy a set of proper arcade buttons or keyboard switches, plus a bit of wire, you’ll have spent as much as the 8BitDo stick costs anyway.
What you wish for is how I use make. Off the top of my head, something like this:
EXEC = programname
SOURCES = $(wildcard *.c)
OBJECTS = $(SOURCES:.c=.o)
all: $(EXEC)
$(EXEC): $(OBJECTS)
%.o: %.c %.h
.PHONY: all clean
clean:
rm -f $(EXEC) $(OBJECTS)
Then just run make
and it compiles and links all .c
files into the executable. Each .c
file needs a .h
with the same name. Remove the .h
if you don’t like that requirement.
From memory you might need a .c
and .h
file with the same name as the executable.
I have the same opinion about MS-DOS. If you need more controls than A B Start Select then DOS gives you a full keyboard and mouse support, plus reasonably useful resolution like 640x480.
You can emulate DOS on any computer platform, including the web so people can use software in-browser with no effort. There are even DOS emulations on 100MHz+ microcontrollers like ESP32.
There are pre-made DOS cross-compilers for C so you don’t need to learn assembly like you might with NES: https://github.com/andrewwutw/build-djgpp
I’ve been playing with 86Box lately to setup Windows 95 to play some old games.
Win95 has a bug where it doesn’t run on fast CPUs, so using one of the original CD images in a VM like KVM is not possible.
(I later found https://github.com/JHRobotics/patcher9x which you can use to patch the install images)
I tried Bochs but it was impossible to use, it drops to a text debugger and wants you to connect over VNC which isn’t what I wanted anyway. PCem lost a lot of momentum after going unmaintained, and there is no Linux binary.
86Box has both AppImage and Flatpak, and comes with a nice configuration GUI. It’s easy to use and works well for what I want to do.
I like how it seems to properly emulate the BIOS and specific devices, so you can use the actual original drivers too.
I gave Tangram and Ferdium a look but the rendering engine they use is awful and makes my eyes hurt. Old Chrome/Chromium used to have the same problem years ago. I’ll stick to Librewolf pinned tabs.
I keep watching reviews of devices like Retroid and Anbernic, I still think the Vita is a better experience.
Use an open source 2FA which lets you export
You can store your recovery codes as files in KeepassXC
If you run your scripts through https://shellcheck.net it’ll pick up things like this. Also available as a Linux package for offline use.