Archive for the ‘Scientific Linux’ Category

More Scientific Linux AA1 Notes – Hardware

May 4, 2010

Overall, I’ve been satisfied with the decision to run Scientific Linux on my AA1. Here’s a quick run down of the hardware on the AA1 and what is known working under SL54, as installed from the live CD (Gnome version):

  • video – X was properly configured and has been flawless
  • audio – zero issues, headphones jack works properly, external microphone works (note: mp3 codecs installed from live CD)
  • onboard microphone – works properly
  • Synaptics mousepad – set up out of box to include tapping and scrolling
  • left-side SD card reader – SD card must be inserted at boot to function, but then it can be hotplugged, etc. (have not tried right side reader but have no need for using two SD cards simultaneously)
  • USB ports – no issues (note: USB card adapter works if user forgets to insert SD card in left reader at boot)
  • video out – functions properly
  • suspend, hibernate, resume – no issues yet
  • wireless – I have yet to have any weirdness I’d experienced previously with more recent kernels (ath5k + WPA, etc.)
  • Acer onboard functions – everything I tried has worked, including disabling the Synaptics pad, adjusting audio, and adjusting screen brightness (haven’t tried disabling wireless via the switch on front)
  • power-related events – the Gnome battery monitor works and properly notes when the AA1 is plugged in, on battery, or is nearly discharged and needs to shut down; everything functions as set up for events like closing the top (on power it remains on, on battery it suspends), etc.
  • webcam – I installed Skype and can report that video is clear and crisp in Skype’s tiny resolution (haven’t tested beyond that but no need to since I only need it for Skype)

As you can see, there are a few things I’ve yet to test — in addition to those mentioned above, I’ve yet to try a wired connection but I presume that should be flawless as it’s commodity hardware which is well-supported. One thing which hasn’t worked out of the box is the wireless LED. I can live without it.

As far as additional distro-unsupported software, I’ve installed Skype’s latest beta (2.1.0.81) and Opera 10.10. Both work properly. I wasn’t going to install Opera but I decided to do that and continue to use the supported version of Firefox.

Let me also note there are other means of testing and installing Scientific Linux. In addition to the Gnome version of the live CD, there’s another “light” CD which uses icewm and lacks some of the things found on the Gnome CD (including wpa_supplicant) and a DVD that includes both Gnome and KDE. Both the live DVD and Gnome live CD also have icewm. Additionally, there’s the traditional CD set and a net install image from which a user can install SL 54.

For what it’s worth, there are also “flavors” of SL from the different labs using it. These are tailored for their particular system needs but they do show movement towards the 5.5 release for Scientific Linux. Yesterday (May 3rd), SL-CERN 5.5 was released. The main SL 5.5 release is still showing on mirrors as “beta 2” (as of April 30th). Hopefully new SL55 live images will be up very soon.

I still haven’t set up printing, but CUPS detected one of my older printers right off the bat. The one I want to use, though, will require an update of HP’s driver as the version in the repository will not work. The software side of it, though, has proven rock-solid — just as one should expect.

The software versions also keep me on a level playing field with the rest of my computers, which is mostly all Debian Lenny. I alluded the other day that I’ll have another lengthy post; it deals with my recent reassessment of my computers and what I run on them. I hope to have that up soon. I’m also going to update (as in cut and paste this stuff) my AA1 page shortly to repeat a lot of this and also note a few tweaks I’ve made (and need to make) and other stuff.

Finally, really big thanks to Steven Rosenberg for the kind plug about my blogs and SL-related entries.

UPDATE: I started updating my Aspire One page earlier this (Wednesday) morning. I should have the rest of it filled in sometime later today when I can get the rest of my notes together.

Update 20100501 – SL54 on AA1, Etc.

May 1, 2010

I’m going to try to post something this weekend I’ve been working on for a couple weeks now. It’s somewhat related to some of the stuff I posted earlier this week about a certain site’s review of a certain distro, but different. It’s ironic in a way because I’ve been re-evaluating my hardware and operating systems again (I’ve actually had time for that the past couple weeks) and have been investigating a few things. That included my own posts last weekend about Scientific Linux on my Aspire One see if there was a chance that a more stable approach to things (specifically ath5k timeouts) might mean I can again run Linux on my netbook.

I installed SL54 live (Gnome) last night on my Aspire One. It went on a smaller partition I’d set aside for {Tiny,Micro}Core, which I’d pretty much stopped booting into on the Aspire One since I was plagued by ath5k timeouts. I had no issues last weekend during my various tests, which included leaving the thing running for lengthy periods of time (previous experience indicated timeouts would occur within six hours), bombarding it with traffic including HD streams (which it handled well even running off USB), and testing how proximity to various routers would affect wifi performance. The only thing holding me back was awaiting a road map for release of SL 5.5; I decided to not wait. The pending release of RHEL (and CentOS and SL and so on) 6 plays no role in my decision — I’ve downloaded the public beta and may install it on something, but probably not the netbook (I have an uneasy feeling about the changes to the networking stack between 5 and 6 given all the trouble I’ve had with more recent kernel versions). The fact that SL 5 will benefit from updates until at least 2012 means I don’t have to worry about updating to a major release just for the hell of it.

