Bye Fedora

I’m going to say goodbye to my current Fedora 12 laptop; yes the one for which I wrote that post about Fedora 10 at the time which I then updated for Fedora 11. This is not because the laptop broke down, but rather because I ended up getting my MacBook Pro fixed, and that is again my main laptop. While I did want to have a laptop running Linux to the side of the MBP running Mac OS X, I finally decided it’s pretty pointless for me.

There are multiple reasons for that, some have nothing to do with Fedora, but a few have. Marginally maybe, but they have. The first problem is, once again, the video card. While it’s not like it has been easy with Yamato’s new one I got to say that two and a half months later I’m definitely glad I got it: KMS with 2.6.32 (and GIT userland — need to check whether that’s still needed, but I guess so for a while still) works like a charm, I’m able to use compiz without a glitch, it’s perfectly stable. With the nVidia on-board card of that laptop, it’s a totally different story. The nvidia binary driver for that card is not (yet?) available for Fedora 12, and the nouveau driver is… useless. It’s not just a matter of lacking 3D acceleration, but it’s also totally broken for suspension, which worked fine at least with the proprietary driver instead.

But it goes beyond the hardware support; probably you have all heard about the thunderstorm around Fedora’s original decision to allow any user with console access to install new packages without root password. I actually think that for Fedora’s target, that’s a pretty good move: it limits itself to installing and upgrading signed packages which has thus limited security implications, and it’s just a default. For most users, having console access is as good as having root’s password so it shouldn’t really matter; for desktop usage, that’s pretty much true already. Smarter, more security-paranoid users can easily change that setting. At any rate, the thunderstorm (or crapfest if you prefer) got them so much they changed the default again; too bad. Unfortunately, it seems instead that I got a different problem: my PackageKit interface is totally broken and I cannot use it at all; I got to use yum to upgrade my box which is definitely not so nice.

At first I thought it had to be related to either the fact that I upgraded from F11 or to my use of RPM Fusion but turns out that the PackageKit interface is as much broken on a box that a customer of mine set up for me to install a toolchain chroot for them last week. I ended up using yum there as well; no clue what the problem is with that.

And since I upgraded to F12 I found another problem as well: I already ranted about the fact that I couldn’t get bluetooth dial-up to work with my Nokia phone, and I had to use the cable to work it out; following Adam’s suggestion I also got the JoikuSpot application that turns the phone into an (ad-hoc) hotspot to use it via WLAN without configuring anything. The latter approach is, unfortunately, valid only if you’ve got the power adapter of your phone at hand, since it lasts about an hour on my E75; and the other day (at my customer’s office) I didn’t have it available. I had, though, the cable, left in the bag since the last time I used it, unfortunately when I tried to connect with that, exactly like I did in F11, NetworkManager decided to fail. And of course neither DUN nor PAN seems to be available via bluetooth in F12 as well as F11.

So I’m considering whether I need that laptop or not: the MBP starts up in less than two seconds, thanks to the fact I always leave it in Suspend-to-RAM (and that’s faster than Google’s Chrome OS… I wonder why people seem to challenge the start-up time rather than fixing the suspension support, bah); the MBP lasts more than four hours on its battery; the MBP have a much sleeker design which makes it handier and I don’t have to go around with the clunky power supply (not only because the MBP’s is smaller, but also because I have my mom’s supply downstairs if I’m running low on battery); the MBP (with OSX at least) can connect properly, via bluetooth, to the phone and thus the Internet (most of the times at least). So at the end, I’m not going to use the Compaq for much.

I’ll create a Fedora 12 virtual machine on Yamato for testing my projects there, where most of the previous notes about stuff not working properly will be moot points.

*Post scriptum: I wrote the draft for this article a couple of days ago and in the mean time I set up the Fedora 12 virtual machine I noted in the last paragraph; it was that way, by trying out virtio, that I found the n-th qemu/kvm quirk that made me drop the “proper” qemu. Unfortunately with that new install, from scratch, not update, I found another share of problems.*

*The remote desktop support in GNOME is totally broken: I can see with tcpdump the request arriving, but no reply is given altogether. If you set an hostname in three parts (say, fedora12.qemu.local), Avahi will advertise fedora12.local instead. system-config-services is not installed by default, and the first time I installed it I had to reboot otherwise I would only get crashes. One default cron job causes SELinux to report invalid accesses to /var/lib … all in all, it seems to me like Fedora 11 was way more polished!*

bash scripting tiny details

Although I’m now an ebuild developer for almost two years, and I contributed for at least another year through bugzilla, I never considered myself a bash expert; the functions I use are mostly the generics, a bit more advanced than a newbie usage, as often needed in ebuilds, so from time to time, when I learn some new trick that others known since ages before, or I discuss about alternatives with other developers, I usually end up posting here trying to share it with others that might find it useful.

As autoepatch is being written entirely in bash, I end up coping with some problems or corner cases that I need to dig around and thus I ended up learning some more tricks, and some things I’m thinking about for the ebuilds themselves.

The first thing, is about sed portability.. we already have made sure that “sed” called in ebuild scope is always GNU sed 4, so that the command lines supported are the same everywhere; a portable alternative, and seems also to be a faster alternative: perl. The command “perl -p -i -e” is a workalike replacement for “sed -i -e”, that as far as I can see is also faster than sed.. I wonder if, considering we already have perl in base system, it would be viable to use it as an alternative to sed throughout the Portage tree.

