You’re welcome to your opinion ;)

Fair cop on the inconveniences, although I’ve found it fine after an adaption phase, coming from fedora it was lesser than hopping to a new distro. Hard agree on knowing the nuances being problematic, clarity and accessible education is sorely missing, certainly the steepest part of the learning curve.

I just run ‘distrobox upgrade -all’ in my Daily.service, didn’t need quadlets (although after adaption I quite like them for containers now).

Why would I use a system that isn’t supposed to change if I want to change it?

There’s a bunch of benefits, atomic updates, intrinsic rollback, security of immutability, safe automatic updating and it goes on. Some things are not quite ready yet, e.g. things like sddm which should probably install themes to /etc (which they’re working on), so as often happens in linux, workarounds ensue. Making one directory mutable does not destroy all the benefits.

Yeah, I had that at the beginning, then added to my fstab

#enable sddm and therefore good themes
/var/sddm /usr/share/sddm none rbind 0 0

and KDE themes with sddm components install fine now (most themes install fine into /home, does Gnome really not have per user themes?)

Essentially you can tactically make things mutable as needed, use sparingly, but maybe not even trying lessens your opinion, no?

Yeah, I had that at the beginning, then added to my fstab

# enable sddm and therefore good themes
/var/sddm /usr/share/sddm none rbind 0 0

and then it works, kludgy, but sddm is apparently working on allowing themes in /etc, sometime soon.

Inconvenient package management

Fair.

If there’s a flatpak, no problem.

Once you realize you do package management in distroboxes rather than the main OS (rpm-ostree etc), no problem, plus you have the AUR at your disposal.

So Ima go not fair, although there is something of an education gap atm.

Be aware that halfway decent backup solutions dedupe. Which is not to say you shouldn’t clean your shit up. I vote https://github.com/qarmin/czkawka.

To a large degree, the point of RAID is to not care about drive reliability, trust the process. Also, you seem to conflate RAID with backup (“RAID is not a backup”), you want both. In a NAS, you’re probably better off with RAID5 + backup.

In a system that can take a drive failure, the current datahoarder zeitgeist is Manufacturer Recertified (Enterprise) Drives, see ServerPartDeals.com if you’re a yank, other countries have their own options.

I’d suggest you move toward a backup approach (“RAID is not a backup”) first. Assuming you have 2x10Tb, get a 3rd and copy half of your files to it, disconnect it, and now half your files are protected. Save, get another, copy the other half, now all your files are protected. If you’re trying to do RAID on USB, don’t, you are already done, otherwise (using SATA or better) you can proceed to build your array in an orderly fashion.

Sounds like an excellent idea, I’d be surprised if it isn’t happening.

Sure, I was being mildly facetious, but pointing to a better pattern, the nature of python means it is, barring some extreme development, always going to be an order of magnitude slower than compiled. If you’re not going to write even a little C, then you need to look for already written C / FORTRAN / (SQL for data) / whatever that you can adapt to reap those benefits. Perhaps a general understanding of C and a good knowledge of what your Python is doing is enough to get a usable result from a LLM.

When you need speed in Python, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in C and call it.

When you need speed in C, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in Assembly and call it.

When you need speed in Assembly, after profiling, checking for errors, and making damn sure you actually need it, you’re screwed.

Which is not to say faster Python is unwelcome, just that IMO its focus is frameworking, prototyping or bashing out quick and perhaps dirty things that work, and that’s a damn good thing.

AGI, then ASI. Goalposts change…

You don’t, I like it coz it minimizes profiling for the component search engines, and gluetun is right there, just point SearxNG at the proxy. I still get reasonable localized results by chosing a nearby exit node.

OSS, local llm, SearXNG. I likey, is there a demo ? SearXNG via VPN has helped unshittifying my search, but GIGO still applies.

Also note that Thinkpads up to a couple of years ago (when soldering RAM became a thing) are mostly trivial to open and upgrade RAM / drives, so you don’t have to care about those and can pick up a bargain (look to T480 at the moment (not the TN screen tho), or whatever is 3 years or so old, as that’s the corporate fleets that are getting dumped onto the market).

Fingerprint readers are definitely hit or miss… If you care make sure it was originally specced for linux (usually at least Red Hat), then you’re probably good for any distro.

Yup, Framework 16 highly tempting, that 8xOculink project is awesome. I’m usually a firm believer in out of contract business models, but this…

I’m on a T580, great machine, basically a P52. Dual batteries. No TN screens (I think, make sure). I put the discrete graphics card cooler in my (integrated graphics) coz I live in a hot place and some TPN7950 on the CPU, and it never cracks 70C and usually stays silent. Upgraded the SSD to a 2TB nvme, and it’s basically been flawless for 2+ yrs, touch wood.

RAID is your friend. If you can’t afford to lose one, you might have a bad time (applies to all drives anyway). Manufacturer refurbs are your best bet.