I didn't really get into custom kernels until I started using Crux. A few years after I started using Arch I got sick of the rolling release and Arch's constant breakages, so I started looking into the alternatives, that brought me to Crux (which Arch was based off of) and Slackware (which was philosophically the opposite of Arch without sacrificing the base understanding of the OS). Crux would have probably won out over Slackware if it were not for the switch to 64bit, when confronted with having to recompile everything, I went with the path of least resistance. Crux is what taught me to compile a kernel, in my Arch days I was lucky when it came to hardware and only had to change a few things in the config which the Arch wiki guided me through.
Crux is a great distro for anyone ok with a source distro and I think it might be the best source distro, unlike the more common source distros, it does not do most of the work for you. Also love its influence from BSD, which came in very handy when I started to explore the BSDs and FreeBSD which is my fallback for when Patrick dies or steps back, Crux deserves more attention.
Arch always turned me off with it's rolling release schedule, and I wasn't that impressed with pacman to be honest. I used to love Slack, but they lost their way trying to compete with Ubuntu and the like. I remember thinking how ridiculous it was for mplayer to have samba as a dependency, and the community saying a full install was the intended way to run Slack. I ran it as a minimalist without issues until they started wanting to compete in the desktop space.
The best successor I've found is Alpine. It's minimal and secure by design, has an excellent package manager (I much prefer apk to pacman or xbps, or apt and rpm for that matter), has stable and LTS releases while letting people who want to be rolling release do so by running edge. People think it's only for containers but it has every desktop package anyone would need, all up to date and well maintained. Their wiki isn't at Arch's level, but it's pretty damn good in its own right.
I like alpine because it try to be relatively simple (openrc, busybox, …). My only issue is programs relying on glibc for no reason (altough you can use flatpack). But I’m using openbsd now.
I was never a fan of openbsd, a lot of the security claims are misplaced, bordering on theater. glibc support isn't so bad in Alpine, there are compatibility packages that work for most things if there isn't a flatpak.
Pretty sure that's cos every AI company wants to have a copy of all the worlds information stored in each of their data centers, and hard drives are the best storage medium for that.
Design your training strategy carefully and you can do streaming rather than random reads from the drives and get enough performance.
To be honest, they mostly have 8 TB and up in stock at the moment, but the price was around 35 EUR for the 1 TB drive which is kind of insane when similar drives at local stores cost 110 EUR right now - I remember when those Seagate Barracuda drives were about 40-50 EUR brand new!
I still use SSDs for boot drives, video games and also fragmented data (like Garage for something S3 compatible, which chunks the files), but for backups and longer term storage HDDs are great.
Same with DRAM, old-node chips during the Post-COVID chip shortage, and toilet paper during COVID. Lots of things are commodities until the demand spikes.
I'm with you and I'm a solo dev right now. Reading, understanding, and trying to decide what is the right code and how that code fits is the most time consuming.
It’s pretty well established that you cannot understand code without having thought things through while writing it. You need to know why things are written the way the are to understand what is written.
Yeah, just reading code does little to help me understand how a program works. I have to break it apart and change it and run it. Write some test inputs, run the code under a debugger, and observe the change in behavior when changing inputs.
I’ll grant you that there are many trivial software defects that can be identified by simply reading the code and making minor changes.
But for architectural issues, you need to be able to articulate how you would have written the code in the first place, once you understand the existing behavior and its problems. That is my interpretation of GP’s comment.
Some musings from someone who has not worked in microsoft but has in big tech.
This often happens because the people inside are incentivized to build their own empire.
If someone comes and wants to get promoted/become an exec, there's a ceiling if they work under the an existing umberlla + dealing the politics of introducing a feature which requires dealing with an existing org.
So they build something new.
And the next person does the same.
And so you have 365, One, Live, .Net, etc
Google Plus was the same. Lots of unrelated google products were temporarily branded as part of google plus for some reason, including your google account and google hangouts (meet).
That was a very intentional strategy. In hindsight, not a good one, of course, but Plus and its integration across the whole company was blessed by Page and Brin, who were quietly panicking that Facebook could eat Google's lunch by becoming the "start page of the Internet" the moment they integrated search. Which they never did and never appear to have wanted.
I even bookmarked a page to remember how to rebuild the kernel because I can always expect it breaking.
reply