The installation went smoothly. I already had appropriate partitions set up (the live CD installs on one partition, so others can be added manually later) so it was a matter of letting the installer do its work. It correctly installed GRUB (I was going to not install it since it was already installed but I had no intention of using TinyCore on the AA1 so it seemed more logical to let SL control GRUB and menu.lst since it would change with updated kernels, etc.); I was impressed that the installer running off USB allowed me to choose which drive GRUB would be installed (unlike other installers which only installed to sda even if that was the USB stick due to boot order). Then I set up my user account (and deleted the default sluser account and group), added myself to wheel and added that group to sudoers via visudo, and updated the system. I recall over fifty updates. Then I adjusted services and applications to suit my needs.

I still have some work to do with it yet, and I still have to decide if I’m adding a separate /home partition. It’s there if I want or need it, but it’s currently being used as an encrypted partition under Windows. For the time being I won’t need to worry about storage because I’ll be using it to shell in to other computers hosting my files (that also mitigates any need to edit a 21.x-compatible .emacs or compile the latest stable release since I can shell in and use what I have on another machine). And browsing, etc.

More soon. Maybe. I have some work plus some other things to take care of this weekend. Hopefully I’ll get to finish that post I mentioned above.

Distrowatch Reviews Suck A$$

April 26, 2010

It’s sad to see how far the standards at Distrowatch have fallen. I didn’t always agree with Caitlyn Martin (particularly her views for Vector and against Slackware — I realize new users want to be able to install without reading any documentation but Slackware isn’t difficult, burdensome, or too nerdy to install) when her reviews would appear at Distrowatch, but at least her standards went beyond appearances, themes, and other trivialities.

Today’s review abortion doesn’t disappoint if your primary criterion for a Linux distribution is style rather than substance. The target is Scientific Linux, which I’ve recently written a good bit about because I was testing it out on my Aspire One.

The reviewer started with some prattle about his presumptions about (against, rather) SL and that it’s a niche/specialty distro. That couldn’t be further from reality. It’s simply recompiled from RHEL sources — much like CentOS is — but with more of an emphasis on packages relevant to research. That’s to be expected as it’s the product of FermiLab, CERN, various universities, etc., where end users are less concerned with games, default themes, and so on, and more on applications relevant to their work.

The reviewer then notes SL’s “website is a simple display of black and white in a Wiki style” and “is fairly quiet, almost sparse in its presentation.” Yes, and what’s wrong with that? It’s very straightforward and informative. It’s not put together to entertain prospective users or “reviewers” who are drawn to aesthetics over performance.

It doesn’t take long for the reviewer to fall into his own tedious comfort zone in how he rates distros:

The theme is really where the system shows its roots and its age. The distribution is, after all, sitting on a 3-year old platform. Some may find this an unpleasant trip into the past while others will probably enjoy the comfort of familiarity.

In fact, he later in the review adds, “The version of GNOME which comes with Scientific is 2.16, which is a few years old. This may be good or bad, depending on one’s point of view.” Why the hell would it be bad if it works, doesn’t crash, doesn’t hog up too many resources just to make stuff wobble, etc.? This whole issue is moot to enterprise users — remember, the release and support cycles for RHEL (and its clones) are measured in years rather than months. This distro can be used on newer hardware but is still a valid and working solution for hardware being used at the time of the 5.0 release — as well as older hardware. Most distros consign older hardware to the scrap heap, which is why businesses and researchers don’t use them in production. Why the hell would they want to use something which makes 2010 presumptions (multicore CPUs with GB of RAM) for 2005 hardware (which may not even have 512MB of RAM)?

The reviewer’s mindless obsession about default themes is a common thread in the reviews he’s had at Distrowatch. He doesn’t seem to appreciate the distinctions between an enterprise-grade distro and all the other bullshit he’s attracted to because of “pretty” themes with bleeding-edge versions of every possible piece of software. Never mind those other distros are buggy as hell and unsuitable for use in environments where RHEL, CentOS, SLED, and SL are going to be used.

He then notes the live CD’s installer “may seem primitive compared to other installers” — even though the installer for the real CD set uses anaconda, the same installer used by RHEL, CentOS, etc. Maybe if he’d read the site instead of criticizing its lack of entertainment value he’d know the difference and maybe chosen to do a conventional install rather than use the live CD (though I’m quite content and satisfied with the live CD’s installer myself).

The review drones on to note that a default user account — which happens to be sluser — is set up. The reviewer didn’t note that the tools are in place from the live CD/install to manage multiple user accounts, including removing sluser. Instead, he criticized the version numbers of the applications: “Most of the applications are fairly standard, though their version numbers tend to lag a bit behind the latest and greatest.”

