Removed by mod

• Red Hat Linux 5.1 - 7.x
• Slackware 7.0 - 12.0
• Ubuntu 6.10 - 9.10
• Slackware 13.37 - 14.1
• Mint 16 - 17
• Arch

So how does that work given that most Steam games are x86/x64 and the M2 is an ARM processor? Does it emulate an x86 CPU? Isn't that slow, given that it's an entirely different architecture, or is there some kind of secret sauce?

Multilib packages aren't installed by default just by enabling the multilib repo, so yes you need to find the lib32 libraries your application needs and install them by hand.

Perhaps it's a 32-bit application and it needs lib32-zlib.

What does ldd ./runner say?

It was a bit rocky coming over from Plasma 5, but settled in nicely now.

Just go Debian.

Ubuntu used to bring a bit of spit and polish at a time when most Linux distros lacked that. Nowadays it brings nothing worthwhile to the table anymore, it's just brand recognition, but what it does bring is aggravation for experienced users.

I had this realization a few years ago when I found myself fighting against 20.04 and I asked myself: what exactly is Ubuntu doing for me that plain Debian can't? The answer was nothing really, so I moved all my Ubuntu VMs over to Debian Bullseye and never looked back.

Oh I wanted to say, “Do not use #!/bin/sh if you’re not writing bash-only scripts”

Hah, I was wondering if that was wat you actually meant. The double negation made my head spin a bit.

I have run into scripts that don’t work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.

The weird thing is that man bash still says:

When invoked as sh, bash enters posix mode after the startup files are read.
...
--posix
    Change  the  behavior  of bash where the default operation differs from the POSIX standard to 
    match the standard (posix mode). See SEE ALSO below for a reference to a document that details 
    how posix mode affects bash's behavior.

But if you create a file with a few well known bashisms, and a #!/bin/sh shebang, it runs the bashisms just fine.

Do not use #!/bin/sh if you’re not writing bash-only scripts

Actually #!/bin/sh is for bourne shell compatible scripts. Bash is a superset of the bourne shell, so anything that works in bourne should work in bash as well as in other bourne compatible shells, but not vice versa. Bash specific syntax is often referred to as a "bashism", because it's not compatible with other shells. So you should not use bashisms in scripts that start with #!/bin/sh.

The trouble is that it is very common for distros to links /bin/sh to /bin/bash, and it used to be that bash being called as /bin/sh would change its behavior so that bashisms would not work, but this doesn't appear to be the case anymore. The result is that people often write what they think are bourne shell scripts but they unintentionally sneak in bashisms... and then when those supposed "bourne shell" scripts get run on a non-bash bourne compatible shell, they fail.

You're welcome!

There’s still another odd behavior with ./ ! When extracted it will overwrite the permission/owner to the current directory source

Only if ./ itself is included in the tar file as a directory.

If my tar contains the following folder ./home/user/ and I extract it in my current home folder (which would be kinda stupid but It happens) this will overwrite the home folder

No it will not. It will extract your files to /home/user/home/user, so a nested home directory inside your home directory (yo dawg).

The man page section you quote is about absolute paths. That is, paths that start with a / without a leading dot. They indeed can be dangerous, but by default (GNU) tar strips absolute paths and will throw a warning like:

# tar -cf test.tar /etc/hosts
                   ^leading slash
tar: Removing leading `/' from member names

# tar -tvf test.tar
-rw-r--r-- root/root       184 2022-12-08 20:27 etc/hosts
                                               ^no leading slash

this kind of structure could actually be dangerous

citation needed

I mean, tarbombs exist, but not because of the leading ./ as far as I know and they're usually specifically crafted tar files to create harm, not something you accidentally create yourself while tarring stuff.

Has anyone a good explanation why the second way is bad practice? Or not recommended?

They're functionally the same. It's like the difference between mkdir somedir and mkdir ./somedir. The leading ./ is not necessary, so I guess you could consider it less clean, but I wouldn't lose any sleep over it.

and if I make some server-like setup with multiple drives, I’d go with some kind of raid with redundancy instead of just stitching the drives together (or mb yolo and raid 0).

Server setups are usually virtual machines nowadays, with virtual disks (i.e. vmdk or qcow2 files in a storage pool). Stitching virtual disks together is valid in this case because redundancy is handled on another level, invisible to the vm.

You're good. That's the latest image, it's just the confusing Debian version scheme where the package version is not the same as the kernel version. Debian package version 6.1.0-17 = kernel version 6.1.69-1

See:

$ uname -a
Linux debian12 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux

And:

$ dpkg-query --list linux-image-6.1.0-17-amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                       Version      Architecture Description
+++-==========================-============-============-=================================
ii  linux-image-6.1.0-17-amd64 6.1.69-1     amd64        Linux 6.1 for 64-bit PCs (signed)

Realistically it's not super dangerous, and no you probably don't have a virus just from browsing a few tech support sites, but you do eliminate your last line of defense when you run software as root. As you know, root can read/change/delete anything on your system whereas regular users are generally restricted to their own data. So if there is a security problem in the software, it's made worse by the fact that you were running it as root.

You are right though that Firefox does still have its own protections - it's probably one of the most hardened pieces of software on your computer exactly because it connects to the whole wide internet - and those protections are not negated by running as root. However if those protections fail, the attacker has the keys to the kingdom rather than just a sizable chunk of the kingdom.

To put that in perspective though, if there is a Firefox exploit and a hacker gets access to your regular user account, that's already pretty bad in itself. Even if you run as a regular unprivileged user they would still have have access to things like: your personal documents, your ssh keys, your Firefox profile with your browsing history, your session cookies and your saved passwords, your e-mail, your paypal account, your banking information, ...

As root, they could obviously do even more like damage like reading all users' data, installing a keylogger or screengrabber, installing a rootkit to make themselves undetectable, but for most regular users most of the damage is already done when their own account is compromised.

So when these discussions come up, I always have to think about this XKCD comic:

*removed externally hosted image*

Some suggestions:

Step 1:

rsync has a -x flag that stops it from crossing filesystem boundaries. I find it quite useful so that I don't have to manually exclude all these directories with mounted pseudo filesystems and whatnot. Alternatively, you can also do a second mount of the filesystem you want to backup in a more convenient location than /, and run your rsync from there.

If you want to be fancy, you can also use rsync's --link-dest option to maintain different versions of your backup, so that you can go a bit further back in time. Using this option rsync creates hardlinks for files that are unchanged between the current backup and the previous one, and you can have multiple backups without much storage overhead and while still keeping the backup incremental and speedy.

Step 3:

Reflector comes with a weekly timer preinstalled. You can enable it with systemctl enable reflector.timer and then just edit the config file to your preferred settings.

Alternatively, it also has a service that you can enable so that it runs at boot time, but that doesn't work for one of my systems that is using wifi. For some reason it runs before the network is truly available and returns an error. On my ethernet connected system, I don't have that issue.

Step 4:

Instead of vacuuming your journal manually, you can also set limits in /etc/systemd/journald.conf. I just set SystemMaxUse to something sensible like 512M, so I don't ever have to worry about my journal overflowing my disk.

Step 5:

I just automate the paccache stuff with a simple cron.weekly entry. You may also want to look into where yay caches its packages.

I also agree sed and some regex is your best bet

Nah, regexes are okay if you really have no other choice, but they're a bit of a hamfisted tool. For a json file, which is a neatly structured format, I would always try to do it with jq first.

I really did like the feel of alma. Rocky I thought felt like every other GNOME system

Unless you used different versions of each, shouldn't they feel exactly the same?