You mean, they’re mounting something that isn’t an SD card to the /sdcard directory? Like something truly evil, such as mount -t btrfs -o subvol=@home / /sdcard? Or do you think there’s not anything mounted there; it’s just a directory in the root partition? None of that would make any sense.

If they’re letting whatever automount tool (eg udevil) do its thing, this is practically impossible. And if they know enough to do it by hand, I think they’d have answered the direct question of “which filesystem” with a filesystem rather than a mount point. Don’t you think? We still don’t know what filesystem they’re working with, since they haven’t answered the question.

I agree; it probably didn’t occur to them. But it was a fairly common job in IT in the 90’s. Not a career or job description, maybe, but a duty you got saddled with.

I can see that, although TBH I almost never have to “admin” EndeavourOS. I just upgrade every once in a while.

Most important to me is being able to find and install whatever software I want, and I have a string preference that it either be installed in my ~, or be managed by the package manager. I really dislike sideloading software globally. And Arch does this better than most. AUR is massive, and packages are trivial to write and install in the rare event something isn’t in AUR.

It doesn’t matter. FAT filesystems - which are usually the default on SD cards, simply do not support ownership or file permissions. Linux emulates these attributes at mount time, but they apply to the entire SD card. You can mount an SD card and tell Linux to act as if root owns everything on the card; you that you own everything on the card; and it will be so until you unmount it and remount it with a different ownership.

These are filesystem level attributes, not device attributes. If you have a modern internal nvme drive and you format it with vfat, you will not be able to set permissions or ownership at the file level, but only at mount time, for the entire drive.

What they really got wrong was the clothing: so much anime/hentai.

This is a techno-goth.

Base Arch can be fussy, but that’s because there’s a lot to set up, so many opportunities to forget things and only discover them later.

I ran Artix on a laptop for about a year; that was a constant PITA, although I still value their goals.

But EndeavourOS has been an entirely different matter. It’s a “just works” Arch derivative.

I had so many fewer problems with Arch that I went through the effort to convert my 3 personal cloud servers from Debian to it. I went through a lot of work to replace thee default Mint on an ODroid to Arch, and it’s been so much better. I put Endeavor on the last two non-servers I installed. So, yes, I personally find out far more reliable and easier to work with than Ubuntu, Debian, or Mint.

That said, I had dad install Mint on a new computer he bought because I had to do it over the phone and he never, ever, upgrades his packages, and almost never installs anything. If all I’m going to do is install it once and then never change anything, Mint is easier. But for a normal use case where I’m regularly updating and installing software, Arch is far easier and more reliable.

A studio should be able to afford a good LTO tape drive for at least one backup copy; LTO tapes last over 30 years and suffer less from random bitrot than spinning disks. Just pay someone to spend a month duplicating the entire archive every couple of decades. And every decade you can also consolidate a bunch of tapes since the capacity has kept increasing; 18TB tapes are now available: $/MB it’s always far cheaper to use tape.

They could have done that with the drives, but today you’d have to go find an ATA IDE or old SCSI card (of you’re lucky) that’ll work on a modern motherboard.

But I’d guess their problem is more not having a process for maintaining the archives than the technology. Duplicating and consolidating hard drives once a year would have been relatively cheap, and as long as they verified checksums and kept duplicates, HDs would have been fine too.

Github is full of lists of things. There are even several lists of “awesome lists”. Far more than I can list here, and it starts to get painfully recursive (an awesome list of awesome lists of awesome lists?). Just search for “awesome list” on github; some live outside of github, so you could search for “awesome list” in Ecosia, or DDG, or whatever you use.

• https://github.com/athityakumar/awesome-awesomes
• https://github.com/topics/awesome-list
• https://github.com/bayandin/awesome-awesomeness

It sucks the same way Python sucks. Some people just really don’t like indentation-based syntax. I’m one of them, so I dislike both formats. However, if you groove on that sort of thing, I don’t think YAML is any worse than any other markup.