What this dumbass doesn’t realize is that those “version numbers” include patch level numbers. So that kernel 2.6.18.xxxx has had many improvements backported from official versions >2.6.18. The same is true of many of the applications included. In addition to security patches, there are legitimate feature patches. Does that mean everything is bleeding edge? No. But people who need an enterprise-grade operating system aren’t looking for bleeding edge — they only want stability and security. An enterprise distro — SL/CentOS/RHEL/SLED — delivers stability and security without pretenses or without delusions that the most recent version of anything is necessarily “the greatest” version of it.

The review continues with high praise for inclusion of YUMEX (a graphical front-end to yum; I’m not going to be as judgmental as I should be about preference of using such things over command line tools), Flash, and various audio codecs. He regrets certain video codecs aren’t included. The reviewer also left out the fact that anything else a user may want can often be found in third-party repositories; one of the benefits of being (mostly) binary-compatible with RHEL 5.5 is that there are alternative repositories that will (mostly) work in CentOS and SL just as they do in RHEL. Perhaps he just didn’t know any better. Regardless, that’s something which other users might consider noteworthy. (The qualification of “mostly” is warranted since packages between repositories can be built with different dependencies which will break when using too many repositories. Two can be too many if their bases and dependencies are unmatched. There are ways to manage conflicts via yum. The point remains that users can set up additional repositories for SL and thereby access a wider selection of software packages.)

He winds down his review by not being able to find many flaws aside from its age:

The only drawback, so far as I can see, is that some of their key components are getting out of date. Usually this isn’t a problem, except perhaps, when using software like OpenOffice.org and Firefox. Those projects which put out major releases once a year or more will appear dated.

This ignores the fact that relevant patches are given for security and to fix issues as warranted. That inlcudes OOo and Firefox. Enterprise users aren’t going to care that the distro in question — RHEL, CentOS, SL — is tied to release cycles for various projects the way, for example, Ubuntu is tied to Gnome’s release cycle. To enterprise users, the difference isn’t measured in release numbers of software included in a base or repository but rather in the stability of the whole paradigm. Using such a benchmark, Ubuntu is not even comparable. That explains why so few businesses, researchers, government units, etc., use Ubuntu but do use RHEL, SLED, or the clones of those.

I noted in one of my own posts about SL, “I’ve gone back and forth between OOo 2.x and 3.x recently and, aside from formatting changes in 3.x that don’t work when backing down to 2.x, I don’t think enough of 3.x to demand that whatever distro I use have it available.” I really don’t think most users would even know any difference, particularly since few users will avail themselves of any features contained in the newer versions. What’s left is being on the cutting edge for the sake of being on the cutting edge.

That’s fine for some people. But I think Linux reviews shouldn’t try to fit every distro in that same basket. A reviewer should actually understand the underlying paradigms of a distro and judge according to those rather than to “it’s too old” or “it’s not pretty enough” sham criteria. It’s a disservice to readers — not to mention to the developers working on their distros — to lump them all together and, by way of flawed benchmarks, make them rise or fall according to aesthetics and/or version numbers.

Distrowatch’s reviews are utterly predictable because they focus only on those two elements. If you use a flashy theme and enable wobbly windows by default, you’re likely to get a good review. If your distro requires more than clicking buttons to do things, isn’t terribly flashy, or is targeted at stability rather than being on the cutting edge of application release cycles, you’re going to be compared to the distros with paradigms 180-degrees from your own.

I saw that happen with DSL. I’ve seen it happen with Slackware, TinyCore, and OpenBSD. Now I see it with CentOS and SL, too.

Sadly, Distrowatch is among the worst at pulling that crap and reviewing every distro according to one slovenly-conceived set of criteria. Reviewers whose focus is on style rather than substance don’t seem to have much substance themselves.

UPDATE: Surprised at the traffic this post is generating since it hasn’t been linked anywhere (by me anyway). Yes, it’s the same hare-brained reviewer mentioned in other posts in my Scientific Linux and OpenBSD categories regarding GnoBSD who complained that the BSDs don’t automount every freaking piece of storage you insert in your USB ports by default and that the process in BSD is  difficult. I responded to that in another post here. I don’t know why any Linux distros include man pages since the vast majority of users — and especially distro reviewers — obviously can’t bother reading them.

In any event, I noted only two pieces of software in the SL base (from the CD) that I’d update: emacs and hplip. The reason I’d update hplip is so my printer would work. The reasons for updating emacs are probably more selfish: I don’t want to track down packages like org-mode and others which are now included in emacs and so I wouldn’t have to change anything in my .emacs file. But like I wrote in one of my SL-related posts, I’d be just as happy using emacs 21.x (again). Either way would take some effort on my part — either I compile emacs (trivial) or I hunt down the things I currently have set up in my .emacs and set it all up again (less trivial but acceptable). Big freaking deal.

