Archive for the ‘crunchbang’ Category

Scientific Linux 5.4 (Live/USB) on my Aspire One

April 17, 2010

I ran Scientific Linux for a little while on my new-old laptop and still have it installed on a spare hard drive in my new desktop (though I’ve been running Debian on that for about a month). Really didn’t have much trouble with it — it’s just what one should expect by something that’s oriented for enterprise use: stable, solid, not flashy, not bleeding edge, no drama.

For those who don’t know about Scientific Linux, it’s compiled from RHEL sources so it’s in the same category as CentOS. The biggest difference between CentOS and SL is the former is a community-run project while SL is based at FermiLab. SL has a more scientific orientation than CentOS, with a focus on packages for use in research and writing and less on games and entertainment (though there are concessions to games and entertainment). If the SL repositories are inadequate for your needs, there are optional third-party repositories of RHEL binary-compatible RPMs which should work across the spectrum of RHEL-compatible distros.

I was playing around with distros while watching the NBA playoffs tonight, since the first two games today were routs. I first decided to look at SL54 live CD on my Aspire One. I first tried the Lite image but it lacked wpa_supplicant, so I grabbed the full Gnome image and put it on USB via unetbootin. For what it’s worth, the Lite image uses icewm (which is also on the Gnome live CD) and comes with Firefox, emacs, vim, xfe, and probably other stuff I didn’t bother looking at very closely. Sorry, but there’s only so much I can do without networking. I did log out of icewm to run emacs in console and I can vouch for its stability.

Once I set up a USB stick with the Gnome image, I booted up. It’s straightforward and comforting because I like to see hardware detection instead of some sexy graphics. I encountered one little problem logging in: Scientific Linux live CD has a pre-login option to set keyboard and passwords (passwords are optional). With the small display of my Aspire One and the large text in the dialog, I was unable to see the area where the prompts were. Fortunately, I’ve used this fine little live CD before so I knew US-English keyboard is 1 and I didn’t bother to choose to set a password since I was just seeing how well it would do on the Aspire One. After hitting return, I went to the gdm login and entered “sluser” and I was quickly in  Gnome.

After a quick look at dmesg and lsmod, I quickly set up my wireless. Voila.

It’s been a while since I spent this much time using Linux on the Aspire One. Other than occasionally logging in to my TinyCore/MicroCore install on this thing, I’ve given up running Linux on it. Search my ath5k entries and you’ll see why. I never did sort out whether it was related to the ath5k driver, something in the 80211 MAC stack, or wpa_supplicant — it could be one, it could be a combination, but I know for sure that it isn’t the card (it works flawlessly in Windows no matter how long I’m on it). It’s quite possible if the problem is with wpa_supplicant that “backing down” to an enterprise-oriented distro like Scientific or CentOS might let me run Linux on this thing since wpa_supplicant most likely is a more stable (okay, older) version with certain patches to fix bugs. The problem with testing that tonight is I was on battery and thus not up long enough to see. (I just plugged in again to reboot and post this.)

The only issue I remember under SL54 on my desktop was having to manually update hplip for my printer. The same would apply to CentOS and other RHEL-compatible distros (what does that leave, Oracle?). That’s a minor consideration compared to the issues I had with repeated wifi timeouts under the following distros (not the fault of the distros, just a summary of ones I ran on the AA1):

  • PCLOS (KDE, Xfce/Phoenix, etc.)
  • Fedora (10, 11, 12)
  • Debian (Lenny and Sid)
  • CrunchBang
  • TinyCore/MicroCore

I think that’s it. There were others I ran off USB but never would install because they weren’t ready for prime time. And when I run off USB (as I did tonight), it’s rarely for hours or days on end. It was more like 45 minutes while I shelled in to my desktop and moved files around (including the above screenshots). Like I wrote above, not enough time for the ath5k to race and panic and then no longer be detected.

I didn’t do a full checklist of hardware compatibility but I don’t think this thing would have any unresolved issues (except maybe the stupid card readers). I was a little surprised after the login thing with the keyboard and password prompts that gdm and X ran perfectly and detected the correct resolution. I didn’t look at the webcam. I presume audio works (the error beep sure did) but didn’t bother with that since I already knew I’d have to download codecs to listen to anything other than ogg files (I was watching the games, not interested in streaming or playing anything). As you can see from the wifi icon, my ath5k card was properly detected and nm-applet did a cursory scan to find available networks; I set it up quickly and was networked with WPA.