Oddly, I get along with Haskell, which also used indentation for scoping/delimiting; I can’t explain that, except that, somehow, indentation-based syntax seems to fit better with functional languages. But I have no clear argument about why; it’s just an oddity in my aesthetics.

Your logic makes sense. To OP’s point, though, you wear an engagement ring to show that you are engaged; a wedding ring to display you are married/wed. The argument for it being called when you receive it is weakened by the fact that most people remove their rings when an engagement is broken, or they get divorced. Or, they move the ring to a different finger, at which point it’s no longer an engagement or wedding ring, right? It’s just a ring.

If the rings were named after the event of reception, they’d still be called wedding and engagement rings even after a broken relationship. They’re “was” rings; ex-wedding-rings. No longer engagement rings.

So the more I think about it, the more I’m with OP - the rings represent a state, and so wedding rings should be called “marriage” rings to represent the state of being engaged/married, rather than the singular event of the giving.

Which set contains no elements?

Or, more in the spirit of OP’s observation:

What are the fundamental rules for set theory?

The Energy Star program had been around for around 15 years at that point

And, for computers, was almost exclusively limited to monitors. In 2009, the Energy Star specification was version 4.0, released in 2006. In that specification, the EPA’s objective was to get 40% of the computers on the market to have power management capabilities 2010 – 40% by the year after Bitcoin was introduced. Intel’s 2009 TCO-driven upgrade cycle document mentions power management, but power use isn’t included in any of the TCO metrics.

All of the focus on low-power processing units in 2009 was for mobile devices and DSPs. Computer-oriented energy savings at the time was focused on processes, e.g. manually powering down computers or use of suspension and hibernation - there was very little CPU clock scaling available for desktop computers – you turned them off to save power. DVFS didn’t become widely available – or effective – until 2006, and a study published in 2009 (again, the same year Bitcoin was introduced) found that “only 20% of initiatives had measurable targets.”

So, yes: technically, there were people thinking about these sorts of things, but it wasn’t a common consumer consideration, and the tools for power management were crude: your desktop was on and consuming power – always the same amount of power – or it was off. And people did power down their computers to save energy. But, like I said, if your desktop was on, it was consuming the same amount of energy whether you were running a miner or weren’t. There was a motto at the time bandied about by SETI@home, that your computer was using energy anyway, so you might as well do science with the spare CPU cycles. That was the mindset of most people who had computers at the time.

Zooz 800 ZSE42 800LR. $30, the coin battery lasts about a year IME.

But control of the protocol - the definition and development - is still controlled by the for-profit company, right? It hasn’t been handed over to a nonprofit governance committee, has it?

Federation or not, if Bluesky dominates the protocol, they can decide to stop federating and essentially kill the independent servers. Much like what Signal did. Sure, you can run your own Signal server, but without access to the dominant player’s market, and using a protocol that’s controlled monopolistically, it’s practically useless to do so - which is why almost nobody does it anymore.

I really like the Nostr protocol, though. It’s too bad the network is so inundated by cryptocurrency topics.

It’s simple, it has a nice extension process (standing on the shoulders of giants), and it’s super easy and lightweight to self-host. It reminds me a lot of the early days of http, when it was more common (as a developer) to telnet to port 80 and just type in a couple of lines of header and get a response.

Sadly, Nostr’s association with cryptocurrency, and the fact that 90% of the traffic on it is cryptocurrency created posts, has been a severe handicap.

djot for text markup. It addresses a lot of the issues in Common mark (and of course far more of the issues of Markdown).

I love that there’s someone out there who’s that passionate about JSON.

Love, love, opus. It’s a fantastic format.

Minnesotan here. Can confirm that 32 is still long-sleeve shirt weather.

I regularly see people here walking into a store from the parking lot in T-shirts, in 32° weather. Wind chill makes a far greater difference. 38° from wind chill is far colder than 32° with no wind.

The week-of-year is far more relevant in Western Europe, and is used quite a bit in business. I have a Junghans watch that has a week complication.

It’s an important format outside of the US, and gives ISO-8601 an edge as a standard of conformance.