"The best that most of us can hope to achieve in physics is simply tomisunderstand at a deeper level."
– Wolfgang Pauli
Remember ... the big supernetwork of all networks is the computer ... it's not the distro -- it's the community, dev network, company, sustaining foundation and everything built around the distro ... and, at the end of the day -- that distro is JUST a distro, even if it is the best distro.
The point of THIS little particular rodeo is doing "from first principles" computational material science ... we apply and break our tools, methods and theories like density functional theory (DFT) in order to test them and find out where they are wrong or incomplete to better or more practically misunderstand the nature of the Universe at a deeper level. It's the intuition that comes from trying things ... learning the hard way ... that gives us the deeper, broader insights we seek.
The How comes from the Why
And NOT the other way around ... but in order to actually use the computational toolkit for this kind of science, it's a DAUNTING task of first sharpening the axe ... this exercise, along with using that axe, allows us to think about what the axe does, why we want it sharp and maybe if there's a better way.
That means it necessary to spend at least a few months or years practically living inside the tool, inside different elements of these computational toolkits ...
That means things like really, really, really using the distros [and their dev communities], banging on them hard, maybe getting frustrated enough to find workarounds and even re-config, re-compile, modify and re-build the things to really LEARN how the LARGER realm of computational knowledge works and develops.
Hints that come with decades of experience
You would not think it takes so long ... the HINTS are really simple ... but they are kind of hard rules.
HINT #1: It's not JUST the Linux kernel or some miraculous tool like Git or GitHub or GitLab ... or, for that matter, any command line tool ... the same principle applies to things like chroot or the Open Container Initiative and things like CRI-O, Podman, LXC and especially studying the most awesome things that being with docker or docker compose ... and that comes AFTER really using the tools in your workflow, which necessarily involves becoming intuitively conversant in OR thinking in the idioms of what docker itself is doing as well as ALL of the docker, i.e not just docker-run but ALL of those commands ... and then understanding what's up with the K8s vocabulary and all things K8s like openshift ... and certainly spending some time understanding what the fuss over WASM is all about ... and that means understanding what ByteCode Alliance projects like Wasmtime, Cranelift, WAMR are all about ... understand in ways that apply to how you get work done what a kernel is, what's a distro, what's in an operating system, what's a container, what's a process, what's a thread, understand computational architectural things, eg why does memory bandwidth matter, for making Big Compute work.
HINT #2: Features are nice ... but at the end of the day it's all about reliability, predictability, stability ... this is the same as the reason for valuing the STABILITY of BSD when you are doing something like Netflix ... but remember -- you're not Netflix ... you are trying to do scientific computing and HPC, your use case is not about developing a reliable, speedy content delivery network to keep customers paying their monthly Netflix bills [rather than cable] ... but ultimately, predictability and stability are still the name of the game -- you don't want to get lost or distracted by quirky new features or the wild virtual world of the Metaverse -- you will have to be monitoring performance and execution, so you need to take some of the chaos out of the equation ... this is because, you want to focus on the science ... so that's why you want predictability, reliability, stability as you push the boundaries of what you can do in Big Compute ... RedHat Enterprise Linux seems work better than other Linux distros and Ubuntu get's used a lot because it's far better than anything the Microsoft or Apple / FreeBSD ecosystems have to offer. RedHat ENTERPRISE Linux bring decades of quasi-opennesss and adds in the insistence on stability from IBM. You can complain that Red Hat sold out -- but, the code is still open [through Fedora, CentOS Stream, Rocky Linux, Alma Linux, et al] and thus still-extensible material ... but it is developed as a tool for huge business customers, ie the tool has to just work without any developer or corporate IT flunkie sysadmin fiddling with it. You will notice that RHEL is the basis for Oracle Linux which is buttoned up as tight as Apple, if not tighter -- that's not derogatory, ie people love their Apple stuff because everything just so, so comfortable to Apple users and, mostly it just works [until it doesn't]. Being tight means that people can really depend upon it RELIABLY just working and there's no shortage of data and proof that Oracle/IBM can bring to PROVE this, ie unlike gushing assertions like "I love popOS; it just works so well for me."
"The best that most of us can hope to achieve in physics is simply to misunderstand at a deeper level."
– Wolfgang Pauli
Remember ... the big supernetwork of all networks is the computer ... it's not the distro -- it's the community, dev network, company, sustaining foundation and everything built around the distro ... and, at the end of the day -- that distro is JUST a distro, even if it is the best distro.
Let someone else follow the exiting flashy features or the fashionable trends in AI, the Metaverse, information security and privacy, programmming and WASM ... or Web5 or genomics in the cloud ... keeping up with the horseraces is sort of what the Big Network is for.
KNOW your WHY
The point of THIS little particular rodeo is doing "from first principles" computational material science ... we apply and break our tools, methods and theories like density functional theory (DFT) in order to test them and find out where they are wrong or incomplete to better or more practically misunderstand the nature of the Universe at a deeper level. It's the intuition that comes from trying things ... learning the hard way ... that gives us the deeper, broader insights we seek.
The How comes from the Why
And NOT the other way around ... but in order to actually use the computational toolkit for this kind of science, it's a DAUNTING task of first sharpening the axe ... this exercise, along with using that axe, allows us to think about what the axe does, why we want it sharp and maybe if there's a better way.
That means it necessary to spend at least a few months or years practically living inside the tool, inside different elements of these computational toolkits ...
That means things like really, really, really using the distros [and their dev communities], banging on them hard, maybe getting frustrated enough to find workarounds and even re-config, re-compile, modify and re-build the things to really LEARN how the LARGER realm of computational knowledge works and develops.
Hints that come with decades of experience
You would not think it takes so long ... the HINTS are really simple ... but they are kind of hard rules.
HINT #1: It's not JUST the Linux kernel or some miraculous tool like Git or GitHub or GitLab ... or, for that matter, any command line tool ... the same principle applies to things like chroot or the Open Container Initiative and things like CRI-O, Podman, LXC and especially studying the most awesome things that being with docker or docker compose ... and that comes AFTER really using the tools in your workflow, which necessarily involves becoming intuitively conversant in OR thinking in the idioms of what docker itself is doing as well as ALL of the docker, i.e not just docker-run but ALL of those commands ... and then understanding what's up with the K8s vocabulary and all things K8s like openshift ... and certainly spending some time understanding what the fuss over WASM is all about ... and that means understanding what ByteCode Alliance projects like Wasmtime, Cranelift, WAMR are all about ... understand in ways that apply to how you get work done what a kernel is, what's a distro, what's in an operating system, what's a container, what's a process, what's a thread, understand computational architectural things, eg why does memory bandwidth matter, for making Big Compute work.
HINT #2: Features are nice ... but at the end of the day it's all about reliability, predictability, stability ... this is the same as the reason for valuing the STABILITY of BSD when you are doing something like Netflix ... but remember -- you're not Netflix ... you are trying to do scientific computing and HPC, your use case is not about developing a reliable, speedy content delivery network to keep customers paying their monthly Netflix bills [rather than cable] ... but ultimately, predictability and stability are still the name of the game -- you don't want to get lost or distracted by quirky new features or the wild virtual world of the Metaverse -- you will have to be monitoring performance and execution, so you need to take some of the chaos out of the equation ... this is because, you want to focus on the science ... so that's why you want predictability, reliability, stability as you push the boundaries of what you can do in Big Compute ... RedHat Enterprise Linux seems work better than other Linux distros and Ubuntu get's used a lot because it's far better than anything the Microsoft or Apple / FreeBSD ecosystems have to offer. RedHat ENTERPRISE Linux bring decades of quasi-opennesss and adds in the insistence on stability from IBM. You can complain that Red Hat sold out -- but, the code is still open [through Fedora, CentOS Stream, Rocky Linux, Alma Linux, et al] and thus still-extensible material ... but it is developed as a tool for huge business customers, ie the tool has to just work without any developer or corporate IT flunkie sysadmin fiddling with it. You will notice that RHEL is the basis for Oracle Linux which is buttoned up as tight as Apple, if not tighter -- that's not derogatory, ie people love their Apple stuff because everything just so, so comfortable to Apple users and, mostly it just works [until it doesn't]. Being tight means that people can really depend upon it RELIABLY just working and there's no shortage of data and proof that Oracle/IBM can bring to PROVE this, ie unlike gushing assertions like "I love popOS; it just works so well for me."