+1 to runit. So much simpler than systemd unit files.

Those security features are misleading.

A second app can already read all of your files, modify the first app, modify $PATH to replace your display server and do anything it wants as your user. Running wayland instead of Xorg provides no tangible benefits in security.

https://halestrom.net/darksleep/blog/054_nvme/

Summary: two Silicon Power P34A80’s died within a few months of use, the second one was the warranty replacement of the first. In both cases sectors suddenly became permanently unreadable.

Eat bad food, wake up with your wallet stolen.

Glad you found a fix :)

FWIW I was running “xbps-query -s gtk2” out of curoisity last night and only saw “gtk2-engines”, which I thought was odd.

A method I have not seen mentioned yet (for when you have an old precompiled version of an app):

1. Identify the missing libs. You can run the program, but sometimes it’s easier to use ldd
2. Use your web browser to download the missing libs from Debian’s repos (stable or older if need be). Unfortunately you often also have to grab their deps too.
3. Extract the .debs
4. Move all of the .so files into the same folder as the old program you are trying to run
5. export LD_LIBRARY_PATH=“$(pwd)”
6. Now try running the app

It often takes a bit of fiddling, but it’s worked for me a few times and you only need to fetch the few libraries you are missing. For bigger things however it can be a dependency hell, you might as well use the distro’s actual package manager inside a chroot.

Note: You don’t need to be using Debian as your host distro, I don’t. As long as it’s a glibc based distro you should be mostly fine (glibc is mostly backwards compatible)

I don’t know what was originally written here, but shouldn’t it now read “Could not find creator.so.5”?

My distro recently dropped support for gtk+2 (which I am fairly pissed about, since it’s the last good version of GTK+)

Stuff like this completely throws the shared libraries idea in the bin. There are lots of benefits, sure, but none of them matter when your program won’t even start.

Please name and shame your distro. GTK2 is a core component of userspace for many users, just as important as glibc and bash. Maintaining it might be annoying, but it’s the lesser of two evils.

My distro (Void Linux) dropped support for qt4 a few years back. Now I’m running QUCS in wine. “win32 is the only stable ABI in Linux”

(And yes you’re right 2 is the last good version of GTK+. Gtk3 and 4 look and feel so much worse, they make me feel like I’m being punished.)

SFF = Small Form Factor. It’s smaller than traditional ATX computers but can still take the same RAM, processors and disks. Motherboards and power supplies tend to be nonstandard however. Idle power consumptions are usually very good.

USFF = Ultra Small Form Factor. Typically a laptop chipset + CPU in a small box with an external power supply. Somewhat comparable with SBCs like Raspberry Pis. Very good idle power consumption, but less powerful than SFF (and/or louder due to smaller cooler) and often don’t have space for standard disks.

SBC = Single Board Computer.

I wouldn’t attack via USB, that path has already been too well thought out. I’d go for an interface with some sort of way to get DMA, such as:

• PCIE slots including M.2 and external thunderbolt. Some systems might support hotplug and there will surely be some autoloading device drivers that can be abused for DMA (such as a PCIE firewire card?)
• Laptop docking connectors (I can’t find a public pinout for the one on my Thinkpad, but I assume it’ll have something vulnerable/trusted like PCIE)
• Firewire (if you’re lucky, way too old to be found now)
• If you have enough funding: possibly even ones no-one has thought about like displayport + GPU + driver stack. I believe there have been some ethernet interface vulnerabilities previously (or were those just crash/DOS bugs?)

I recommend using a different set of flags so you can avoid the buffering problem @thenumbersmason@yiffit.net mentions.

This next example prevents all of your ram getting uselessly filled up during the wipe (which causes other programs to run slower whenever they need more mem, I notice my web browser lags as a result), allows the progress to actually be accurate (disk write speed instead of RAM write speed) and prevents the horrible hang at the end.

dd if=/dev/urandom of=/dev/somedisk status=progress oflag=sync bs=128M

“oflag” means output flag (to do with of=/dev/somedisk). “sync” means sync after every block. I’ve chosen 128M blocks as an arbitrary number, below a certain amount it gets slower (and potentially causes more write cycles on the individual flash cells) but 128MB should be massively more than that and perfectly safe. Bigger numbers will hog more ram to no advantage (and may return the problems we’re trying to avoid).

If it’s an SSD then I issue TRIM commands after this (“blkdiscard” command), this makes the drive look like zeroes without actually having to write the whole drive again with another dd command.

N.B. to anyone reading this: ask your isp to “opt out of CG-NAT”. Talking about IPv6 may confuse the staffer you’re talking to, it’s partially related but not the fully picture.