I’m still determined to run Linux on this thing even though it’s supposedly been for sale for the past couple months. I’ll probably give this USB stick with SL54 a longer look on the AA1 in the coming days to see if I can get the ath5k to time out again. For now, though, I have to get some sleep.

UPDATE: I’ve posted an update/addendum to this post.

Crunchbang Moves to Debian-Squeeze

March 24, 2010

I found this interview of Crunchbang Linux developer Philip Newborough in which he details reasons for building #! on Debian-Squeeze (testing). The first reason he gives is the difference between Debian’s democratic process and Ubuntu’s commercial sponsorship by Canonical, which he likens more to being a “governing party” more interested in “producing a polished end-user system” that often makes the work of derivative projects more difficult. He thinks “that some of [Canonical’s/Ubuntu’s] recent decisions might not necessarily have been made with the best interest of their users/community at heart.” He also lists other reasons including the ease of the build process under Debian.

I had my own reasons for ditching #! last year, primary among them was an issue related to wireless performance that has less to do with distribution base than (IMO based on reviewing many threads relating to certain hardware combinations) getting the kernel’s wifi driver to work correctly with WPA encryption. I reconsidered using it on my new laptop, but instead chose Debian-Lenny (stable) as it was adequate for my hardware and spared me all the hassles of bleeding edge versions that tend to be found in Ubuntu. I’m quite happy with older software that gets patched for legitimate reasons like security, bugfixes, and real features.

For the moment, I’m running Debian-Lenny on both my laptop and desktop. The desktop is basically being used as a server, without X installed (yet). The only other Linux install I have right now is a small 5GB partition on my Aspire One which is being used for TinyCore and MicroCore. I finally rebooted that the other day and used my USB wifi adapter instead of ath5k.

The main reason I’d probably not care to use #! on my computers full time is because it’s using the testing branch rather than stable. I couldn’t care less if it’s set up on a “corporate” base as it was under Canonical/Ubuntu or a more “democratic” base under Debian. What matters more to me is stability. I hate drama. Debian wins that battle over Ubuntu hands-down, in my opinion. The other potential deal breakers for me are the Openbox/Xfce options. I’d like to see something even more basic than those. I may check it out when it’s at a “stable” release, but probably only via USB stick.

I have my own ideas for what would make it lighter, faster, and less obtrusive to the end user. But that’s a subject for another time when I have… well, time.

Another Day, Another ath5k Timeout – This Time TinyCore

August 26, 2009

The goal was to leave the AA1 running TinyCore on as long as possible. The problem has to be somewhere between the ath5k driver, wpa_supplicant, and the 80211 stack. Here’s uname -a, lsmod (note: I was using the TinyCore wireless-2.6.29.1-tinycore_mod.tcem extension so now it’s happened with both 2.6.29.1-based module extensions), and dmesg (with my AP’s MAC masked). This kind of speaks for itself. Again.

Linux pluto 2.6.29.1-tinycore #1337 SMP Fri Apr 10 19:12:39 EEST 2009 i686 i686 i386 GNU/Linux
Module                  Size  Used by
oss_usb                92044  0
oss_hdaudio           127844  0
osscore               509140  2 oss_usb,oss_hdaudio
ath5k                  93848  0
i2c_i801                5280  0
i2c_core                9980  1 i2c_i801
mac80211              106056  1 ath5k
ath                     5228  1 ath5k
cfg80211               49524  3 ath5k,mac80211,ath
rfkill_backport         7656  1 cfg80211
squashfs               11732  0
vfat                    5652  0
fat                    29692  1 vfat
acer_wmi                8984  0
rfkill                  4012  2 acer_wmi
backlight               1404  1 acer_wmi
serio_raw               2240  0
r8169                  18352  0
wmi                     2952  1 acer_wmi
ac                      1732  0
battery                 5976  0
scsi_wait_scan           260  0

13:42pm  up   3:52,  0 users,  load average: 0.28, 0.18, 0.07