Finally, I need to clarify that SL’s repositories — and the install CDs — have a wide variety of software beyond scientific/research kinds of applications and third-party repos aren’t necessary to use SL as a “normal” distro. You don’t have to enable third-party repositories to have a usable system. The software contained in the live CD (Gnome version) is adequate for most users with an adequate mix of commonly used software including browser, e-mail client (thunderbird), file manager, media player, and so on.

UPDATE 2: I meant to add above that SL (and RHEL and clones) is hardly alone in using “old” release numbers. I’m currently using my laptop at home which has Debian Lenny installed on it. My OOo version is almost as ancient as the one used in SL. Not complaining — WorksForMe (and odds are it would work for everyone else whose not too obsessed with version numbers to actually get stuff done).

Blimey! I don’t see an expiration date on it! Maybe the dipshits at Distrowatch will give Debian a crummy review because its stable branch doesn’t have the “latest and greatest” version numbers like Fedora or Ubuntu. Whatever. At least it works and the developers aren’t pissing people off by little things like moving buttons around. The result is that Debian-stable is stable while Ubuntu seldom is. That’s the price users have to pay for being wedded to bleeding edge software and the ever banal paradigm that places style over substance. And for relying on Distrowatch reviews for accurate and fair reviews.

SL54 Live – The Overnight Test Results

April 19, 2010

This is part three in my series on running Scientific Linux on my Acer Aspire One and testing ath5k wifi for timeouts, which plagued my use of Linux on my AA1 to the point that I ultimately chose to only use Windows XP on it. Part one is here. Part two is here.

Just a few quick notes from where I left off, which was that I probably wouldn’t do yet another update. I booted from USB again with a SD card inserted and can now verify the left side card reader works. I didn’t bother testing the one on the right side, but the left one works in standard Linux form: if a card is detected at boot, it works; if it’s not inserted at boot, it isn’t detected and doesn’t work.

Moreover, after reinserting the card after unmounting it, it again auto-mounted (grrrr) and was correctly identified as coming from a camera and I was prompted to see if I wanted to import the photos. I chose no and if (more like when) I install I’ll make sure to change the setting (in Gnome: System – Preferences – Removable Drives and Media; then click off the relevant boxes in the dialog) so it doesn’t auto-mount stuff like that.

So, how did well did wifi perform in a little overnight test? Very well!

It’s been up about 14 hours as I begin to write this without any crazy wifi issues I endured previously. In the above shot, the line count of dmesg rose nine lines overnight; those messages relate to authenticate and reassociate with my router. I also kept count of lines in /var/log/messages relating to noise floor calibration timeouts. There was only one overnight and it didn’t miss a beat.

That’s not to say there weren’t any scares overnight. I noticed a few times that the audio streams I was playing had stopped. Each time I looked, though, I noticed there was no loss of my wifi signal to my router — perhaps the problem was with my Internet connection or with particular streams (two of them were coming from the same service). Each time I was able to get back on Firefox, find another stream, and play audio. I admit I was surprised each time. I was expecting it to do what it’s always done.

The benchmark for pass-fail is not very high in this instance. I can’t recall an uptime greater than six to eight hours under any of the previous Linux distros I ran on my AA1, certainly not with any of the later kernels (> 2.6.26?). I don’t know if suspending and resuming helped or hurt that, but I know if I was trying to work and had it on for significant periods of time it would eventually crap out on me and persist through reboots (into both Linux and Windows — which really, really shouldn’t happen).

Again, I don’t know if the problem is specific to the driver, the 80211 stack, or even wpa_supplicant. I get frequent hits on this blog about such timeouts related to ath5k like those I experienced and wrote about here. It’s clear from some of the search terms that other Aspire One owners have had this issue, but I suspect it could be wider-spread and, thus, beyond one of the suggestions that it could be an AA1 design flaw or something. I couldn’t accept that because the problem is specific to Linux — never has happened in Windows, and the only times it’s affected me in Windows is following a reboot after it failed in Linux. I also read the developer lists and noted there were many reports of similar issues. Some blamed “noisy environments” and others seemed to pin it down on changes in wpa_supplicant. I couldn’t narrow it down to my router because it happened at home, at work, at my in-laws’, and seemingly everywhere.

Regardless of what the issue is, I’m quite pleased that Scientific Linux proved much more stable in my little overnight test than other distros have done in much shorter time frames, including trying madwifi instead of ath5k. Nothing worked correctly.

Off and on the phone while writing this, but I’m right now at 15 hours uptime on the AA1 with SL54 running off USB. Wifi is still working without floods to dmesg indicating any trouble at all. It’s performing like it’s supposed to. I also know that most of the hardware seems to work properly and was properly detected and configured, even to the quirks/tweaks for Acer-specific hardware.

