Removed by mod

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?

If anyone can enlighten me, This is pretty much why you can find DooM on almost any platform BECAUSE of its Linux code port roots?

I mean yeah. Doom was extremely popular and had a huge cultural impact in the 90s. It was also the first game of that magnitude of which the source was freely released. So naturally people tried to port it to everything, and “but can it run Doom?” became a meme on its own.

It also helps that the system requirements are very modest by today’s standards.

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.

You don’t have to choose just one though. It’s perfectly ok to share a directory via Samba for Windows clients and share the same directory again with NFS for Linux clients.

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!

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.

Mostly the migration to QT6 I think.

Personally, I rather like that they’re not doing big changes or redesigns on the user facing side. KDE is pretty damn good as it is and I don’t need a whole bag of new-and-shiny breaking my workflow.

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:

So little is done by others that, if Red Hat stops, Xorg is effectively done.

Source?

As far as I know the X.org foundation is an independent non-profit organization, and while Red Hat is a sponsor and they have 1 member in the board of directors (out of 8), they don’t appear to be the main contributor.

Who made Red Hat the arbiter of when xorg should end?

I mean, sure they’re a major Linux vendor but their market is servers with hardly any foothold in the desktop market. It would be more interesting to see how long Debian, Ubuntu or Arch will keep xorg alive.

Trim support is standard. Any kernel released in the past 15 years or so will have trim support built in. So that’s not something you should worry about.

How trimming is triggered is another matter, and is distro dependent. On Arch and Debian at least there is a weekly systemd timer that runs the fstrim command on all trimmable filesystems. You can check it if’s enabled with: systemctl list-unit-files fstrim.timer. I can’t tell how other distributions handle that. On Debian derived ones, I imagine it’s similar, on something like Slackware, which is systemd-less and more hands-off in its approach, you may have to schedule fstrim yourself, or run it manually occasionally.

There is also the discard mount option that you can add in /etc/fstab, which enables automatic synchronous trimming every time blocks are deleted, but its use is discouraged because it carries a performance penalty.

Hope that answers your question.