CPI: Battery Slot [BAT1] (battery present)
ACPI: AC Adapter [ACAD] (on-line)
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
r8169 0000:02:00.0: setting latency timer to 64
r8169 0000:02:00.0: irq 28 for MSI/MSI-X
eth0: RTL8102e at 0xf808e000, 00:23:8b:0d:68:f4, XID 24a00000 IRQ 28
intel_rng: FWH not detected
acer-wmi: Acer Laptop ACPI-WMI Extras
Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04771/0xa40000
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input5
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
squashfs: version 4.0 (2009/01/31) Phillip Lougher
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 2144636k swap on /dev/sda6.  Priority:-1 extents:1 across:2144636k
intel_rng: FWH not detected
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
 (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
 (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
 (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ath5k 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k 0000:03:00.0: setting latency timer to 64
ath5k 0000:03:00.0: registered as 'phy0'
ath: EEPROM regdomain: 0x65
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x65
phy0: Selected rate control algorithm 'minstrel'
Registered led device: ath5k-phy0::rx
Registered led device: ath5k-phy0::tx
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
mtrr: no more MTRRs available
mtrr: no MTRR for 40000000,800000 found
mtrr: no more MTRRs available
Clocksource tsc unstable (delta = -339460540 ns)
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
wlan0: authenticate with AP yy.yy.yy.yy.yy.yy
wlan0: authenticated
wlan0: associate with AP yy.yy.yy.yy.yy.yy
wlan0: RX AssocResp from yy.yy.yy.yy.yy.yy (capab=0x431 status=0 aid=4)
wlan0: associated
wlan0: deauthenticating by local choice (reason=3)
wlan0: authenticate with AP yy.yy.yy.yy.yy.yy
wlan0: authenticated
wlan0: associate with AP yy.yy.yy.yy.yy.yy
wlan0: RX AssocResp from yy.yy.yy.yy.yy.yy (capab=0x431 status=0 aid=4)
wlan0: associated
wlan0: deauthenticating by local choice (reason=3)
wlan0: authenticate with AP yy.yy.yy.yy.yy.yy
wlan0: authenticated
wlan0: associate with AP yy.yy.yy.yy.yy.yy
wlan0: RX AssocResp from yy.yy.yy.yy.yy.yy (capab=0x431 status=0 aid=4)
wlan0: associated
oss_hdaudio 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
usbcore: registered new interface driver oss_usb
intel_rng: FWH not detected
CE: hpet increasing min_delta_ns to 15000 nsec
wlan0: no probe response from AP yy.yy.yy.yy.yy.yy - disassociating
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 17 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
__ratelimit: 16 callbacks suppressed
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to wakeup the MAC Chip
ath5k phy0: can't reset hardware (-5)

 This is why I reclaimed so much of the hard drive space taken up by CrunchBang. It could’ve been any other distro, it just happened to be CrunchBang/un-buntu at the time I finally had it and decided it’s too goddamn unstable to use on my hardware. This is a driver in the 2.6 mainline and it’s buggy as hell.

Now my only Linux partitions are a very small primary (for /boot) and about a 5GB space for TinyCore. That’s adequate for the kind of use (such as testing other Atheros-related options like madwifi) I’ll have on my AA1 unless I can find a more stable option. And stability really matters — I’ve been using this for work. I can’t justify rebooting and waiting for the fucking card to work again. Fortunately, I’ll have the new laptop by this weekend and it doesn’t have any Atheros chips in it. I’ll run Linux on that and Windows on this.

Why TinyCore

August 26, 2009

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

20090824 Update: Moving Things Around and Adios CrunchBang

August 24, 2009

I stayed up a bit too late last night configuring a few things and moving things around. I still have a bit of work to do to get it working as desired.

I’d already set up entries in my menu.lst to boot {Tiny,Micro}Core. Last night I moved my separate ex-CrunchBang /home around, with the basic files in the same root partition as the rest of ex-CrunchBang and the rest in the FAT partition which holds shared data and is set to automatically mount (/windows) under ex-CrunchBang.

I sorted through extensions to decide which I want to load at boot and which need to go in the “optional” directory (which can be loaded manually). I decided to load wireless-related extensions and audio at boot, along with a few utilities and applications (such as elinks and mplayer, both of which I may go ahead and move to optional). Even with all my extensions loaded, I’m not using much space or RAM — less than I was using in CrunchBang.

After getting things sorted out a bit to my liking, I decided that ex-CrunchBang just has to go — I was very unlikely to use it much anymore — and {Tiny,Micro}Core probably won’t ever need the nearly-20GB’s worth of space on my drive it’s currently set up on. I don’t know how much I’ll even boot Linux, let alone for how long, since I’m so totally freaking distrustful of Linux with respect to the Atheros wifi card now. So the smaller 5-6GB partition I’d set up for CrunchBang’s / will get the 300 or so MB of TinyCore extensions, as well as my persistent /opt and /home.

I’ll use TrueCrypt to encrypt the whole 20-ish GB partition for use in Windows. The only reason I’m going to do it sooner than later is so I’ll have that space for some things in Windows. I’m running out of space and I don’t want to add another TrueCrypt container on my Windows partition; I’d rather move all that data to one partition.

I’ll update again later today (or in the coming days) and explain my setup with more detail.

UPDATE: I decided to check out the Xorg extension for 1024×600 resolution. Tried it first under MicroCore to no avail — I got all kinds of xfont errors. So I tried it under TinyCore. Holy shit at the RAM hit for that: an extra 100+ MB. No thanks. I’ll use my scrunched-up looking screen (1024×768 squeezed and flattened into 1024×600) or run without X (MicroCore).

If it’s going to use that much RAM, I’d just as soon use a standard distro with full utilities (not busybox). Fortunately, the native max resolution of my new laptop is supported by tiny X.

Now I just have to un-do a couple things so I won’t be bothered by the xsetup script when I boot. More later (maybe).

UPDATE2: Had a little time to myself for lunch before a conference call. “Fixed” the xsetup issue (resulting from trying out the full Xorg extension) by copying over /etc/skel/.xsession and then commenting out the line for wbar. Edited jwm theme using the default.thm in /opt/jwmThemes as a starting point (font 7×13). Just realized the resolution is set at 800×600 for some reason. Guess it’s either that or the scrunchy 1024×600 — pick your poison. I also commented out the swallow tags for “watcher” in the jwm tray so now I have less distraction on the desktop. 

screenshot_0824122335

I also moved more things to optional to reduce initial hit on resources at boot. There’s still plenty more I can move there since one of the things already moved is the audio driver package — I’ve tried both OSS and alsa, and moving both to optional lets me choose which I care to use. I think OSS is a bit more bloated and I added a line in bootlocal.sh to mute the internal speaker (which is horridly crappy on the AA1) at boot. Neither package is set up for persistent settings so I need to see what I can do to get my alsa settings to stick between boots. The weirdest part of the alsa package is the default settings, including setting one channel pretty high and the other at 0 for the microphone.

For the life of me, I’ve been unable to get this fucking Atheros card to work from bootlocal.sh or even from my own script. If it’s not one thing it’s another with this piece of excrement — it functions absolutely well under Windows but I cannot emphasize too much how unstable and buggy it remains under Linux. The problem appears to be related to scanning during wpa_supplicant and no amount of sleep up to 10 seconds helped. I wanted to manage it from scripts anyway so I’ve created one for each AP I’m likely to hit today (changing SSID settings, etc., along with different wpa-conf files) and then I start DHCP via alias. WTF, it works, it’s almost as fast, and it doesn’t have the overhead of something like wicd or the issues I had with NetworkMangler (intentional) latching onto other APs before connecting to the ones for which it’s been set up.

More to do: Still some basic set up including seeing what else I want to add to my filelist and sorting out “little things” that annoy me. Need to fix the resolution (again) and see what I can do about fine-tuning the Synaptics pad (need to slow it down a bit and see if I can scroll with the driver/tiny X). Compiling applications and figuring out what I can do about auto-completing aliases (short of changing shells) is also on the agenda. When I find some time. Speaking of which, I’m out of it now.

UPDATE 3: I got everything shuffled around so my {Tiny,Micro}Core stuff is all on one (roughly) 5GB partition and the 20GB partition which had been /home for my CrunchBang install has been converted to NTFS.

adios-crunchbang-recovered-20gb

And that, my friends, ends my little experiment with anything Ubuntu on my hard drive. I’ll write a “debriefing” one of these days and post the screencast I was in the process of making when I lost wifi.

Now I’m down to Windows XP, TinyCore, and MicroCore on my Aspire One. My menu.lst has the usual entry for XP plus several options each for {Tiny,Micro}Core. I’ll also write a more detailed article about this soon.

As far as Windows goes, right now I’m leaving D: (which was /windows in CrunchBang) and E: as they are but I’ll most likely join them together and either encrypt the whole resulting partition or set up a couple bigger containers than I’m using now. The only reason I’d leave them separate like they are now is because the data currently on D: is stuff like multimedia which I want easy access between operating systems.

I haven’t had much more time to do anything else with TinyCore. I’ll see what else I can do in my spare time this week. Hopefully, that’ll include getting it (and/or somethinge else) set up when the not-quite-new laptop arrives.

20090823 Update: AA1, Linux Security, TinyCore, Etc.

August 23, 2009

Quick personal follow up to my previous post about the latest, and probably most extensive yet detected, vulnerability in the Linux kernel.

I’ve been using my own kernel under what used to be CrunchBang. I can’t blacklist certain modules (e. g., bluetooth and IRDA) because I built them into the kernel rather than as modules. Yuck. Back to using the big-ass kernel from the repository if I’m going to use Linux. At least if I’m going to use my ex-CrunchBang install (it’s no longer even close to being what it was originally — from the window manager to the applications to my own kernel and so on).

I haven’t even booted into Linux since last week when my wireless crapped out under Linux again — I’ve had a busy week and this next one will be even more hectic. Right now, I’m not sure if I’ll bother upgrading again because I’m completely fed up with losing wireless and not being able to get it back without rebooting several times. As I noted, the crash and resulting videos came as I was making a screencast explaining why I dislike binary-based distros and their packaging and why I was more likely going to start using TinyCore more often.

Problem is, the same thing occurred one time under TinyCore. The ath5k time-out thing is not a distro problem. It’s a problem somewhere between the kernel/module, possibly WPA, and possibly a couple other things. So I have more than a reason or two to reduce my use of Linux on my AA1. I’m most likely reclaiming the larger partition I have set up for /home under CrunchBang for use under Windows (probably as an encrypted partition) and then using my 5GB partition for {Tiny,Micro}Core.

I’ve settled on another laptop and should have it next week. It’s not new — I don’t think I’ll ever again buy anything new enough that running Linux will be such a pain in the ass as it’s been with the AA1. The more bleeding edge the hardware, the more quirks and utterly stupid bullshit there will be with getting its glorious open source drivers to function properly and in some sort of stable manner. I checked all the specs to make sure Linux will have better support for the next laptop than I have on my AA1 now.

Right now I’m debating between Slackware (13 is almost ready) and CentOS 5.3, both of which have modern-enough kernels to support the hardware in the laptop. The reasons I’d install Slackware are for its lengthy support cycles and so I don’t have to download miscellaneous headers to (re-)compile anything. The reason for CentOS is to have an enterprise-grade distro with enterprise-grade support cycles (as in seven years). After all, I have to use this for my work. I can’t afford to randomly lose wireless (especially if it requires several reboots to get it functioning again) or to have to deal with freezing up when disconnecting the laptop from a projector.

I’m open-minded beyond those two distros. Even source-based since I’m going to have a few days around Labor Day weekend where I can leave it to compile all day long and let it catch on fire or something.

Back to the security issue affecting eight years’ worth of Linux kernels. Is {Tiny,Micro}Core a better solution for problems like this particular vulnerability? In some ways, it may be. It doesn’t come with a full set of modules. You have to install things separately because the whole concept is more modular. The kernel is read-only and in RAM. If someone were able to pwn at the kernel level, you can reboot into a fresh environment because the base system isn’t writable.

The counter to all that is, the more persistency you have for your installation the more vulnerable you are. Most of your configuration files are stored either in /opt or /home, which are read-write. Depending which extensions you use, you may have the same kind of exposure you’d have under any other distro.

And, most importantly, the weakest link in security is almost always the user. You can’t underestimate the problem users cause from clicking on links to opening things to setting up files so that anyone (aka “world” in Unix terms) can write or execute them. Some people ignore permissions altogether or set them up for the sake of convenience — such as other small/live distros that run only as root. I’m not saying that {Tiny,Micro}Core is inherently safer with its use of sudo (I wish more users would accept a default scheme which sets a random password so even running off the live CD or USB would require entering a password before mounting and erasing a drive, etc.).

So add TinyCore to the list with Slackware and CentOS. That may be the fastest way to get it up and running anyway. And TinyCore may be the last remaining Linux distro on my AA1 whether I run Linux on it again or not.

Video: Linux ath5k Reboot (Part 2)

August 18, 2009

Yeah, it so deserves a friggin’ sequel.  This was post-reboot. As you can see, the Atheros device wasn’t even detected in dmesg, lspci, etc.

That meant no scanning, no connecting, nothing. What’s the purpose of a netbook if it can’t fucking network?

As I note in the comments, it took me several reboots this time — and yet again in both Linux and Windows — to re-detect the device and be able to network.

Let me make a disclaimer. I’ve followed the bug reports on this from the first time it happened to me. What is it now, nearly six months? I appreciate the serious effort these people are making to make this device class function under Linux. As of my most recent kernel, though, I think it’s proven to still be at a development-stage and still quite unstable. I don’t recommend using Linux on Aspire Ones or other devices using the ath5k driver unless you have a high threshhold for pain and can live with it stopping suddenly and for no apparent reason like this. Maybe they’ll get it functioning better soon. I hope they do.

In the meantime, I’m faced with either changing cards or using Windows rather than Linux. My AA1 is off warranty in a couple months. I may switch cards before then. Or I may spring for Windows 7. The irony of this is, all of this happened while I was making another screencast demonstrating why I was going to ditch CrunchBang/Ubuntu for TinyCore. That’s when the audio from the stream stopped and I realized I was dealing with this mess again.

Caveat emptor. One man’s “free as in freedom” is another man’s quintuple reboot to get the damn thing to work correctly again.

Video: Linux ath5k Fail (Part 1)

August 18, 2009

I was going to try to work out of Linux all day today. Guess what happened at lunch. I went through another spell with the flaky ath5k driver. Here’s part one.

This is right about the time it happened. My only indication of a problem was the drop of the audio stream. I knew what the problem was right away and this time decided to vent my spleen with some video.

Update 20090817

August 17, 2009

I’ve been busier than expected the past few days. Taking a bit of a break this afternoon to clear my head. Here’s a little update of what’s going on with my computers.

My AA1 continues to be my primary computer, for better or worse. I’ve decided I really need a bigger, faster laptop for full time service. I’m looking at a used high-end business model and also at new mid-level business models now. I’ll probably continue using the AA1 quite a bit since it’s by far the easiest to tote around.

I’m really hard pressed to say I’m still running CrunchBang since I’ve removed a lot of its defaults and replaced them with other things. If anything, it’s more like un-buntu. Nothing against CrunchBang but, even though I think it’s certainly a decent implementation for users wanting less point-click bullshit and less overhead, I think it could benefit from changing window managers and some of the default stuff like the tint2 panel and conky.

I’m still using ion3, which I’ve “fixed” so it doesn’t get full primary use of my function keys. I basically run two “desktops” in it. The first is full screen for well-behaved applications; the other is split so about 30% of the screen is used by the smaller windows of multi-windowed applications like GIMP and Skype. Simple and works for my needs.

I’m also using TinyCore and MicroCore more often but I haven’t had time to finish compiling some of the apps I want. Once I do that, I may enlarge my second Windows partition and reduce the Linux partitions, and get rid of CrunchBang or un-buntu or whatever the hell it is now. I hope to have more to add about all this shortly. {Micro,Tiny}Core is really growing on me.

I’m using NetBSD on my last remaining home server, which I was about to set up as my VPN server. Unfortunately, the server is just about FUBAR. I think the mobo is shot. Regardless, I’m going to scrap it if I can’t figure out if it’s just a bad ribbon cable. It was a rescued MMX box so no big loss. I got a little over a year’s service out of it. I’m thinking of using my old ThinkPad as a VPN server. It’s probably a fire hazard so that could be interesting.

How have I tried to clear my head today? By getting some stuff set up (config files and such) so I can transfer it over to MicroCore, writing a script, etc. I’ll do a separate posting on all that this week. Maybe a video, too, to show the speed and efficiency of console applications and how they can be integrated to work together.

Addressing More Search Engine Hits

August 11, 2009

Here’s another post addressing search engine hits to my blog.

To the person hitting on “error installing xubuntu,” I couldn’t agree more. Installing Xubuntu is a very serious error! Fortunately it can be corrected by installing something else. I recommend any other distro, but if you insist on an Ubuntu-based distro give crunchbang a try.

I keep getting sporadic hits looking for microcore screenshots. You know what it would look like? A console. You boot straight into a prompt that (if you boot without user= and/or host= cheatcodes) looks like this:

tc@box /:

Do you really need a screenshot to decide if you want that? It would seem to me that people who don’t want X shouldn’t need a screenshot of a prompt. It would also seem to me that anyone using MicroCore with the intention of a full X extension would appreciate the fact that the TinyCore screenshots are MicroCore+X screenshots. Duh.

Today was the first time I had a hit about how to use an AA1 as a keyboard for another computer. Ummm, via ssh? That would certainly do it but the AA1 is a computer not a keyboard.

Finally (for now anyway), I’m getting a stream of hits for searches related to ath5k problems. I’m using kernel 2.6.30.1. There’s been no changes to ath5k in the changelogs up to current (2.6.30.4) and no significant changes to the 802.11 stack, either. I try to limit my Linux use to less than three hours per session but I still lose function of the Atheros wifi card. It’s a pain in the ass and one of the reasons I continue to dual-boot with XP (never had any problem with the Atheros card under XP except that the problem persists between boots after it crashes in Linux) and am strongly considering upgrading to Windows 7.