I’m also more comfortable with the focus on stability and security rather than on rapid development changes (I’ll have a post about that soon). There are only a few things that I’d want to update myself — cups, emacs, etc. — but most of the rest I can live with. I don’t know how much the lengthy release cycle will mean because I don’t see myself holding onto it until 2014. But who knows.

I actually feel comfortable enough to install it, and I was secretly hoping for a quick fail on this so I’d have no reason to not sell it (or give it away). I probably can’t install right away because I haven’t even looked at how much space I have available (what was left for TinyCore is very small because I’d had so many problems with wifi that I didn’t see ever installing anything else on it) and if I might need to shrink and/or combine Windows partitions. Also as I noted yesterday, SL 5.5 is now in beta and should be released very soon (dittos CentOS, which I haven’t ruled out yet). I haven’t decided if I’ll wait for it to hit -release but the release may happen before I get around to installing unless I find more time in the next week or so.

UPDATE: I left SL54 running on the Aspire One all day since it wasn’t needed. Used it a couple times to surf, and I also streamed audio (doubles as a test to make sure it still has a wifi connection). It just hit the 24-hour uptime mark. Look at that wifi icon — that’s all you have to know. It worked.

The only extra lines related to wlan in dmesg pertained to reassociating with the router. Dittos my tail of /var/log/messages, which showed only one floor calibration message early this morning (noted above, IIRC). I never felt any warmth in the area of the palm rest where the card is located that would indicate it was overheating in some manner.

I figure if it’s good for 24 hours of uptime without any drama, it’s probably going to be good enough for longer. Hopefully I’ll find some time soon to install it, maybe even before SL 5.5 hits -release status.

Day Two SL54-Live/USB on Aspire One

April 18, 2010

I rebooted my Aspire One early this morning from XP to the USB stick with Scientific Linux 5.4. It’s now approaching the three-hour uptime mark; I’ve usually experienced ath5k timeouts and losing detection of the card altogether in the two- to four-hour range.

I have a few things to update about what I wrote last night. I didn’t need to install anything to listen to streaming audio or individual mp3 files. My first “test” was hitting magnatune’s classical page, which had an embedded player ready to go. I could hear the music as soon as I hit the page.

Not only that, but you can see the box with the audio icon in the screenshot. I can now vouch that the Acer system audio setting adjusted via the function key works out of the box. So, too, do at least some of the others including disabling the touchpad and adjusting screen brightness.

Maybe this attention to detail is why the more “stable” distros appeal more to me than the others. I mean, you have time to get things right when you’re not tied to a six-month release cycle. I read some of the recent entries on Steven Rosenberg’s CLICK blog the other day which had screenshots showing how Ubuntu’s latest beta (10.04) was full of daily surprises, with changing window controls and version downgrades due to bugs.

I think RHEL/CentOS/SL/Oracle get a bad rap by the “hobbyists” when it comes to version numbers (more on that below), but in absolute fairness Red Hat (and those built off of it) patches for new hardware, for improvements and bugfixes, and for adding legitimate features. The kernel in SL54-Live shows up as 2.6.18-164.1.el5. It’s really more than adequate for my — and most users’ — needs. What gets rushed out to meet a timeline for certain distros results in users having to fill in the details; enterprise users expect and receive a bit more than that (especially when it’s derived from a for-profit enterprise; last time I checked, Red Hat was profitable and Canonical was still trying to figure out how to monetize Ubuntu).

Anyway, since I knew I had audio working correctly out of the box I hit shoutcast to find a nice jazz stream. Upon clicking the link for Sky Smooth Jazz, I was given a dialog prompt to open in the default movie player. I selected it and waited for the stream to cache.

It worked without a hitch right out of the box. As it should, eh? I tweaked the settings quite a bit to see how much RAM I was clogging with the changes. That might be unfair since it was running off USB (I do have a swap partition it’s using, though).

Next, I wanted to see if it had flash or a substitute included so I checked about:plugins in firefox. It showed that libflashplayer.so was indeed installed, so I went to youtube.

So far, so good.

I then turned my attention back to hardware. I didn’t check the base application list to see if there was anything with which I could test the webcam. I did note it was detected in dmesg and the proper uvc driver loaded for it. I just tried to hotplug the SD card that was in my camera to see if the left-side internal reader would work; dmesg showed nothing and it wasn’t auto-mounted. That’s hardly a surprise since the only way to get it to work is to boot with it inserted (fortunately, USB card readers work — if only Acer had installed one card reader on these things and added another USB port or two). Synaptics mouse works correctly, and tapping and scrolling are enabled by default.

I suggested above that “hobbyists” wouldn’t appreciate the paradigm at play in such a distro, particularly when it comes to version numbers. This isn’t a hobbyist distro, though. I already noted the kernel is patched. So are the applications. Gnome is shown at version 2.16. It may not be as fancy as the latest version, but it’s rock solid. It also has some of the standard Gnome desktop software including gedit, games, and all the gnome-whatever things that are supposed to make things easier for users.

