Gentoo Development Weblogs

Here some ideas about alternatives and gentoo possible alternative implementation (refer to Diego's post):

- implemented as an eselect module, possibly with an alternatives interface for those who like it
- will work just on executables you directly run
- it will be backed by an eclass to handle post-inst/post-uninst (registration and removal to the alternatives list)
- it will use the environment, a separate config dir, a C wrapper [pick one or all]
- the wrapper will check his argv[0], look at the config dir for the string to call and run it.

Probably even those 5 lines have conceptual bugs but I guess that's enough for a draft.

lu

As some of you may know, I built some versions of Claws Mail for Mac OS X. However I didn't keep them up-to-date with the latest Claws version, nor the latest Mac OS X versions, shame on me !

However I had good reasons, and when you'll see the next version that I'm currently trying to build, you'll see why...

So stay tuned !

My AMD desktop workstation is dependable. It's always worked like a champ, with nary an issue. Until now. Now, I'm getting issues in spades.

Let me direct your attention to bug 221145, which contains the details of my woes. It started out as a simple (apparent) kernel issue, in which the newer libata subsystem can't be used with my IDE optical drive. I'd been using the old IDE subsystem. libata is supposed to work for SATA and PATA devices alike, so it should work with the IDE controller on my nVidia MCP55 chipset, right?

Wrong, apparently. Ah, but this was only the tip of the iceberg. Turns out that it's not just my kernel (or whatever it is), but my applications themselves aren't working with the drive. Especially gstreamer-based audio apps, and Gnome audio apps. Totem, Decibel, gnome-cd-player, and a few other gstreamer-based apps I briefly tried. Nope, none of them can play audio CDs. Or DVDs. The really weird thing is that they can see the media in the drive. Decibel will recognize the disc ID, get the info from CDDB, load up the tracklist, but then refuse to play the individual tracks. It doesn't really believe they exist. gnome-cd-player is hardcoded to look for /dev/hda apparently, and can't be changed to look for the correct drive.

It gets better. I switch to the 2.6.25 kernel, and now some CDs have a few playable tracks. But I can't play anything past track 4, or track 9, if I'm lucky.

The woes continue: I bought an Asus SATA DVDRW drive off Newegg, which I installed this morning. It seems that it'll use the same sata_nv drivers that my SATA hard drives use, so no kernel changes needed. Reboot the machine, fire up Decibel, and . . . you guessed it. Track info can be fetched, but nothing will play. So I tried booting with "libata.dma=1" appended to my kernel line, as suggested in the bug, but nothing changes.

This is really weird. A native SATA device that can't work with libata. Not an IDE device masquerading as a SATA drive, but the real deal. At least my SATA hard drives still work. Did I not get some memo on nVidia MCP55 chipsets not liking SATA drives? Or that the kernel code for 'em may not work? Or something.

I'm at my wit's end. If you've got any ideas that haven't been covered on the bug, I'm all ears.

* * *

In other rocks and hard places, I did have Xubuntu on my old Toshiba laptop for a coupla weeks or so. Installation went smoothly, but man . . . Synaptic is slow. Same for the Gnome apt frontend. Remember, this thing ain't for me, it's for my wife, so going to the commandline for packages is forbidden. Anyway, I spent two rather disappointing weeks trying to slim it down into something with better performance. I'd wanted to go for a lightweight WM-only environment, instead of the default Xfce. But Xubuntu is just too bloated; it's far too much work to trim down everything. As "light" as it is, compared to vanilla Ubuntu, it's still not a good place to start building a small system.

So I ended up installing SliTaz, as a new "cooking" edition was just released. Man, SliTaz is nice. There's no support for wireless, unfortunately, but that's about my only quibble. Oh, and there might not be essential Toshiba-specific packages available; I couldn't get working internet, so it's hard to tell. But still, I mentioned a few months ago that SliTaz was the most impressive of all the distros I'd tried, and that's still the case.

I may give it another shot, but in the mean time I've been downloading more ISOs, getting ready for the next batch of testing and reviews.

Coming soon: Damn Small Linux, Linpus Linux Lite (seems to be optimized for mini-laptops with specs not much better than mine), Shift Linux, OpenGEU (E17-based, which apparently performs better than the last time I tried it a few years ago), and another stab at NimbleX and Zenwalk.

Assuming, that is, that I can ever get my stupid optical drives to work. CURSES.

So a few days ago fiefox-3 was pulled in during the regular system updates, and after a few hours of using it I must say: it sucks even more than firefox-2, which IMHO was already a regression from earlier versions. Actually I think that since they changed the name from phoenix my user experience has gotten worse with each new version. Now I have to admit I'm probably not a typical user, so firefox-3 might be an improvement for the majority, but I'm really fed up with it.
As neither konqueror (kde-centric) nor opera (binary-only) are alternatives for me I looked out for other broswers out there today and noticed Arora, a new qt-webkit based browser and decided to try it out. And I must say I really like it so far, though I've only used it for a few hours so far. It feels a lot like older firefox versions, just without much of the "user-friendly" bloat they've added over time (e.g. the new fancy addressbar in firefox-3). It's still a very early version, so obviously it's lacking some features (like no flash support, though I consider that more as a feature ) and probably has a few bugs, but at the moment I like it (much) better than what has become of firefox.

I'll stay for about a month in Japan, till the latest I was too busy and not so sure I'd make it so I avoided blogging about this till I were sure.

Hopefully I'll have another great time hurrying from a city to another (Hiroshima and Sapporo will be the southern and northern cities I plan to visit) and I'm looking forward to meet the local gentoo community again (I never thanked you enough).

I'm not sure how I'll be able to get a reliable network link, but I think I'll find a way ^^.

Alternative distros

In the last few weeks I've tried Arch Linux, Zenwalk, and Myah OS.

Arch is mostly the same ol' Arch it always is -- I used to dual-boot it with Gentoo on my old laptop, but I won't be moving to it at any point. It used to be hell on wheels for installed boot times, but now it's slower than many liveCDs. And like Gentoo, it takes a lot of initial configuration. Too much, I discovered. I don't really mind setting up things by hand, but the tools to do so need to be easy to use. Whether this means graphical applications or command-line tools (such as rc-update, which is one of the best selling points of Gentoo), they need to make system configuration quick and straightforward. Arch doesn't have much in this regard. Also, several packages that I consider essential to the light desktop I'll be building are only available as source packages. Binaries only, please. If I'm going to be spending at least as much time configuring and installing stuff on Arch as Gentoo, I may as well just install Gentoo.

Zenwalk's 5.2 release shows much more promise than the last version I tried. Except for the small problem where wireless networking won't work, that is. And I ended up not being able to finish installation or get a bootable desktop. The installation process heated up the CD drive to the point where the media started to become unreadable; packages on the CD would fail their checksums. When the machine was cool, there were no such issues. My laptop almost overheated to the point of shutdown. Once I finally got it to install several tries later, it couldn't boot -- the Lilo screen came up (ugh, Lilo) and tried to boot into Zenwalk, but then the computer reset itself. Repeat ad infinitum. Scratch Zenwalk.

Myah OS is a fairly promising new distribution that offers a "Box" edition built on LXDE, which looked to be perfect for my needs. Unfortunately, it comes with compiz by default and no real support for my GeForce 2 Go graphics chip; Myah includes only the unaccelerated "nv" driver, which is a real POS. So it sticks a heavyweight window manager into an otherwise decent desktop environment. Way to go. Fortunately, openbox is an option, and a few other window managers and desktop environments are available once you have an installed system.

Package selection in the installed environment was quite decent; lots of good, fast apps. LXDE (as configured by Myah) isn't the speediest desktop I've ever used, but it was acceptable. Unfortunately, wireless networking simply will not work. I couldn't figure out if this was because of the stone-age initsystem (and an equally antiquated config layout), or if it was the fault of ath5k. I've never used a kernel with ath5k before now; Myah ships with 2.6.25.2. Up till now I've just used madwifi, which works well. Whatever the cause, I could never get my card to initialize, much less see networks.

Package management is also a cast-iron bitch; the thing uses a weird mix of xterm output and a gtk frontend. The frontend fires up an xterm window with output in the background, but they're both slow as molasses. The frontend is extremely difficult to navigate; you first have to choose whether you want to add, remove, or update packages, then proceed through category menus and select individual packages. Stepping forward or backward through each window is a laborious process, forcing multiminute waits as the installer does whatever the hell it's doing. It's like it's fetching package information via the internet at each screen, and then executing a hell of a lot of code at each stage. Really, I've no idea what was going on under the hood. I just knew that it was a profoundly dissatisfying experience. Scratch Myah -- but I'll look in on this project in the future. It could be going places.

What's next? Well, I downloaded Xubuntu 8.04, so now I'll try a distro that's known for having "easy" configuration and management. Sure, I'll be getting an Xfce desktop (which is in itself too much for my laptop) further bloated with lots of Gnome cruft, but I figure I can use it as a decent base for getting a better environment. It's a lot better than starting with Ubuntu's Gnome desktop. There seem to be packages for everything I need so far.

Alternative desktops

I've also recently switched my workstation's desktop from Gnome and Firefox 2 to gnome-light and Firefox 3. The latter necessitated moving to the former, as right now, too many packages force dependencies on Firefox 2 and/or xulrunner-1.8. Plus, now that I'm on gnome-light, I've discovered the joys of unmerging Epiphany, Evolution, sound-juicer, and sundry other miscellaneous bloat. I've also given up on trying to use Midori and webkitgtk. While I appreciate that both are now in Portage, Midori is just too broken to consider using as a worthwhile browser, even though its rendering speed (thanks to webkitgtk) is second to none.

Besides, the primary advantage of Midori was its integration with my desktop environment. Now that Firefox 3 is installed, it blends in as a proper gtk app. And it's faster than 2.x; Gmail and other AJAX sites load much faster. I must say that I'm impressed with its overall speed despite my initial pessimism over the inclusion of a fricking database (sqlite). I still regard it as so much unnecessary bloat, since I have absolutely no use for all the new bookmarks features, but maybe someone out there will get some good from it.

Gentoo

In other news, we're looking to release 2008.0 final soon, after dealing with lots of security updates and miscellaneous fixes for the snapshot. What's this mean? To new users, it means a newer set of packages will be installed than what's on the beta2 CDs. To current users, it means nothing at all. Gentoo isn't like other distros that force you to reinstall or upgrade your entire system at release time. Releases are made solely to update the installation media -- CDs, stages, etc. -- to bring them up to date.

I've sent in the final documentation tarballs to the rest of the releng team and updated the tentative release schedule with the info provided by Chris, so now I can focus on finishing up the next issue of the GMN. There's one article in particular that I'm excited about, so stay tuned . . . it's coming soon!

I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. One of these days, I'll find a distro that properly supports ACPI and VGA-out. I hope.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz.

In the second article of this series, I tested Linux Mint 4.0 Fluxbox Community Edition.

In the third article of this series, I tried Puppy Linux and antiX.

Now it's time for DeLi Linux.

DeLi: the good
DeLi Linux is specifically designed for older hardware, and declares it will only use lightweight software. Good news so far. I actually seem to have working hardware support for both CLI and X session. For most distros, I get proper screen blanking and automatic fan control only during a console session; once an X session is started (and/or HAL, that damned dirty animal) the fan kicks in and can't be turned off. And neither can the screen. But DeLi succeeds there.

DeLi: the bad
The 0.8 liveCD is actually just an installer; there's no try-before-you-install desktop environment. And it's an ugly installer. It's probably the absolute worst installation experience I've ever had, for any operating system.

For starters, though you can partition your hard drive however you like (indeed, the installer assumes you've run fdisk ahead of time), DeLi will use just one partition for everything. Also, it insists on ext3; other filesystems aren't an option. As if that isn't bad enough, it forces a complete format of the whole partition. None of the usual 5-seconds-to-mkfs.ext3 quick creation found in every other distro. Oh, no. It went sector-by-sector, bit-by-bit for my entire 60GB disk. Yeah, thanks.

You already have a completely formatted ext3 partition? (Perhaps from a previous DeLi installation attempt?) Too bad. There's an option to skip this step, but this just ends the installation process immediately. You're forced to format the partition if you want to proceed.

And it comes with the ancient and user-unfriendly Lilo bootloader. I'm a grub man, and I felt like control was being taken out of my hands. Fortunately, lilo installation to the MBR worked correctly, so it boots properly.

The installer is, surprisingly, even more painful to get through than the old curses-based Ubuntu installers, worse even than Fluxbuntu's installer. The DeLi installer is an arcane mess. Instead of doing all the initial user-specified configuration up front and then waiting for the automated install process to finish, the DeLi installer treats you to the sit-and-wait game, complete with extremely scattered bits of user input followed by long waits and progress bars that don't actually move. The user config bits are the worst, as once you select an option, there usually isn't an obvious way to move on to the next screen. Take the keyboard maps and language selection screens. I picked en_US, and hit enter. Nothing happens. Huh? Scroll back up to the top. Nope, nothing there. K, let's go the other way. Way down at the bottom, dozens and dozens of language selections later, is a single button for the next step, but get this, it's pointing backwards, as if to say "go back a step, because you screwed up, genius!" I dunno if this is leftover from some right-to-left version, but it ain't nice, considering the installer is written in English.

Also, I realize that, as a Gentoo guy, I may not have much room to talk about "sit-and-wait" installation methods, but hey, at least with the CLI-based Gentoo install, it's a busy activity. You can run much of the install in parallel, on different terminals, excepting a few critical steps. Also, assuming you have a working network for the minimal CD, you can always do stuff online. You're not forced to babysit the install process. Well, not the same way, at least. Plus the Gentoo install is scriptable. It's possible to get it started and then walk away.

Not so with DeLi -- this thing has to be monitored constantly, so that you can deal with the elusive bits of user input.

DeLi: the ugly
The installer is a chore, but the real work lies ahead. For starters, I had a rough time getting a (semi)working desktop. IceWM was installed, but there's no X session started by default. Good thing I know how to setup ~/.xinitrc on my own. Also, several services that I take for granted, including net, GPM, and pcmcia, weren't started by default. Not nice. As a "desktop" distribution, all this should have been setup ahead of time.

I could do it the manual way, or I could use the delisetup tool. This is a CLI app to configure things like keyboard, language, lilo, network access, X server, WM, mail, package installation, and local services to run at boot.

Unfortunately, it's buggy as hell. Though it seems to remember the last items selected, it doesn't actually do anything. No real configuration changes were made, and yes, it's properly run as root. Also, the "mail" and "services to run at boot" sections crashed the app entirely, with no traceback or error output. "Install additional packages" seems limited only to installing inetd, gpm, coldplug, net, pcmcia, and a few other basic daemons. Basically, the things I thought I'd already dealt with during installation.

Okay, so how about the rest of the desktop/CLI experience? Slow and glitchy. Both console and X are filled with constant, irritating flickering, when entering commands (and especially tab-completion), and during scrolling output. The X session is no exception. I've never used a slower IceWM setup, ever. My laptop can run Gnome from a liveCD faster than whatever setup DeLi uses for IceWM. It's also replete with flickering and excrutiating slowly redrawn windows. Opening up the ROX file manager is an exercise in frustration. Moving it or resizing it is even worse. Same goes for the hideous stock xterms. If you're going to ship plain ol' xterm (instead of something like aterm, urxvt, or Sakura), at least give it a different color scheme and something besides its default eye-gouging fonts, okay?

The included webbrowser is NetSurf, and it actually comes up fairly quicky, considering the poor performance of everything else. Same goes for the email client, Sylpheed. Unfortunately, they can't access the internet, because the delisetup configuration tool doesn't work. Also, despite manually starting up the appropriate initscripts and manually configuring my system for DHCP, I still can't get net access. Chalk up another failure for DeLi where every other distro succeeds here.

While on the subject of daemons, initscripts, and config file locations, DeLi is a bit weird. It feel like it took the most failtastic parts of Slackware and Arch Linux. Which is weird; both those distros on their own do much better.

DeLi does include pacman (from Arch) for software installation, but it's no good without a working internet connection. Too bad; despite installing everything available on the CD, there's hardly anything there. Sylpheed, NetSurf, xterm, ROX, Gnumeric, Abiword, ePDFview, and GQview. That's it. Oh, and an unnamed calculator. That's a bit too minimal.

But it's not like I'm able to actually do anything with this system. Time to close down this DeLi.

Coming up: PCFluxboxOS, Damn Small Linux, Arch Linux, and possibly even NimbleX. Stay tuned.

I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. One of these days, I'll find a distro that properly supports ACPI and VGA-out. I hope.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz.

In the second article of this series, I tested Linux Mint 4.0 Fluxbox Community Edition.

Now, I'll sum up my impressions of Puppy Linux and antiX.

Puppy Linux is a homegrown mini-distro with several different flavors available. It's well-known for being lightweight, able to run entirely in RAM even. It's also the distro that has introduced me to several different applications I've never heard of before, including some CD burning programs. A fair amount of the applications and configuration utilities available on the liveCD are written specifically for Puppy; they're definitely newbie-friendly, and seem to be especially focused on Windows-to-Linux converts.

So, let's talk about the CD itself. It had just about the fastest boot I've ever seen, wasting no time to get me into a JWM environment, which ran quite speedily. It loaded itself into RAM by default, and provided a handy panel applet that displayed free memory available. Unfortunately, it was rather broken in my case; it showed that I had at least 512MB total memory, and that Puppy was using about half that. Oops, not quite -- I only have 128MB installed.

Still, the CD had quite a nice selection of packages; it's amazing how much was crammed in. It came with the Seamonkey suite for internet access (and for HTML editing). I was a bit worried about this, as the ol' discontinued Mozilla has always felt bloated to me in the past. Not so in this case; Seamonkey ran better than the typical Firefox on every other LiveCD I've used. It felt like an embedded browser, actually, in terms of quick response. Puppy has the most comprehensive array of packages I've come across on a mini-LiveCD so far. There's even a CD remastering tool available, similar to the one SliTaz offers. Want your own Puppy variety? A few clicks will do it!

However, Puppy's support for ACPI and the other necessary bits of my laptop wasn't working in the slightest. I opened up a root terminal to start loading modules, but ran into tons of "module not found/does not exist" errors. I checked /lib/modules to verify that the ACPI-related modules I was looking for did in fact exist, but they still could not be found. What's up with that?

Puppy has a lot to offer, and like SliTaz, I'll be watching it closely in the future. but for now . . . no way to turn off the fan o'doom or get dynamic CPU scaling means this Puppy is going back to the pet shop. Next!

I gave the MEPIS-based antiX a try simply because a reader mentioned it in a comment on one of the earlier articles. It definitely sounded interesting, so I downloaded the "base" edition and got to work.

It booted reasonably fast, and dropped me into a pretty SLiM screen. The liveCD has both IceWM and Fluxbox, so I went with the latter. The "base" CD was indeed quite minimal. Though it ran speedily enough, much better than most other distros I've tested so far, it didn't come with much in the way of software. Most menu entries were to plain ol' xterms that launched some CLI application or another. There's not much in the way of graphical configuration apps, and there's nothing resembling a real power/ACPI manager.

Which brings me to the biggest failing of antiX: it doesn't have working ACPI or APM for my Toshiba. Sure, the toshiba_acpi kernel module can be loaded, but I can't do anything with it from there. Can't turn off the blasted fan, nor did CPU speeds ever seem to vary as needed, despite opening the antiX control center and checking the appropriate box.

antiX has promise as a lightweight distribution; it's speedy enough, but it can't handle the hardware. So long, antiX.

Coming up: PCFluxboxOS, Damn Small Linux, DeLi Linux, and Arch Linux. Stay tuned.

Currently we have packages like sun-jaf that are reference implementations for a JSR and have since been incorporated into the JRE (>=1.6). So before introducing Java virtuals ebuild developers had to either depend on sun-jaf or a new enough JDK version. Tomcat used the java5 use flag to select between the two options. This of course is not ideal for users and as such we added support for virtuals into java-config. We are still in the early stages of converting stuff to virtuals and let's see how it takes as the work is quite boring. Any way here is a demonstration of the jaf virtual in use:

betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.5" java-config -p jaf
/usr/share/sun-jaf/lib/activation.jar
betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.6" java-config -p jaf

betelgeuse@pena ~ $

jaf was introduced in 1.6 so in the first case you need the separate package and in the second case there is no point in polluting the classpath with extra stuff as we already have it in the JDK. On the ebuild side you use the same functions as with normal packages but you have to add the --virtual parameter to java-pkg_jar-from and java-pkg_getjar calls so that they don't record individual jars.

If you're using portage-2.2_pre6, portage-2.2_pre7 or trunk you must install portage-2.2_pre7-r1 ASAP to rebuild the NEEDED.ELF.2 files that were corrupted by some subtle bug in the pre6 and pre7 ebuild.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz. I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. Of the three distros I tried, I was most impressed with SliTaz.

I took Linux Mint 4.0 Fluxbox Community Edition for a spin yesterday. How did the second Ubuntu-based distro do?

Worst-performing LiveCD ever.

And I mean ever, on any hardware I've had to use. Even booting a Gnome-based LiveCD and running Evolution and OpenOffice on this old laptop showed better performance. Booting Ubuntu 5.04 on my wife's ancient iMac G3 (128MB RAM, CPU about 400mhz) took less time than Linux Mint did.

Linux Mint offers the standard Ubuntu-style bootscreen, followed by an etremely long boot time. There was no way to get detailed boot messages or status, just a splashscreen with a bouncing progress bar. Fluxbuntu at least had the usual function key for verbose boot. The only indication I had that my laptop was still working for the 5 minute bootup was the constant thrashing of the CD drive. Fail for transparency -- I need to know what's going on during the boot process so I can tweak it for my system later, if need be.

Once the graphical desktop was loaded (another 6 minutes), the CD thrashing continued. At this point I was worried about what it might be doing to my drive, but grimly pressed on. Supposedly the LiveCD was using the existing 512MB swap partition on my hard disk, but not very well, as performance was abysmal. Also, just like Fluxbuntu, the annoying fan never turned off.

Desktop load times were further increased because of a couple of panel applets. The first sucked up bandwidth and CPU usage dialing out to find software updates ("1 update available;" who cares since it's a LiveCD?!), and the other took awhile to examine my hardware and tell me "1 restricted driver available." I assume this was for the integrated nVidia graphics chip, but I didn't bother trying to install either update. The functionality is nice enough, I suppose, but really shouldn't be activated in a limited-resource environment like the LiveCD.

Mint contains a minimal Fluxbox environment, with a single desktop "Install" icon, presumably provided by iDesk. Alone among the distros I've tried so far, Linux Mint does not by default display a more practical panel like FBpanel, Perlpanel, or Pypanel. However, in the Fluxbox menu there was an entry to start FBpanel. Why couldn't that have been already running, replacing the extremely limited Fluxbox toolbar? I clicked it, and discovered why. It took 8 minutes to load. Eight minutes to launch FBpanel, fer cryin' out loud. FBpanel is known for being tiny and fast; I had no problems with it in the other distros. The Mint panel starts up on the bottom of the screen, right under the Fluxbox toolbar. Fail for positioning; they shouldn't both occupy the same space.

I poked around the Fluxbox menu to see what was available. Linux Mint offers its own toplevel menu, laid out mostly sensibly by the developers. But for some reason, the menus generated by Fluxbox are also available at the bottom, and those are confusing as heck. The one nice thing is that the application name was displayed, rather than just "Picture viewer." Fluxbox's generated menus were quite poorly designed; it would have been better if the developers had left it out, in favor of their own menu. The generated Fluxbox menu had the most application entries (though poorly laid out, in multiple submenus), the Mint-designed menu had fewer listings, though better organized, and the FBpanel menu has the fewest entries, though it's the layout most familiar to Gnome and Xfce users.

Software selection is okay; the filemanager seems to be Rox, but I couldn't get it to actually load. Several minutes of disk churning, and then things went back to normal. At least OpenOffice isn't bundled with Linux Mint; who knows what that would have done. The Xfce Terminal is included, but its performance is just as piss-poor as the rest of the apps on the CD. Took 3 minutes to launch and get to the prompt. Now, even under load, when running Terminal on my old laptop, worst startup was around 10 seconds. It's a little unusual that they picked a terminal emulator that requires several Xfce runtime dependencies, when similar apps like rxvt, aterm, and eterm are available.

Having had enough of the poorly performing LiveCD environment, I decided to give the "Install" icon on the desktop a shot. Maybe it won't behave so badly once installed, right? Double-click.

Fifteen drive-thrashing minutes later, there's still no sign of the installer. Clearly it's trying to load something, but what--oh, look, the screen went blank. It was still backlit, so I'm not sure if it was trying to load a fullscreen installer or a screensaver or what. Wait, wait, wait some more. It never came back up. I put it down as "more retardedness," and decided to hell with this. I powered off the laptop the hard way. Oh well, it's not like there was any data on the hard disk. I wanted to throw the CD-RW across the room, but I still need it for the other distros.

If I'd been manually reinstalling Gentoo, I would have been at least halfway through at this point.

The verdict for Linux Mint: fail. A solid 0 on any scale. Not recommended for any machine, really. Especially not old hardware. Linux Mint 5.0 is currently in beta status, but even if the Fluxbox edition is updated, I doubt I'll ever try it again.

Coming up: PCFluxboxOS, Damn Small Linux, Puppy Linux, DeLi Linux, and Arch Linux. Stay tuned.

Those who read my previous post know that my number one concern these days is disk data integrity. As disks become bigger and cheaper, their uncorrectable error rates are not improving. That and the other failure points in the chain tempt Murphy to come out from behind the curtain of denial. It's getting scary (read my last post for my experiences with this).

The current mainstream Linux filesystems do not address the problem: ext3 does no checksumming, and ext4 adds only journal checksums (but not data block checksums). Your data is still vulnerable to silent corruption.

Sun's interesting ZFS filesystem had seemed like the sole bright spot on the horizon, but the licensing issues that prevent its inclusion in the Linux kernel are disheartening - we cannot just sit and wait for that to change; and we don't have to!

There is a new game in town that has a lot of promise. It comes from Chris Mason at Oracle, and it is called "Btrfs". I had noticed this project a few months ago, but I did not entertain the idea of trying it because it seemed to be so far off in the future - a great idea, but not anywhere near usable. Well, either I got the wrong impression, or things have changed. Quite a lot of Btrfs works, and in my limited testing, it works damn well. It seems quite fast too, compared to what I experienced when trying out ZFS-FUSE. Btrfs is in the Linux kernel, you see, which gives it a big performance advantage and allows it more access to the hardware as well.

Recent Googling revealed that not only are people giving this new fs a spin, but there are already assorted ebuilds out there in various overlays (not surprizing, since building Btrfs and its utilities is a snap). I quickly cooked up my own ebuilds (for the kernel module and the utilities), and they are now in Gentoo:

sys-fs/btrfs
sys-fs/btrfs-progs

There are some actual kernel source patches available out there (the ebuild provides a separate module), but at this early stage it is probably more handy to be able to insert Btrfs in any kernel and be able to upgrade it separately. Now, please note that there is a big warning on the Btrfs site (which I also put in the ebuild):

WARNING: Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized.

So yes, it's experimental, and upgrades can change the disk format (meaning you'll have to re-format and re-populate). So call me crazy: I created a big partition and copied my 104GB home directory to a Btrfs filesystem, and I'm playing with it now as I type this. I will be keeping very recent backups, of course, but this is really very cool. I figure I need to put myself out there and help by giving it some serious testing.

I won't go into details about what Btrfs offers in terms of features (just visit the site), but it appears to be aimed directly at ZFS's feature set while better fitting into the "Linux way" of doing disk management. The big thing for me is the data checksumming - not having this feels a little like flying blind with no safety net. I am really excited that something is being done to address my number one issue. Go Btrfs!

Almost a year ago, I wrote a series of articles called "Distribution Checklist," parts 1, 2, and 3. The articles pose a series of questions to be answered when trying to decide "Which distribution is right for me?"

I wiped Gentoo off my old Toshiba laptop a couple of nights ago, and have been trying out binary distros with a smaller-is-better philosophy. The laptop has anemic I/O, and only 128MB RAM (nonupgradeable; the socket is fried).

I need a distro that is lightweight, mostly self-contained (if it can run from RAM, all the better), yet also has a decent package repository for the edge cases, like Toshiba hardware support utilities. I'm planning to turn the laptop into a useful secondary work environment for my wife. She'll need to run presentations from it, so there needs to be an easy way to get the VGA-out and/or TV-out working. No commandline intervention should be required to do anything.

So far I've been through Fluxbuntu, TinyMe, and SliTaz. Of the three, SliTaz shows the most promise.

First up is Fluxbuntu. Fluxbuntu is quite dated; latest available is a release candidate for 7.10, from October 2007. For an Ubuntu-based distro, it didn't have hardly any configuration tools. Also, booting takes forever, as others have noted. Well over 3 minutes.

While trying to install useful apps, I got my first hands-on experience with Synaptic, and, well, I definitely didn't think much of it. The button labels are not at all intuitive, nor is it especially obvious how to go about actually installing a package or series of packages. A button marked "Install" would have been appreciated ("Apply" means what to the new user?). And a more up-front list of packages to be installed would have been helpful. Perhaps it was just Fluxbuntu's particular config?

In addition to the package manager interface, the rest of Fluxbuntu wasn't exactly userfriendly, and I'm used to Fluxbox. The odd setup & configuration and poor preinstalled packages were enough for me to wipe the Fluxbox install. No PDF or image viewers. Ugly gtk1 audio player (XMMS). Oh, and seriously, preinstalled OpenOffice? With Rox? OpenOffice for a "featherweight" distro. Right. Ugh, Rox. I prefer something intuitive and attractive, such as Thunar, PCmanFM, or Nao.

Another annoyance was that even after installation (terrible; it seems to reuse the very first Ubuntu Warty installer), hardware support for my Toshiba was nonexistent. Even after installing apps that are known to work on Gentoo, such as tosh-utils, fnfxd, and the like, they just wouldn't work in Fluxbuntu. Something was interfering with the fan utilities; the noisy fan ran constantly. Also, the CPU never seemed to idle; it was constantly at full speed. Excessive heat and noise. Felt like the distro was fighting the very tools I installed to take care of it.

Fluxbuntu was toast after just one day. On to TinyMe.

This one is based on PCLinuxOS. Its main attraction was its lightweight claim to fame. It comes with a decent assortment of packages, for a 300MB or so download. However, even though it's running Openbox, it feels rather bloated. Both the TinyMe Control Center and the PCLinuxOS Control Center are slow to run. They're good ideas; they offer the configuration options Fluxbuntu lacked, but they subscribe to the KDE philosophy of control: multiple similarly-named (also badly-named) apps that do more or less the same things. Lots of redundancy, so wading through them all was a bit of a chore. Also, networking steadfastly refused to work, despite throwing all my Gentoo-learned command-line tricks at it when the graphical utilities failed. Ironically, I got further in wireless config than I did with the basic Intel PRO/100 wired adapter. It picked up my Atheros PCMCIA card as soon as I ran the configurator; a few clicks and it prompted for the WPA key of my home LAN. That was the only bright spot in the whole thing. CPU usage was uncomfortably high, while RAM usage was decent, staying between 37 and 56 percent with Opera and a couple of other windows open. Something was making my CPU work too hard to do anything useful though, so TinyMe came off. It just feels like a waste of a (potentially) good environment.

Next up: SliTaz. This one has been making waves at the review sites and distro centers because it's reputed to have the world's smallest desktop environment, weighing in at only 24MB. That's a tiny download, though if fully loaded into RAM it'll occupy about 80MB. That's pretty good for everything running at once.

I first tried SliTaz Cooker, as even though it's "unstable", it's more recent than the 1.0 release. It had more interesting features, such as using Openbox by default instead of JWM, and it has a graphical package manager. Also, more of it is in English. However, the Cooker LiveCD kept freezing up at "Preparing initramfs", so I switched to the 1.0 stable release.

This was the best-running LiveCD I've ever used. Fastest, too. I was surprised at how well-configured the environment was, and it had a nice selection of apps. There's some stuff we don't even have in Portage! LXDE, burning apps, etc. I was able to use my wired NIC out-of-the-box, which meant I could get live updates to the CD via Tazpkg, the rather nifty package manager. SliTaz includes a great tool to roll your own LiveCD variant: either what's currently installed, pre-configured alternative images available from the central server, or you can specify your own config files separately.

Alone among the three distros I tried, SliTaz seemed to properly work with ACPI, spinning down the laptop's fan when temperatures were low. I didn't even have to tell it to load the few laptop-related kernel modules at the commandline, either. It has pretty basic hardware support, but SliTaz lucked out and actually got my Toshiba right, something the fatter LiveCDs couldn't do.

It seems like every small and light distro these days is using slightly customized LXPanel, and SliTaz is no exception. Probably just as well; FBpanel and perlpanel are dead. Still, LXPanel provides a fairly configurable, useful panel. I prefer it to the standard toolbar in Flux and Openbox. It's basically a reverse Xfce setup. I like to run just one panel though, because of extremely limited screen real estate. Too bad you can't right-click on the bottom panel to configure or delete it. Couldn't find a way to put the launchers and the window list all on just one panel. But it's still relatively early in development; maybe with increased usage we'll see more features added.

The rest of the desktop is nice enough, though all the red wallpaper is a little wearing on the eyes. Also, I couldn't find a GUI configurator for font hinting. In the past, Gnome and Xfce have provided everything I need to get my fonts just right. I can't be arsed to hand-edit config files for this, Gentoo developer or not.

The app selection is great overall, but Firefox is an (un)fortunate choice, because while it's familiar (I use it on my other machines), Kazehakase or webkit-based browsers would have been somewhat faster options.

My only real problem with SliTaz is that it doesn't install. It freezes about halfway through the "copying packages" stage. Hard lockup. Have to reboot. Also, the 1.0 stable installer is written entirely in French. It's mostly noninteractive, but I suppose I could have mistranslated something and done something I shouldn't have.

Still, I'll be watching future SliTaz releases closely. It's got a lot of potential, and is the most attractive of the distros I've tried so far.

Next up for review are PCFluxboxOS (similar to TinyMe), Damn Small Linux, Puppy Linux, DeLi Linux, Linux Mint (Fluxbox community edition), and the latest Arch Linux beta CD. Though this last one is the most like Gentoo -- it's only as lightweight or fast as I'm capable of making it. I've had issues with Arch in the past, mostly related to retarded source and kernel package management, but since I don't intend to do any compiling (finally) on this laptop, maybe that won't be an issue.

I get the feeling that I may well not find a distro that suits my needs, so I may just setup a chroot on my AMD64 workstation and compile packages on it, then rsync it over the network. beandog gave me a good basic procedure list, though this would easily be the most time consuming of the available options. Still, it would be a very familiar environment to work in. Though I'd have to figure out, on my own, all the neat integration and graphical/one-shot configuration mechanisms binary distros already have.

Tune in next time for more mini distro reviews.

Oh, and Gentoo users, take a look at GPytage. This is a neat little app written by our very own ken69267. It's a very nice Portage config file manager available in Sunrise. Its sole dependency is pygtk. It's a one-stop shop for easy, fast management of your /etc/portage/* config files. Take a look at this screenshot, then go get the ebuild and install it.

the answer for me is no.

many thanks to our security team for ignoring critical SSP bugs. the answer for me is no.
many thanks to our QA lead for replacing his head with a tomato. the answer for me is still no.

and many thanks to our council for supporting names like vapier and halcy0n (and wolf*lotsofnumbers*, i never knew he was into that kind of business) with their aggressive, destructive and pervasive notions of how people should conform to their fascist little black and white one in the stink two in the pink world. i still think the answer is no.

at least you got all the rotten tomatoes in one boat now and it's slowly sinking.
I'll be happy to leave you here with what you have. There have been no innovations hosted by Gentoo Linux on the security sector of host-based systems hardening for 5 years now. You fight people leaving faster than you can hire noobs to fill redundant positions because you fuckups still keep all your puppets in the right positions to decide what the public opinion is and what the people using Gentoo should "think" about your little /usr/portage experiment there.

well fuck you then, bitches.

whatever.

as always i'll have my last curtain with a song i loved when i was young- and maybe still do.
and now i have to admit- the answer to the above question for Gentoo Linux is definitely yes.

CAKE - The Distance

Reluctantly crouched at the starting line,
Engines pumping and thumping in time.
The green light flashes, the flags go up.
Churning and burning, they yearn for the cup.
They deftly maneuver and muscle for rank,
Fuel burning fast on an empty tank.
Reckless and wild, they pour through the turns.
Their prowess is potent and secretly stearn.
As they speed through the finish, the flags go down.
The fans get up and they get out of town.
The arena is empty except for one man,
Still driving and striving as fast as he can.
The sun has gone down and the moon has come up,
And long ago somebody left with the cup.
But he's driving and striving and hugging the turns.
And thinking of someone for whom he still burns.

He's going the distance.
He's going for speed.
She's all alone
In her time of need.
Because he's racing and pacing and plotting the course,
He's fighting and biting and riding on his horse,
He's going the distance.

No trophy, no flowers, no flashbulbs, no wine,
He's haunted by something he cannot define.
Bowel-shaking earthquakes of doubt and remorse,
Assail him, impale him with monster-truck force.
In his mind, he's still driving, still making the grade.
She's hoping in time that her memories will fade.
Cause he's racing and pacing and plotting the course,
He's fighting and biting and riding on his horse.
The sun has gone down and the moon has come up,
And long ago somebody left with the cup.
But he's striving and driving and hugging the turns.
And thinking of someone for whom he still burns.

Cause he's going the distance.
He's going for speed.
She's all alone
In her time of need.
Because he's racing and pacing and plotting the course,
He's fighting and biting and riding on his horse.
He's racing and pacing and plotting the course,
He's fighting and biting and riding on his horse.
He's going the distance.
He's going for speed.
He's going the distance.

may the source be with you and your guards never fail at entropy.

Alex

PS: the next time you write bullshit about me in profiles/default/linux/package.use.mask, make sure you remove my name so i don't feel offended by your blatant ignorance of the problem itself.

Since Diego is deleting my comments from his moderation queue, I'll try to give my impression of his post here. But first I'll state my opinion on the matter.

I think the Council made a mistake (admittedly, not a big one) by missing their latest meeting. And I don't particularly care about why it happened. Also, I don't think they have to give either reasons or excuses, this kind of stuff might happen, and that's all.

However, there's one reason the Council exists: because we all voted for what today is GLEP39 (which wasn't a GLEP by that time, as far as I recall). And said document states it clearly:

If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.

There is no point in enforcing such a rule when Council members are late even for half an hour (or even a couple of hours). But there is no enforcing here, you guys missed the meeting, rules say you have to call an election. Hell, those of you who got my vote will get it again. (And I'm quite sure that's the situation for lots of people).

Just follow the rules that give you the power you have.

However, I find it interesting that Diego, who is a Council member, didn't read the summary of that meeting:

Did I read summary or log the day after? Sincerely, no. I did think I was there till the end, as we were already late, and I don’t tend to read them usually anyway, I’m there during the meeting why should I read the summary? I usually read the replies but not the summaries themselves; I can tell you that Duncan on -dev made the point of the log being missing, so that I surely read. I didn’t even remember to ask what we had to do for the special meeting, and that’s entirely my fault, I should have asked. But I barely remembered saying I was okay with rescheduling, considering the lateness of the whole thing.

Well, to me, it is really important that Council members check the summary so they get an idea of what has been accomplished and decided in that meeting.

But still, am I the only one who thinks that it sounds tremendously like a last exit to get rid of the council when people point everybody at the rules, asking a new election, without having tried a thing to get the meeting actually happening?

This is funny: You didn't do anything to get the meeting actually happening. Don't try to blame those of us who want you to obbey the rules that give you your power.

Now that I explained how it is possible that the meeting was missed by almost everybody, let me reiterate that my official position here (and I repeat mine, not the council as a whole, I’m writing as a single developer here), is that the 50% attendance rule does not apply to this case as the meeting wasn’t officially scheduled through a voting process

Well, to me that's trying to bypass a rule. Be honest, call an election and schedule a meeting (so that last meeting happes) in the next couple of weeks. That should be fine for everyone.

Also, it seems that I have to restate this again: People feeling the need to use cheap psychology on me, please refrain. I don't care what you have to say.

— ferdy

It's official! Decibel Audio Player is now in Portage. Thanks to aballier for adding it, and thanks to everyone who provided feedback & testing.

Yay for yummy audio goodness!

In case you missed it, the Gentoo Foundation has been reinstated, so we're all nice'n'legal again.

Thank you, trustees, for all your efforts!

You can view our updated paperwork with the state of New Mexico here.

As per http://archives.gentoo.org/gentoo-dev/msg_19892c04f0e6cf4c24629f13718e45cb.xml there was a meeting council scheduled for 20:00 UTC today (that's a bit more than half an hour ago).

For some reason, only amne and dberkholz showed up. As per GLEP39's Specification:

• If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.

What's the council going to do? Place your bets.

— ferdy

The newest Decibel Audio Player is out, and it fixes several bugs and adds some new features.

The ebuild has been updated, so get it here!

okay here we go

>>> Regenerating /etc/ld.so.cache...
>>> sys-libs/gxslibc-2.6.1-r2 merged.

>>> No packages selected for removal by clean
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.
* Regenerating GNU info directory index...
* Processed 87 info files.

TMPFS chroot001 miranda ~ # export STATIC="-fstack-protector-all"; gcc-3.4.6 "${STATIC}" -fstack-protector-all -o vuln-stack vuln-stack.c && file vuln-stack && readelf -s vuln-stack | egrep "__guard|__stack_smash"; ./vuln-stack 1234567891234567; einfo "return code: ${?}"; echo; gcc-3.4.6 "${STATIC}" -fstack-protector-all -o ssp_entropy ssp_entropy.c && file ssp_entropy && ./ssp_entropy
vuln-stack: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), not stripped
2: 08049698 4 OBJECT GLOBAL DEFAULT 23 __guard@GLIBC_2.3.2 (3)
4: 00000000 30 FUNC GLOBAL DEFAULT UND __stack_smash_handler@GLIBC_2.3.2 (3)
78: 08049698 4 OBJECT GLOBAL DEFAULT 23 __guard@@GLIBC_2.3.2
80: 00000000 30 FUNC GLOBAL DEFAULT UND __stack_smash_handler@@GL
* return code: 46

ssp_entropy: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), not stripped
__guard: [[0x288a2b8c]]

TMPFS chroot001 miranda ~ # export STATIC="-static"; gcc-3.4.6 "${STATIC}" -fstack-protector-all -o vuln-stack vuln-stack.c && file vuln-stack && readelf -s vuln-stack | egrep "__guard|__stack_smash"; ./vuln-stack 1234567891234567; einfo "return code: ${?}"; echo; gcc-3.4.6 "${STATIC}" -fstack-protector-all -o ssp_entropy ssp_entropy.c && file ssp_entropy && ./ssp_entropy
vuln-stack: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, statically linked, not stripped
1346: 0804f810 18 FUNC GLOBAL DEFAULT 3 __stack_smash_handler
1554: 080bc370 4 OBJECT GLOBAL DEFAULT 16 __guard
* return code: 46

ssp_entropy: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, statically linked, not stripped
__guard: [[0xe686ece4]]

i invented return code 46 as SSP failure because i could not find a list of valid exit codes (unless segfault which is 127) at google.

-Alex