"shallow mental model (...) It really does take time if you want to understand Arch deeply"
You made me curious. Those sound like they are the opposite of each other.
On the article... the same old. Not for me. I like learning, but not just anything. Learning how to use the configuration of dozens of software pieces is NOT on my to do list, specially when it's pretty obvious I won't have room on my mental memory for all of it.
As the article says, it's not for everyone.
The "shallow mental model" most likely refers to fewer initialization files and locations. When starting out, most everything you need is in /etc/rc.conf . Also, Arch and its package manager don't use /usr/local/, instead simply using /usr.
"It really does take time" most likely refers to the fact that you are responsible for building up the OS yourself. So unlike in an OS like Ubuntu, where you do not have to know what a window manager is, or what an xorg xserver and client means, you'll have to learn it all along the way.
Fortunately the wiki makes figuring everything out managable, and I found it an enjoyable to spend a couple days with different software[1] and a programmable tiling window manager[2]. The end result is a fast-booting custom tailored system.
would you elaborate? i guess i agree for historical reasons but for practical reasons i think package managers actually should use /usr/local/. basically everyone uses a package manager now (except lfs). where would you like package managers to install.
"The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated." [1]
And I believe that "system software" today means "installed by a package manager" (please correct me if I'm wrong).
I personally (rarely) use /usr/local for manually-installed packages. This way there's no risk of a package manager accidentally overwriting stuff outside its control.
It's the "go" (as in the game) of Linux distros. Easy to understand, long to master.
For instance, I recently switched off of using netcfg to wpa_supplicant instead. netcfg is an awesome way to manage network configs, but I am to the point that I enjoy and want to tweak my network configs to be faster (faster to get the network connection up, not faster throughput).
Most distros will take a very safe, works-in-all-cases approach to networking and sacrifice some efficiencies that can be squeezed out of the process. Since the system is very simple to configure, I can easily dump all that cruft (and in this case the "cruft" is the already pretty lean and efficient netcfg) and just use ip, iw, and wpa_supplicant.
It takes a bit of time to learn those tools, not long, but it's time. It's valuable because iproute2 is the Way going forward.
You made me curious. Those sound like they are the opposite of each other.
On the article... the same old. Not for me. I like learning, but not just anything. Learning how to use the configuration of dozens of software pieces is NOT on my to do list, specially when it's pretty obvious I won't have room on my mental memory for all of it. As the article says, it's not for everyone.