OpenOffice.org is version 2.3. It works quite well and most users won’t miss any of the features in 3.x. I’ve gone back and forth between OOo 2.x and 3.x recently and, aside from formatting changes in 3.x that don’t work when backing down to 2.x, I don’t think enough of 3.x to demand that whatever distro I use have it available. If emacs had a mode that could convert muse/TeX documents back and forth to MS Office formats, etc., I wouldn’t even care if OOo was installed.

Speaking of emacs, that might be something I’d upgrade to at least -current so I wouldn’t have to track down various things now in emacs which I take for granted. My .emacs is set up for 23.x.

I suppose I could live with 21.x. Again. I did check and gnuplot-mode is installed. For what it’s worth, gnuplot –version shows 4.0 patchlevel 0.

I’ve been keeping an eye on dmesg, looking for ath5k messages, while writing this post. I’m also running tail in a window to see if something shows up in /var/log/messages. The line count I’m paying attention to in dmesg hasn’t changed in a while (dmesg | grep wlan | wc -l). I see system messages every half hour in tail that show NetworkManager is handling and completing supplicant connection handshakes. Fingers crossed.

I’m going to let this thing run while I go running, and beyond if it will. If wifi doesn’t flake out on me as it has with everything else, I’m going to install it. I don’t know if I have enough room since I cut back on Linux partitions (just enough room for TinyCore plus my home directory) so I may have to do some reconfiguration if that happens. And then I may not sell it or give it away even though I know I should (my hands are just too big for it and the screen is too tiny).

Updates to follow if and when I see that ath5k has timed out…

Update: Had to deal with issue for work so I’m just now heading out to run. I’m now past four hours uptime with SL54 Live on my Aspire One, trying to see how long it will take before wifi crashes. As you can see in my messages tail, there was one noise floor calibration time out at a little over three hours uptime.

That’s markedly different from some of the things that have happened in the past, like this crap:

I’ll try to update this at least one more time today to give a final uptime before I accept that it actually works. I have my fingers crossed. Heh.

Update 2: Shit! Instead of crossing my fingers I should’ve plugged the freaking power cord back in. I was walking out of this room when the audio dropped off so I ran back to see if it was due to wifi crash, then I saw that it was already suspended because the battery was almost drained. The good news is the audio kicked right back on as soon as I plugged it in, so wifi was still working and wifi resumed immediately from suspend — not just good, very good. The bad news is I didn’t have it set up to suspend/resume correctly (especially since it only has a little swap partition to use) so I got it back without video. I went ahead and shut it down because I wasn’t going to pay close attention the rest of today anyway. I’ll say uptime was probably close to 4:40, which is pretty good. I may try again later (overnight), or some time this week.

One thing I didn’t comment about earlier: When running other distros with newer kernels and presumably newer releases of wpa_supplicant, the right palm area on the keyboard would get warm very fast. Since that’s where the wireless card is located, it could’ve been some kind of issue where it was over-cycling (but I can only speculate). The same thing has never happened in Windows. After a few hours uptime in SL54, that particular area was cool/warm — much cooler than it had been under the other distros. I think I’m going to try one more long-uptime test (like I wrote) and make damn sure the thing doesn’t overheat or timeout or get weird like it has before under Linux. Only this time I’ll do it overnight so it stays plugged into the AC adapter.

Update 3: I should’ve pointed out in the paragraph about “attention to detail” that I still prefer to be able to set things up myself when it comes to which services start by default and so on. The comparison in that regard is about distros where I’ve had to go into /etc/whatever and add tweaks to get things to function properly because the distro spent a lot more time on aesthetics than setting up hardware config scripts.

The point about such things as peculiar hardware settings for certain models being detected and properly functioning is also different from something installing and starting various services — wanted or unwanted — by default. For example, I didn’t attach my Bluetooth adapter at any point that I ran SL54 last night or this morning yet I had modules loaded for it and services running. The same is true for other things like CUPS, or (my biggest peeve of all) auto-mounting. Some of that is a little more forgivable for a live CD where use could be more “promiscuous” rather than tied to one particular computer, but not when it gets installed to hard drive.

I already know I’ll have things to disable if I do install SL54 (most likely from the Gnome live CD), not to mention compile. I already know I’ll have to compile a newer version of hplip, as I mentioned last night, to use my HP printer. I also know RHEL just updated to 5.5 and Oracle is the first derivative to release a matching 5.5 release (technically version “5 update 5”) and I’ve seen some preliminary announcements at CentOS for testing and QA so I’ll look at the RH changelogs and see if that’s patched adequately for my needs okay, it doesn’t appear to be patched and CentOS doesn’t appear to be close to releasing 5.5. I also looked an the SL rolling release’s note indicates it’s at “Beta 1” as of April 15th.

