Atemu

Note that all of this is in the context of backups; duplicates for the purpose of restoring the originals in case something happens to them. Though it is at least possible to use an index cold storage system like what I describe for more frequent access, I would find that very inconvenient for "hot" data.

how would you use an index’d storage base if the drives weren’t connected

You take a look at your index where the data you need is located, connect to that singular location (i.e. plug in a drive) and then copy it into the place it went missing from.

The difference is that, with an Index, you gain granularity. If you only need file A, you don't need to connect all 12 backup drives, just the one that has file A on it.

There’s still quite a few software written in C that does exactly as I did though.

Oh, absolutely.

’m not sure about what you mean by “OOP but worse”, wouldn’t everything be worse than OOP since C isn’t an OOP language?

I meant specifically this pattern you showed; it's object-oriented programming but in a language that does nothing to support it.

Rust isn't an OO language either but it adds some sensible abstractions to make OOP-like programming possible in an immediately recognisable and standardised manner.

I can’t seem to be able to see what’s inherently wrong with it

My primary problem is that it's convention rather than rule.

I would appreciate if you shared any better ideas you might have, though!

Just don't use C if you can avoid it ;)

Amen.

Could you upload the output of systemd-analyze plot?

I'm sorry but this is effectively just OOP but worse.

You're still defining methods of the player class here but the referenced object/struct is explicit rather than implicit. Contrary to languages that properly support OOP though, they're entirely separated from each other and entirely separate from the data type they effectively represent methods of as far as the language is concerned. They only share an implicit "namespace" using the player_ function name prefix convention which is up for humans to interpret and continue.

The problem is that i didn’t mean to write to the hdd, but to a usb stick; i typed the wrong letter out of habit from the old pc.

For that issue, I recommend never using unstable device names and always using /dev/disk/by-id/.

As for the hard drives, I’m already trying to do that, for bigger files i just break them up with split. I’m just waiting until i have enough disks to do that.

I'd highly recommend to start backing up the most important data ASAP rather than waiting to be able to back up all data.

That would require all of those disks to be connected at once which is a logistical nightmare. It would be hard with modern drives already but also consider that we're talking IDE drives here; it's hard enough to connect one of them to a modern system, let alone 12 simultaneously.

With an Index, you also gain the ability to lose and restore partial data. With a RAID array it's all or nothing; requiring wasting a bunch of space for being able to restore everything at once. Using an index, you can simply check which data was lost and prepare another copy of that data on a spare drive.

I feel it was a direct reply to the comment above.

At no point did it mention livepatching.

Dinosaurs don’t want to give up their extended LTS kernels because upgrading is a hassle and often requires rebooting, occasionally to a bad state.

No, Dinosaurs want LTS because it's stable; it's in the name.

You can't have your proprietary shitware kernel module in any kernel other than the ABI it's made for. You can't run your proprietary legacy service heap of crap on newer kernels where the kernel APIs function slightly differently.

how can you bring your userbase forward so you don’t have to keep slapping security patches onto an ancient kernel?

That still has nothing to do with livepatching.

You probably could. Though I don't see the point in powering a home server over PoE.

A random SBC in the closet? WAP? Sure. Not a home server though.

"Umsonst" beschreibt es gut, ja.

.

10% worse efficiency > no refrigerator