Well, I’ve been migrating to the Arch flavor of Linux for the last day or two. So far, no big negative surprises.
It isn’t very “hand holdy”.
(That, FWIW, is another of those “inner words”…. I’m sure “handholdy” isn’t in any dictionary… yet it is very useful as a tag for those fat releases that do lots of things for you, sometimes in ways you don’t really want… Treating you like a child that has no valid opinion on how things ought to be. Ubuntu and Red Hat are that way. Centos is a Strict Parent and only does an install The One True Centos Way on many points. The more proper English would be “user friendly”, yet that implies it’s a good thing, that isn’t what “handholdy” implies… It is more ambiguous and is good if you are a naive innocent, but bad if you are a Unix Warrior with battle scars.)
The Red Font on the “top” command. Very BMW Dashboard like, but I’m a Mercedes driver.
Finding the name of a package to install is not obvious.
(It shares this trait with other Linuxes as each has their own package manager and libraries, but the others often have more “instructive” results when you hit a forum after a search on “package name for FORTRAN compiler” or such. The Arch user forums are much more ‘terse’ in the typical ‘insider’ way. Saying things like “it’s in the libraries” or “install the compiler packages”… where Debian and especially Ubuntu have more noobs friendly answers and Red Hat / Centos has better formal support pages / answers. That is, you are more “on your own” to find things.)
Things are in different places.
(Really, this is true of all releases. It all depends on where you started. But Arch has some things in places more “old school” and less things off in the new trendy places. Or maybe just “somewhere else”. There’s an example below. But be aware that in the transition to Arch some things you “know” will be wrong. i.e. There’s a learning curve and adjustment to the new environment.
Generally, the default font is too small and you have to size it upward. I know, I know, I’m the old guy not wearing readers, they are the young guys who don’t need them… but… it’s still an annoyance.
So far that’s about it. The positives, for me, vastly outweigh those points. It is far more efficient with resources, and that makes the PiM2 very usable as a desktop. Red Hat Fedora and Debian and especially Ubuntu are just too fat, too slow, and a PITA in a nagging sort of way for a “daily driver” desktop. Just a bit too slow to be acceptable. On Arch, it’s quite good enough, thanks, and that PiM-3 buy becomes totally optional. (I’m still going to get one, but now it is ‘someday’ instead of ‘soon as possible’)
It is very efficient with resources. On “The Others” I’d run into swapping at times. Normally they would float along at ‘almost all memory used’ and when I’d start doing too much, swap a few hundred MB. I put swap on a real USB disk just for that reason. On Arch, it has not swapped at all so far. Memory runs about 1/3 of the installed even with “the usual” stuff open (terminal window, top monitor, systems monitor, browser – and not a lite one like Midori, we’re talking FireFox). With FireFox running a video (which has sound that actually works, unlike Fedora and Ubuntu and Debian – or at least I could not figure out the magic sauce to make it work on them) CPU runs up to about 75% total AND it is smart enough to use all cores more or less evenly. Oh, and using a non-Flash video plug-in the CPU dropped to about 30%-40% (hard to tell with the red font ;-)
It has packages for what I need, and they install fast and easy. It doesn’t choke on errors. The handholdy releases will often barf on any error and halt / back out an install. Arch just runs on forward and lets you decide if it was a problem. Well, I’ve had a few errors pop up, and so far they didn’t matter. What kind? Well, on install the first time I added the “xorg” package first, then the specific bits for X called out in a reference web page. On re-install, I did it in the other order. Each complained one way or another, so there’s some kind of dependency to work out. The “xorg” last barfed 1/2 way through on some file already existing. OK, I renamed it to …/old.FOO and reran the install. Worked fine. Now a noob is unlikely to say “Screw it, just move that junk file out of the way” since it might scrog (another of those ‘inner words’- to really screw up something and break it causing it to not work, but you can likely fix it with work) things and cause you heartburn to figure out how to recover. For other packages it would say things like “BAR missing” or “FOO conflict” and go on. Nice “advisories” to have, but not very important as things ran anyway… (Until they DON’T run, then you pour over those messages seeking clue…) Basically,. Arch says it is your job as Systems Guy to know when errors matter and when they don’t. As a Systems Guy, I like that.
Everything just works. So far, so good, but I’ve not had broken / missing stuff that could not be fixed with the update or install processes. The pacman package manager is easy and fast. Find out “gimp” (image editing program) is missing? Just (as root) type “pacman -S gimp” and a few minutes later it’s done. (I’m running it right now in a terminal as I type this. Something that would kill The Others with resource demands.)
It just feels more like a proper Unix/Linux. Not a lot of cruft (old crummy dusty not quite right any more) laying around and much of the old pure ways still in evidence. Not quite BSD, but you can see memories of it here.
As is usually the case, a transition takes time. Now this is made easier by my having my home directory on external media. So first off, I can just unmount / remount ‘my stuff” and it moves. Also, I can squirrel away key config files from the old system onto “my stuff” and have it available.
I’m also starting to make an Arch Build Script to make the process more consistent (like the one for Debian / Ubuntu / anything using apt-get).
The rough steps:
1) Put BerryBoot on an SD chip. Boot it up. Choose Arch Linux from the list. (In reality, I used a large chip, so loaded on the memtester, PXE server, Fedora and Debian along with Arch, but that’s just for future playing when I deprecate other chips and decide I want to test something on Fedora or…)
2) Once Arch boots, login as root (passwd root). Update the system and install the basic X environment (eventually to be ‘run the builit script’)
pacman -S xorg #(which throws some errors that I think can be ignored)
pacman -S xf86-video-fbdev lxde xorg-xinit dbus
edit the .xinitrc file in your home directory and put in it
To now launch your X-window LXDE world, type:
(those last two hold for your personal login, added later, too)
Now you are in a nice graphical LXDE world. Open a terminal server from the icon that looks like an alien crystal arrowhead lower left, system tools, LXTermal and continue with adding any desired packages. So far, I’ve got:
pacman -S firefox
pacman -S chromium #(that seems to not work, or has an unresolved dependency – we’ll see)
pacman -S seamonkey
pacman -S binutils
pacman -S dnsutils
pacman -S ntfs-3g
pacman -S gcc-fortran #(That brings wtih it the gcc C compiler)
pacman -S gimp
and so it goes… I need to go through the rest of my buildit script and find the matching packages in the Arch world. Note that many are the same name, but some, like FORTRAN, not so much…
Oh, and somewhere in that process you ought to change the default root password to something other than “root”… and TEST IT before you log out…(su to some other user name in /etc/passwd, then ‘su root’ and you have to use the password. Doesn’t work? Exit that shell back to the root one and change it again…)
The Sys Config
I’ve made a lot of customizations to my Linux World. From a DNS that quashes many advertizing and risk sites (and avoids a LOT of junk network traffic and slow DNS lookups and generally makes things go faster) to having my own login so I’m not running as “root’ or “pi” all the time.
It can be a bit of a pain to remember, find, compare, change all those files. So I typically have a script do it. The script has to change with every release of Linux, as Systems Programmers just can’t help themselves and constantly screw around with where key files for Systems Admin are kept and how they work. (Damn them…) The latest and most eggrigious of this sort being the forced bork (yet another four letter word) of moving to systemD, but I digress… So here’s the one that I used for grabbing the Debian files. I’ve likely missed one or two, and over time I’ll figure that out and add them.
On my “movable feast disk” (that mounted disk with home directories) I have, at the top level, a directory named “Pi_Config_Files”. In it are a couple of scripts and some directories
[root@ARCH_pi_64 Pi_Config_Files]# ls Adiff Arch_LXDE DebDD cpfiles difffiles
Note the prompt reminding me I’m logged in as root, on the machine named ARCH_pi_64 (for the 64 GB chip it’s on ;-) and that I’m in the directory “Pi_Config_Files”. Then the “ls” command to list the files. Here’s a “long listing”:
[root@ARCH_pi_64 Pi_Config_Files]# ls -l total 20 -rwxr-xr-x 1 root root 2252 Apr 26 18:33 Adiff drwxr-xr-x 2 root root 4096 Apr 26 18:24 Arch_LXDE drwxr-xr-x 2 root root 4096 Apr 26 23:56 DebDD -rwxr-xr-x 1 root root 592 Apr 26 18:07 cpfiles -rwxr-xr-x 1 root root 2215 Apr 26 18:34 difffiles
Now you could name these anything. In the long listing, note that two directories exist. They are the two configs of the two machines. Arch_LXDE and Debian Daily Driver. I can capture and compare any and all configs I like for each chip/system each in their own directory. Next note the command ‘cpfiles’. that is “Copy Files”. I’ve included it below. There might very well be other files I ought to add. This is just what I thought most important for the initial move.
The “cat” command is “concatenate and print” and takes a list of file names, then prints them out. With only one name, it just prints it to your screen.
[root@ARCH_pi_64 Pi_Config_Files]# cat cpfiles cp /etc/fstab ./ETC_fstab cp /etc/passwd ./ETC_passwd cp /etc/dnsmasq.conf ./ETC_dnsmasq.conf cp /etc/exports ./ETC_exports cp /etc/group ./ETC_group cp /etc/hostname ./ETC_hostname cp /etc/hosts ./ETC_hosts cp /etc/hosts.allow ./ETC_hosts.allow cp /etc/hosts.deny ./ETC_hosts.deny cp /etc/iptables/rules.v4 ./ETC_iptables_rules.v4 cp /etc/motd ./ETC_motd cp /etc/network/interfaces ./ETC_network_interfaces cp /etc/ntp.conf ./ETC_NTP.conf cp /etc/resolv.conf ./ETC_resolv.conf cp /etc/resolvconf.conf ./ETC_resolvconf.conf cp /etc/sudoers ./ETC_sudoers cp /etc/sysctl.conf ./ETC_sysctl.conf [root@ARCH_pi_64 Pi_Config_Files]#
Note that I’m only grabbing things in the /etc directory. There’s a lot more stuff on well used systems to grab. Like /usr/local/bin and more. This is just the bare bones version and will grow over time. But it is enough to get me ‘moved in’ quickly.
Note that the ‘to’ file names are all of the form ./ETC_foo … That lets me copy the files to my current working directory. So to use this, you cd (change directory) into whatever name you gave for a particular system, and type “../cpfiles”. The “..” says “go up one directory” and then you run the cpfiles you find there. Which puts all those files in your present directory. Why rename them like that? So you have constant aswareness of when you are talking about a COPY vs the original. Typing cp ./etc/passwd /etc/passwd has risks of getting the ‘dot’ wrong or just generally being opaque… cp ./ETC_passwd /etc/passwd is clearer.
So that’s all it takes grab a debian copy.
Running this same script against the Arch system gave errors. I captured them by redirecting the error output to a file.
../cpfiles 2> err_msgs
Here’s the ls of the Arch_LXDE directory and the contents of the error messages file:
[root@ARCH_pi_64 Arch_LXDE]# ls ETC_fstab ETC_group ETC_hostname ETC_hosts ETC_motd ETC_passwd ETC_resolv.conf ETC_resolvconf.conf err_msgs [root@ARCH_pi_64 Arch_LXDE]# cat err_msgs cp: cannot stat '/etc/dnsmasq.conf': No such file or directory cp: cannot stat '/etc/exports': No such file or directory cp: cannot stat '/etc/hosts.allow': No such file or directory cp: cannot stat '/etc/hosts.deny': No such file or directory cp: cannot stat '/etc/iptables/rules.v4': No such file or directory cp: cannot stat '/etc/network/interfaces': No such file or directory cp: cannot stat '/etc/ntp.conf': No such file or directory cp: cannot stat '/etc/sudoers': No such file or directory cp: cannot stat '/etc/sysctl.conf': No such file or directory [root@ARCH_pi_64 Arch_LXDE]#
Some of those are because I’ve not installed that “part” yet. So I’ve not set up sudoers on Arch, nor do I have an iptables firewall running yet. Or NFS exports. (Note to self, install the NFS bits…) So those “errors” are in some ways a “to do” list.
The other files already exit, but are different. That’s what the “diff” command scripts do. Compare file sets. The “difffiles” command does them all, even the ones not there on Arch. As that throws nagging errors, I made a ‘cut down’ one with the lines for non-existent files commented out. I’ll do that for each system compared. (Eventually each system has a custom copy script and custom N x M compare script, so if “fstab” moves to /etc/vfstab (damn you Solaris!) that Solaris script would be aware of that and compare fstab to vfstab…
Here’s the one with lines commented out for the missing Arch files. (So later I can just remove the leading “#” and activate that compare once, for example, I’ve installed NFS…)
] [root@ARCH_pi_64 Pi_Config_Files]# cat Adiff echo echo "Doing: diff /etc/fstab ./ETC_fstab" diff /etc/fstab ./ETC_fstab echo echo -n "Next? " echo read ANS echo echo "Doing: diff /etc/passwd ./ETC_passwd" diff /etc/passwd ./ETC_passwd echo echo -n "Next? " echo read ANS echo #echo "Doing: diff /etc/dnsmasq.conf ./ETC_dnsmasq.conf" #diff /etc/dnsmasq.conf ./ETC_dnsmasq.conf echo #echo -n "Next? " echo #read ANS echo #echo "Doing: diff /etc/exports ./ETC_exports" #diff /etc/exports ./ETC_exports echo #echo -n "Next? " echo #read ANS echo echo "Doing: diff /etc/group ./ETC_group" diff /etc/group ./ETC_group echo echo -n "Next? " echo read ANS echo echo "Doing: diff /etc/hostname ./ETC_hostname" diff /etc/hostname ./ETC_hostname echo echo -n "Next? " echo read ANS echo echo "Doing: diff /etc/hosts ./ETC_hosts" diff /etc/hosts ./ETC_hosts echo echo -n "Next? " echo read ANS echo #echo "Doing: diff /etc/hosts.allow ./ETC_hosts.allow" #diff /etc/hosts.allow ./ETC_hosts.allow echo #echo -n "Next? " echo #read ANS echo #echo "Doing: diff /etc/hosts.deny ./ETC_hosts.deny" #diff /etc/hosts.deny ./ETC_hosts.deny #echo #echo -n "Next? " echo #read ANS echo #echo "Doing: diff /etc/iptables/rules.v4 ./ETC_iptables_rules.v4" #diff /etc/iptables/rules.v4 ./ETC_iptables_rules.v4 echo #echo -n "Next? " echo #read ANS echo echo "Doing: diff /etc/motd ./ETC_motd" diff /etc/motd ./ETC_motd echo echo -n "Next? " echo read ANS echo #echo "Doing: diff /etc/network/interfaces ./ETC_network_interfaces" #diff /etc/network/interfaces ./ETC_network_interfaces echo #echo -n "Next? " echo #read ANS echo #echo "Doing: diff /etc/ntp.conf ./ETC_NTP.conf" #diff /etc/ntp.conf ./ETC_NTP.conf echo #echo -n "Next? " echo #read ANS echo echo "Doing: diff /etc/resolv.conf ./ETC_resolv.conf " diff /etc/resolv.conf ./ETC_resolv.conf echo echo -n "Next? " echo read ANS echo echo "Doing: diff /etc/resolvconf.conf ./ETC_resolvconf.conf" diff /etc/resolvconf.conf ./ETC_resolvconf.conf echo echo -n "Next? " echo read ANS echo #echo "Doing: diff /etc/sudoers ./ETC_sudoers" #diff /etc/sudoers ./ETC_sudoers echo #echo -n "Next? " echo #read ANS echo #echo "Doing: diff /etc/sysctl.conf ./ETC_sysctl.conf" #diff /etc/sysctl.conf ./ETC_sysctl.conf echo echo "That's the lot of them... " echo [root@ARCH_pi_64 Pi_Config_Files]#
Note that this, too, expects to be run in the target system directory as a ../Adiff so you would first ‘cd DebDD’ and then do ../Adiff and each file is compared, one a time, to the one on the Arch system vs the DebDD one. Similarly, you could mount the disk on the Debian Daily Driver and instead ‘cd Arch_LXDE’ and do a ../Adiff to compare them on the Debian system. Yes, keeping track of your context is important here… I only wrote this for me, so it isn’t ‘handholdy’ much…
The “read ANS” is reading an input into the variable $ANS, which is just there to stop things scrolling past. $ANS isn’t used anywhere. We also have my usual “say what is happening, then do it” and white space pretty printing with empty “echo” statements.
I’m pretty much moved in. I’ve got “me” in the /etc/passwd file so I don’t need to log in as root. I’ve got things configged (configured) to mount my disks. Life is good.
Still to do is finish that alternate “buildit” script and get the rest of the files changed to match. I’ve done passwd and fstab and hostname and motd (Message Of The Day. The default Arch one says “welcome to…” and there was a court case once where a system intruder used that ‘welcome’ as a defense and won… so mine says:)
[root@ARCH_pi_64 Pi_Config_Files]# cat /etc/motd This is the Arch Linux ARM Pi Box Website: http://archlinuxarm.org Forum: http://archlinuxarm.org/forum IRC: #archlinux-arm on irc.Freenode.net What are you doing here? Get Out! [root@ARCH_pi_64 Pi_Config_Files]#
For now, though, I’m “good enough” to work using it. I can log in as “me”, listen to tunes, do postings, compile things, and mount all my disks easily. Nice.
As I run into any “odd bits” either with files or pacman -S FOO targets, I’ll add things.
For now, I’m going “back to work” ;-)