Anyway, before I install SL (or CentOS) on the AA1 it’s going to get more testing to make sure I really don’t have any more wifi problems. SL (and CentOS) should be at 5.5 by then. Probably no more updates here until then.

Update 4: I managed to do a complete overnight test so I did another update.

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.

Update 20100209 – Debian Lenny, TinyCore, emacs, ratpoison, oroborus, and security of small distros

February 9, 2010

AA1
I’ve intended to sell this thing but haven’t yet. I updated my AA1 page last week to reflect the fact that I really don’t run Linux on it anymore. I still have {Tiny,Micro}Core set up on it, but I’ve booted that maybe three times in the past few months including once this morning to get my emacs-related files. I don’t know if the issues with wireless were related to the network stack, the ath5k driver itself, wpa-supplicant, or a combination of factors. For the last time, it’s NOT a hardware issue because the problem never happened (meaning started) under Windows; it only happened (started) under Linux and persisted after rebooting. I occasionally boot TinyCore from a USB stick on my other computers (see below).

New Desktop/Workstation
It came with Windows XP Pro installed. I first installed Scientific Linux 5.4 via the live CD, which provides a Gnome desktop. I’ve already posted about adding an old hard drive that had OpenBSD 4.3 on it, on which I installed NetBSD 5.0.1 after backing up $HOME. I’ve been too busy to even update SL54 (which I know has updates because I was also running it on my new-old laptop for a while), let alone configure NetBSD beyond the basics (e. g., setting up my network card even though it’s not yet networked, SSH, etc.). I’d hoped to set it up further this past weekend but I’ve been eye-deep in a stack of reports to edit and charts to generate.

New-Old Laptop
I’m still using Debian Lenny, which I installed using net install. I let it go ahead and install the default Gnome desktop even though I initially thought about just doing a minimal installation and adding what I wanted. One of the reasons I did that is because life has been so hectic the past 18-24 months that I care a lot less about bloat than I do about the convenience factor and having everything ready to roll. Otherwise I’d already have the other computer set up and ready to roll, no?

I have switched some apps around, though. I was using xemacs but decided instead to revert to GNU emacs 21.4 from backports so I’ll have more of the modes I’ve come to take for granted and which require either finding via apt or from their developers. I’m posting this now via weblogger.el (which I’ll have to clean up later) from within emacs. I’ve also installed oroborus and am using it instead of metacity within Gnome (edit ~/.gnomerc to include a line “export WINDOW_MANAGER=oroborus”); this is RAM-sparing to some degree but not nearly enough. I already have ratpoison installed as well, and will more likely than not start paring down on the Gnome bloat as I find time. I’ve been running ratpoison mostly under another user account.

Other Computers
My ancient ThinkPad got a minimal install of Debian Lenny several months ago but hasn’t been booted in at least a month. I may use it for TinyCore. Or as I’d intended with Lenny just to be a temporary HTML/blog server for home use. I may just use MicroCore if I do that.

Nothing to report on my old MMX box. I haven’t booted it in so long I don’t even remember what it has on it.

Unfinished Business
Speaking of {Tiny,Micro}Core, I started on a screencast/presentation back before Christmas that I alluded to at least once here. I’ve been too busy to finish it. It’s in response to a question that was asked at the TCL forums about using TCL as an enterprise Linux replacement. I wanted to demonstrate beyond the more obvious answers why I thought it was unsuitable and worked out a quick and dirty concept to show how vulnerable such a distro — based basically on one file — could be. This kind of goes beyond the security of the image being read-only and, accordingly, being able to reboot into its original state; instead, I wanted to see how difficult it would be to take advantage of the fact that the image is on a read-write partition which can be mounted by user tc locally or remotely and then replaced. My little POC requires user interaction at this stage (which was in maybe 20 minutes’ work) to basically get a corrupt image to replace the original so that each subsequent booting of it isn’t actually the “pristine” original tinycore.gz image but instead the corrupted one (which could have any variety of “reconfigurations” in it, but mine basically pings another computer when it has an IP and has a message stored in a file stating what changes have been made to the original image).

I haven’t decided if I’ll go through and see if I can get it to work remotely without user interaction. Even if I do that, I won’t post it here. Sorry, kiddies.

Since these small image-based distros typically lack logging facilities, it would be trivial to pull this off and possibly leverage vulnerabilities in various packages to further make a mess of it. The smaller the distro’s base image, I think the less noticeable it would be. With my download speed, I can download the TinyCore image in just a few seconds.

Also, I tested this on USB. It’s trivial to test if something has been booted from sd{a,b} and contains a directory named boot containing a file called tinycore.gz. The same applies to other small distros which similarly use one file to store the operating system, allows full sudo (or, in the case of some like Puppy, root only), etc. Even though something is running from RAM, it’s still found on a storage device attached to the computer and can be mounted (unless it’s quickly removed). So I don’t think this is inherently more secure than anything else (or inherently secure at all), and the smaller size could be a disadvantage since it would take less time to download and be less likely to be detected by most users.