For find(1) we instead rely on a portable subset of commands, so that we don’t ask Gentoo/*BSD users to install GNU findutils (that also often breaks on BSD too); one of the most used features of find in ebuilds is -print0 to then run through xargs to run some process on a list of files. Timothy (drizzt) already suggested some time ago to use -exec cmd {} + instead, as that merges the xargs behaviour in find itself, avoiding one process spawning and a pipe. Unfortunately, this feature, designed in SUSv3, is present in FreeBSD, DragonFlyBSD and NetBSD, but not on OpenBSD… for autoepatch (where I’m going to use that feature pretty often as it all comes down to find to, well, find the targets) I decided that the find command used has to support that feature, so to run on OpenBSD it will have to depend on GNU findutils (until they implement it). I wonder if this could be told of the whole Portage and then replace the many xargs calls in ebuilds…

I should ask reb about this latter thing but he is, uh, disappeared :/ seems like Gentoo/OpenBSD is one of those projects where people involved end up disappearing or screaming like crazy (kinda remind me of PAM).

Talking about the MacBookPro: today I prepared an ebuild for mactel-sources in my overlay, that I’m going to commit now, that takes gentoo-sources and applies the mactel patches over it, it’s easier to handle for me in the long run; this way, the Synaptics driver for the touchpad actually worked fine. Unfortunately, KSynaptics made the touchpad go crazy, so I suggest everybody NOT to try it, as it is now.

Runabout and Intrepid

I’m telling the tale of two new boxes in my network, that are being tested and used all day long.

Intrepid is, as you might have already read, my new MacBook Pro Core2Duo, on which today I started to install Gentoo Linux (AMD64 of course). Unfortunately, well, I got into a little problem when I started installing, because I partitioned using fdisk after running BootCamp, so then GPT and MBR were out of sync, and both OSX and rEFIt weren’t sure of what was going on. I then decided to copy all the content of the installed root and then restarted from scratch.

As I wanted to have a swap partition (just to be safe, or if I ever decide to use software suspend), I then decided to first create the Windows partition with BootCamp, and then fiddle with the partitions directly on the GPT. Thanks to Daniel Ostrow, I then used the same method used on IA64 (GNU parted), and the result is, well, that the partitioning worked! YAI! :)

One problem I have now is that rEFIt shows as bootable also the swap partition, but that can be worked around somehow, I hope (actually I’m just trying to see if by using parted to set the boot flag off on sda3 and then on on sda4 it would help.. no…).

Runabout instead is a new name, a new box… if you can call that a box, it’s a Nokia E61 smartphone, that I bought to get back my 3 number while I’m without the V1075… afterward, it will become my work phone. It was suggested to me by a friend of mine, Andrea, who has similar tastes to mine (although I don’t usually like Nokia as much as he do); I decided to spend money and buy this on his suggestion, as I also got the first payment for my current job, which allowed me to spend a bit more money than usual for once.

Although I was skeptic at the start, after playing with the E61 for a while, especially with the WLAN settings, the email setup, the Web browsing, I had to agree with my friend, it is an interesting device. I also found a PuTTY port that will allow me to connect via SSH to my boxes directly from the cellphone (that’s the final tool for a geek system administrator!), and an IRC client, both Free Software, which is pretty good.

The hostname (Runabout) I reserved some time ago for whenever I had a PDA, and seems the time came, finally :)

New laptop, finally!

Today I finally got my new laptop, a siny and happy MacBook Pro 2.33GHz Core2Duo. I was quite pleased with my iBook (exception being the sucky wireless support under Linux, main reason why I usually used it with Mac OS X), and this ew Intel incarnation of Apple’s hardware seems to have the same touches that made me like the previous laptop (that’s now being usd by my mother): the backlight on the keyboard is good to have while I’m writing in my chambre, the non-glossy display still has an incredible color and does not reflect so much, the design is sleek and sober, compared for instance to HP’s Pavillions, and it’s quite fast.

Gentoo will come on this box soon; for a couple of days I’ll leave Mac on this and then I’ll start working on that. I was thinking of building the system from the other box, but the ROOT= support is quite limited and this CPU has SSE3 while the other hasn’t, so I can’t really use a pure chroot.

Now, on more Gentooish notes, I started to port nss-mdns to FreeBSD, as the current implementation only works on GLIBC; the reason of this is just that I needed a way to identify the two laptops that have dynamic IP addresses depending if I connect them via cable or via wireless, so I decided to give an inner try to Avahi and ZeroConf as a whole.. the result is pretty neat, although I had to disable the return-on-not-found for the minimal nss module or it was failing to resolve everything when searching for local domain. Maybe I have to play with it a little more to get it to work as I need.

Instead, on the ALSA front, after yesterday’s release of ALSA 1.0.14_rc1, I’m probably going to work a little bit more on the ability to disable on request the plugins of alsa-lib; especially considering the embedded devices, often you don’t need most of them; even for simpler user systems you probably need just an handful of them.. I think this would be simple to solve with use groups, but in the mean time I’m probably just going to ask for a new USE_EXPANDed variable, to be converted in the future (and poke Zac again about getting something usable for that).

I know there are still glitches with that (for instance there’s a too low dependency for alsa-lib in alsa-utils), but considering I always say to leave as much as the same verison for everything there, it’s hardly a priority to me.

Okay, let’s see what else I can do with this boxy before going to sleep :) And for who’s wondering, considering the other laptop was named Voyager, this one is, obviously, Intrepid :)