Since I’ve had one comment and a couple e-mails about my decision to get rid of CrunchBang, I decided to give a broader accounting of why I threw in the towel with it. I appreciate the input from others, as well as suggestions to try different things (been there, done that).
I posted the two videos showing the ath5k timeout right after it happened and after reboot — during which the Atheros card remains entirely undetected by both Linux AND Windows (that time through a combined five reboots before re-detected) — to demonstrate one issue. The timeout occurred while I was in middle of doing another screencast, which, ironically enough, was to demonstrate the frustration I was having with setting up a more or less custom system on anything using tools like dpkg/apt/aptitude.
In a nutshell, I started removing applications and things I knew I’d never use or which I wanted an alternative. I also had to compile a few things to support my hardware and devices (such as updating libmtp for my Samsung S3). I also recompiled a few things so I wouldn’t have excessive crap — for example, compiling the latest release of mew (e-mail client) without extra dependencies installed via the repository version.
The end result was something of a hybrid system. I know there are plenty ways to manage such things, but the end result required issuing more “sudo aptitude hold” commands for various things I needed but aptitude thought I didn’t, and vice versa. Every upgrade was first run with -s to see if I’d have more problems upgrading than I would if I just fetched the sources and compiled them myself.
As I explained in my reply to a comment this morning about different kernels and such, it’s a house of cards. Pull the wrong one out and the whole fucking thing is going to come crashing down.
There are several options to that which allow more control over my own system. They include:
- Using a source-based distro,
- Using a ports-based distro or BSD,
- Using a minimal install with full headers (Slackware would be ideal) and compiling the rest of the system as desired, or
- TinyCore.
I openly admit my bias to the last one. I was active in the DSL community and had posted my thoughts on modularlizing DSL a few years ago when Robert inquired what direction DSL should take (unfortunately, my images were hosted on another site which underwent a change in ownership so I don’t have those anymore). I was also on the TinyCore team during its earliest development phase; you can blame me for the logo and a couple other things. I dropped off the team due to work commitments and (later) family issues that required me to care 24/7 for four elderly people from October into January. I didn’t have time for myself from about August onward and it’s taken until this summer to get caught up with the rest of my life.
I chose to use binary-based distros because I didn’t want the “hassle” of configuring things. I just wanted to install it, get the apps I need to get stuff done, and that’s it. Unfortunately, that’s expecting too much. Along the course of jumping from PCLOS to Fedora to Debian (Lenny and Sid) to CrunchBang, I wondered openly if I shouldn’t have either opted for a source-based distro or TinyCore since I was doing as much configuration and (re-)compiling of things that didn’t suit my needs or tastes.
I’d changed CrunchBang around so much that it was basically back to Ubuntu plus and minus the things I either recompiled or compiled separately. I’d taken to privately calling it "un-buntu." It was also un-CrunchBang, as I’d removed nearly everything that was unique to CrunchBang (and my entry in menu.lst avoided the splash crap).
The base apps didn’t put me off CrunchBang because I knew I could change all of that around to work for me. And I did. If not for "aptitude hold" commands applied to so many packages, it might still work for me as unwieldy and fucked up as I think it is to lose so much control because the packaging system wants to make changes I don’t want it to make.
The recurring ath5k timeouts also didn’t put me off CrunchBang. They putme off Linux. Totally. At least on my AA1.
I was off CrunchBang because I was fed up with the ever-increasing dependency issues that only reinforced how much control packagers had over my system and how much I had to do to maintain control of it myself. That’s not a problem if you don’t give a shit who’s putting what on your system or why. Click in synaptics and add things to your heart’s content and don’t worry about it. I fucking hate bloat.
I decided to reclaim all that space because I was tired of losing wifi and I was also at a point where running aptitude commands prompted me to remove 20-something more things, some of which I knew damn well I needed to hold and some of which I’m not even sure. I’ll post the video showing that bullshit.
Why is TinyCore a better option for me?
- It’s very small and its packages are lean,
- It’s modular so I only add the bits I want/need,
- I have total control over how my system starts and ends up,
- I can reboot to undo any changes and I’m right back in a fresh environment without nagging about {u} packages,
- I decide which things persist between boots, and
- I can also set it up in a hybrid state to suit my own needs and tastes without risking problems with “big brother” packaging trying to change or overwrite the way I have things set up.
Let’s go through each of these points in greater detail.
1. It’s very small and its packages are lean.
The initial ISO isn’t a complete system. Maybe it’s not the best selling point that I had to manually download extensions (packages) to be able to connect to the Internet. Or that I prefer adding extensions to use GNU coreutils and various other utilities over the busybox versions. The base is very lean, fast, and stable.
2. It’s modular so I only add the bits I want/need.
As noted above, I much prefer the "bloated" versions of certain utilities to the stripped ones in busybox. I also need them in my preferred environment (emacs) for things like dired-mode, which is my file manager. I don’t have gobs of shite on my hard drive I don’t or won’t ever need. My system has the extensions I need to use Linux the way I want, not the way various packagers have chosen to compile things with every possible option.
3. I have total control over how my system starts and ends up.
TinyCore’s cheatcodes allow for various start up options, including ignoring all extensions and backups — so you start in the same initial state you’d have from the original ISO. But that’s only part of the way you can customize your environment.
By default, TinyCore will look for a tce folder with extensions at boot and automatically load those extensions. Within the tce directory, you can set an optional directory for any other extensions you desire to load ad hoc.
I’ve chosen to keep both sound modules (OSS, alsa) extensions I use in there so I can load them as desired. Same with the extensions for OpenOffice, v4l, mencoder, etc. — why load them automatically when I can load only as I want to use them? Dittos with compiletce, a meta-package for the extensions for compiling from source in Tiny Core.
Other options include setting up your own local mirror with TC extensions. I’m only running TinyCore on one computer (AA1) at the moment but may do that if I install it on anything else beyond my new laptop when it arrives.
4. I can reboot to undo any changes and I’m right back in a fresh environment without nagging about {u} packages.
If things get out of hand, all I have to do is reboot. The only settings that persist are the ones I’ve set up to do that or that are on persistent partitions. The TC extensions only load as I choose, when and how I choose them to load. The kernel and utilities are read-only in RAM. If anything happens to them, a reboot cleans it back to the way they were found in the ISO (or a remaster). If pwned, it’s only going to last to reboot unless a persistent setting (such as a conf file but there’s probably more that can be affected) is altered to make it persist.
5. I decide which things persist between boots.
The whole base refreshes itself between boots. That includes some files which I may not want to revert to a “base” state. And I can edit a boot line in GRUB to "norestore" so that I can get to the original state. I have separate menu.lst entries for that already so no need to edit. I can also choose which directories persist — I can remove /home, /opt, or /local (or add nolocal) to further control how the system starts up.
6. I can also set it up in a hybrid state to suit my peculiar needs and tastes. And there’s no worry about my stuff changing unless and until I want it changed.
My primary application is emacs, which I compiled from source. I’m writing this in it now. I chose to install it more traditionally using $HOME/local as a prefix (so I have /home/tc/local/{bin,share,lib,etc} in one directory tree). I chose that to keep compiled apps separate from scripts in $HOME/bin and to keep my home partition from cluttering up with separate lib, share, etc, and so on directories. I wanted emacs at the very least in a more "traditional" form like that because of its size (I figure /home is faster to mount than a 100+MB package would be to load) and because I want persistent rw access to some elisp files it installs and uses. I’ve installed other apps with the same prefix for the time being. I’ll probably recompile them for use as extensions after testing.
The more tweaks I’ve made to TinyCore, the more time I realize I wasted trying to get other distros to work the way I want them to. In most cases, that meant starting big and tearing down — that includes CrunchBang. With TinyCore, it’s much more sensible, clean, coherent: start small, add only what I need, compile what I want, and I’m not stuck with dependency hell scenarios or getting warned that half my system is suddenly about to be removed by the packaging system if I don’t hit N now.
And if the ath5k driver in wireless-2.6.29.1-tinycore_mod.tcem doesn’t timeout, I’ll have a reason to keep running Linux on my AA1. At least in tandem with Windows. Or instead of it. (Edit: See next post for ath5k timeout at about four hours uptime. At least TinyCore doesn’t take up a lot of space on a hard drive.)
---
posted from emacs 23.1.1 using weblogger.el
re-formatted from the original with minimal editing
