depending on how much free space you have on your drive and the size of your home folder, the easiest way would just be to

0. boot into some live image with gparted (basically any live image)
1. use gparted to resize your root and add a new partition for /home
2. copy the whole /home folder contents over to the new partition
3. if you want your existing install to work: edit your fstab to mount the new partition as /home. the arch wiki should have good instructions for this, doesn't matter if you aren't using arch

I do think they should have taken an approach similar to prettier and gofmt. very minimal settings and opinionated so all js/go codebases are effectively the same formatting

the trend of serverless means that people are writing a ton more programs that are smallish single endpoint things. not that a ton of people are using java there, but that was a major motivation for c#

steam is one of the few commonly used 32 bit apps left on linux.

I imagine most of it is bc most other things are oss and have been updated/rebuilt already. having to run a 10 year old binary happens way less on linux than it does windows.

a handful of distros have tried to remove 32 but support they've gotten backlash bc they'd lose steam support. linux the kernel won't drop it any time soon, but there's a good chance that if steam drops 32 bit, so will fedora etc

11 and the half of 12 I made it through were almost entirely awful, I don't think I have much hope left for excellence

yeah, ofc it should only be a curated set of errors where the consumer can do something about it. unknown errors should just be opaque 500s

middle ground point: start with the clj dialect for the ecosystem you're most familiar with. cljs for js, clj for jvm, etc. then you're learning the new language stuff but don't have to worry about a new ecosystem.

I love clj. in general it takes more of a pragmatic approach to functional programming than others. you get most of the purity for way less effort. same with specs over proper static types. it just ends up being a very enjoyable and productive language

sql as the language executed by the db hasn't changed notably, but I do think there's been significant developments in ORMs. for a lot of developmers sql is now just an intermediate target

more directly, sqlite was originally for tcl which is why they share the semantics.

also I'd argue that sqlite is a bigger contribution than tk, but I suppose in a more roundabout way

did you read it? apple throttled device performance. google is throttling charging speed and battery capacity for safety reasons. there are literally phones melting. also, battery capacity is something people assume will go down over time. also they're giving clear notifications when people are affected.

it's not really the same, and definitely not worse

in your case the user list would be rendered by the server and the client wouldn't care, it would receive a new rendered copy when you changed pages.

it seems like their argument was all just sites that should have been fully static to begin with, and for some reason have made it sound like that's the main use of SPAs. It's a silly article and I wouldn't change anything I'm doing based on it. if your site is a content based site(showing docs/articles/etc.) then you shouldn't be using an SPA, especially just for page transitions. otherwise you have a valid use for an SPA and should continue regardless of these new APIs