The RPIs are moving to nvme too, though indeed a bit slower than desktop machines. My virtual machines use /dev/vdx, and I don’t typically connect USB drives to my virtual machines with the intent to flash them :)

Well, try not to shred too many SATA SSDs then until you get there 🤡

Here’s the thing: your answer is both invalidating and ignorant, and it shows a lack of understanding of what differentiates Arch from a stable distro.

• My wifi, that had been working fine since I installed this computer in 2020, broke in kernel 6.11 and 6.12 because Arch pushed those updates.
• Early plasma 6.0 releases were rough as balls for months, because Arch pushed those updates.
• My bluetooth, that had been working since I installed this computer in 2020, started to randomly disconnect sometime last year due to buggy firmware updates because Arch pushed those updates.
• Hell even plain old intel ethernet on my old system from 2014 suddenly started hanging up under load a year or two ago (never found the cause, did find a workaround).

None of these issues were a fault of my own, all I did was pacman -Syu, and none of this would happen on a stable distro. I’m not saying Arch is shit because of this, I’m saying: beware of what you are getting into when you choose Arch: for every single package on your system, you are effectively at the mercy of whatever “upstream” decides to shit out that week. Being delusional about that fact and having guys come crawling out of the woodworks everytime this is mentioned, saying platitudes like: “I nEvEr HaD aN iSsUe” doesn’t help anyone.

What you’ve said is true, though it’s a bit of a trade-off

Yes, and that’s why after more than 10 years I still use Arch. I like having the latest version of things and I’m confident enough in my abilities that I know that if something breaks I can always either find a fix, or at least identify the offending package, hold it back, report the bug and wait for the issue to be resolved.

There are times where it can be trying though. The first plasma 6 releases for example were rough. More recently, I’ve also been having issues with 6.11 and 6.12 kernels and my ax200 wifi that I only recently found a fix to. My wifi would freeze whenever I started streaming video from the PC to my TV, but only in kernels after 6.11. Turning off TCP segmentation offloading with ethtool resolved it (ethtool -K wlan0 tso off). You don’t want to know how long I had been pulling my hair out at that issue until I found the fix.

That’s such a cop-out answer and totally missing the point. I’ve run Arch on 4 different systems, and yes I had different issues on each and sometimes issues that hit across the board.

At the end of the day, whether or not this was just my personal experience doesn’t matter. What matters is that the issues were always caused by what Arch is: a unstable rolling release distro that pushes out the latest version of upstream packages, bugs and all. Sooner or later some will hit you, telling yourself and other people otherwise is deluding yourself and those people.

I’ve been using Arch since 2014. If I could be arsed, I could write you a looooooooong list of regressions I’ve had to deal with over the years. For an experienced Linux user, they’re usually fairly easy to deal with, but saying you never have to deal with anything is just a lie.

My experience with Arch is basically: it’s all very predictable until it isn’t and you suddenly find yourself troubleshooting something random like unexplainable bluetooth disconnects caused by a firmware or kernel update.

Luckily, this problem will disappear soon as we’re moving to systems with only nvme drives. Kinda hard to mistake /dev/nvmexny for /dev/sdx.

In Linux, everything is a file.

So if you have a problem, it will be in a file somewhere.

So logically every problem can be equalled to one or more files.

Therefore it follows: no files = no problems. And no problems = no headache.

Millenials - Load"$“,8 LIST LOAD"LEISURESUIT*”,8,1 (wait 10 min.) RUN

Even the oldest millennials were just toddlers when the C64 was relevant, so this is not a typical millennial experience at all. It’s really a GenX thing… so once again we are forgotten.

I would say millennials’ computer experience starts in the late DOS/Win3.11 era at the very earliest, but more typically in the Windows 9x and early XP era. So even IRQ/DMA/config.sys/autoexec.bat fuckery is not that typical.

I see military spending as a necessary evil, it’s like paying your insurance policy against the evils in the world. There will always be someone with a stick willing to beat someone weaker than them. So you could theoretically spend that military money on something “more useful”, but if all your friends do that as well, you won’t be able to enjoy that nice world for very long.

Also, people usually highly overrate how much a country spends on defense and underrate how much is spent on social security. Where I live, in Belgium, with a similar military budget as Canada (in terms of % of GDP) they did a survey once and asked people to estimate how many euros out of €100 of tax money went to the military and other things. People on average thought it was €6.1 to the military and €17.4 to social security. In reality the proportions are just €1.3 to the military and €37.5 to social security.

So I guess what I’m saying is: it’s okay to enjoy the cool noises without guilt. You paid for it, it’s necessary, and at least they’re providing people with some entertainment now.

A core memory of mine is getting flung off of one of these things because of the centrifugal force, falling on my back, and being unable to breathe for like 20-30 seconds … until I screamed at the top of my lungs, and things slowly returned to normal, while the teacher just went: oh you’re fine, don’t be a baby. I was 6.

The flag is called --no-preserve-root, but the flag wouldn’t do anything here because you’re not deleting root (/), you’re deleting all non-hidden files and directories under root (/*), and rm will just let you do it.

Since you forgot to add - - preserve-root It won’t go too far

Go on then … try it.

Or don’t because you will erase your system. (Hint: it’s in the asterisk)

as the binary is already loaded into memory

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

In Unix/Linux, a removed file only disappears when the last file descriptor to it is gone. As long as the file /usr/bin/rm is still opened by a process (and it is, because it is running) it will not actually be deleted from disk from the perspective of that process.

This also why removing a log file that’s actively being written to doesn’t clear up filesystem space, and why it’s more effective to truncate it instead. ( e.g. Run > /var/log/myhugeactivelogfile.log instead of rm /var/log/myhugeactivelogfile.log), or why Linux can upgrade a package that’s currently running and the running process will just keep chugging along as the old version, until restarted.

Sometimes you can even use this to recover an accidentally deleted file, if it’s still held open in a process. You can go to /proc/$PID/fd, where $PID is the process ID of the process holding the file open, and find all the file descriptors it has in use, and then copy the lost content from there.

kill -9 1

Leave the poor kernel out of it, it has nothing to do with this. It’s Lennart, not Linus.

I don’t think it’s intended as a “solution”, it just lets the clobbering that is caused by the case insensitiveness happen.

So git just goes:

• checkout content of README.md to README.md (OS creates README.md)
• checkout content of README.MD to README.MD (OS overwrites README.md)

If you add a third or fourth file … it would just continue, and file gets checked out first gets the filename and whichever file gets checked out last, gets the content.