As improbable as it is that such things can be accomplished without some kind of user interaction or physical contact with a USB stick to install a corrupted image, it’s still possible. Add in potential vulnerabilities from various packages — including browsers, improperly set up servers, etc. — and the possibilities increase both locally and remotely.

No, the sky is not falling, but there is a potential for risk even though the image itself is read-only. The image may be, but its partition isn’t. The risk may be acceptable for most uses. It isn’t acceptable for enterprise use — not without some kinds of safeguards that enterprise distros have to help reduce problems like this from occurring.

I’m not knocking these small distros. I think they have a special niche, but too many people think they can be one-size-fits-all. Enterprise-grade distros — including RHEL and its clones, SLED, etc. — have a variety of safeguards that would be “bloat” in something designed to be small and minimal. Adding those things to a minimalist distro would seem to be counter to their very purposes. That includes everything from security enhancements to logging facilities (you really do want to know who logged into which computer at what time on what day, and having every user named “tc” can’t be of much use if you need a chain of custody for various computer records, file records, changes, etc.). Moreover, the packages or extensions these small distros offer typically don’t undergo the same level of testing as in enterprise distros, are more often than not bleeding edge rather than tested and stable versions, and aren’t signed. Even signed/trusted repositories aren’t free from trouble as the RedHat/Fedora people found out a couple years ago when their mirrors were compromised.

I’ll see if I can finish the presentation and get it posted soon. Then again, I thought I would’ve had that done a month ago. Stay tuned.

Update 20100130: Musical Hard Drives, NetBSD, Scientific Linux

January 30, 2010

I’d alluded last weekend that I’d installed NetBSD on a spare hard drive in my new workstation. That drive was the last (I think) OpenBSD 4.3 install I had before I had to go care for family in 2008. Hard to remember anymore, I only know that when I ran last it showed my last reboot was a couple days after I returned last year. Anyway, I’d already installed Scientific Linux 5.4 on another spare hard drive I put in the workstation and set up separate partitions on it. My only nitpick about SL’s installer on the live CD version is that it doesn’t allow many options as far as partitioning or filesystems but that’s not a big deal to set up afterward. (Note: the full install/net install CDs use anaconda.)

I switched drives around so my old OpenBSD 4.3 one would be master. Once I logged in (after finally remembering my root password and changing my user password), I looked around and saw a few things I wanted to make sure I backed up before using that drive for something else. I added entries to my fstab for the other drive so I could copy them to my user account on it (that drive is eventually going into another computer; sorry about image quality but I didn’t have the computer networked when I set up).

I recently said some unkind things about the reviewer of a NetBSD-based live CD on a certain website because he complained that it didn’t automatically mount things for him. The BSDs — excluding possibly desktop-oriented projects based on any of the BSDs — don’t enable such things by default. I also recall in a simulated install of KDE packages one time that directions flew up my screen about enabling various daemons to get it all working if so desired. It’s just a different perspective on things. The BSDs are true to their Unix roots, and Linux distros by and large are true to their “GNU’s Not Unix” (heavy emphasis on “not”) roots. Let me be a little more constructive than I was at that website and show how easy this stuff is (especially if you bother to read the documentation).

I installed NetBSD from CD. The installation took a few minutes. Granted, it’s not like installing the average Linux distro — it doesn’t have a graphical installer, it doesn’t have all kinds of apps to install. It’s pretty basic, but you add what you want on top of it instead of whatever some developer decides to include. It’s fast, it’s easy (RTM), painless. It takes a bit of time to configure and set up but it’s a blank slate and you’ll know exactly what’s going on because you’re the one turning all the stuff on that you want to be on.

I wanted to get my files I copied over to the SL54 drive from the OpenBSD install so I decided to set up /etc/fstab to include my SL54 drive. The first command I ran was dmesg | grep wd1 to make sure the drive was detected as wd1 (the next step would tell you the same thing but I usually look at dmesg first). Then I did disklabel wd1 to get information (man disklabel if you want specific options) about the partitions on that drive.

Once I had that, I could edit fstab accordingly and/or mount the partition I need. In this case, the partitions I wanted were g and i and I needed to make directories (mkdir /mnt/wd1{g,i}) for them and then mount them. Then I was able to get my stuff I’d copied from my old OpenBSD install as well as the few things I’ve had time to get on the other SL54 drive. Hardly a hassle.

I haven’t had time to do anything else with that drive (meaning with NetBSD) yet because things are hectic with family and work. Funny how that works out sometimes — get a new computer, fiddle around with a couple of hard drives, and then have to get back to them in a week or two or three (I’ve only been using SL54 on it). For what it’s worth, I’m very pleased with Scientific Linux 5.4, which is compiled from RHEL5 sources. I’ll write a review of it soon — and probably before I get back to setting up NetBSD.