All the Perl that's Practical to Extract and Report

Upgrading and Downgrading

ziggy on 2002-11-07T21:24:56

Before I send my iBook back for repairs, I want a working laptop that I can use for the week it's away. I have a nice thin x86 laptop that I've been meaning to install FreeBSD on since I got it over a year ago.

Since I'm not relying on this machine anymore, now is as good a time as any to reformat the hard drive and start anew. Sadly, the current versions of FreeBSD (4.6.x/4.7) don't support my PCMCIA cards (CardBus), nor do they support the seemingly quirky APM Bios I have (/dev/apm is supposedly broken). FreeBSD 5.0 might be the answer here, but it's not supposed to be "ready" until later this year.

After spending a few hours getting this laptop nicely configured, I trashed the FreeBSD installation in search of something more suitable. Because laptop hardware support tends to be better with Linux, I chose to install gentoo. The installation process isn't exactly smooth yet; the current release is 1.4_rc1 (and hasn't been updated for a good few weeks), but the installation instructions seem to focus on 1.2.

A few things I learned during the installation:

  • Don't try and install over a wireless ethernet connection; the docs and stage1 CD don't match. (Plus, it doesn't look like my hardware was supported by the stage1 CD). Instead, use the built-in ethernet that's probably on your motherboard already.
  • portage isn't exactly 100% in sync. There were a few ports I tried to install that wouldn't compile for one reason or another. Thankfully, there are multiple versions of many ebuild scripts, so manually building one version earlier or later did the trick. (I think I had to use a previous ebuild script for gtkperl, tetex and vim.)
  • Installing and configuring gentoo takes a loooong time, because you're compiling everything from source. I actually prefer doing this, but I didn't used to compile so many packages all at once. (I typically start a fresh FreeBSD installation with packages and then upgrade via ports.)
So far, everything is working fine. It didn't take much effort to build a workable system from scratch, but working around a few of the glitches did take some sleuthing.

The most striking thing about this installation is that my desktop looks pretty much like it did 5 years ago (and 5 months ago) when I was using WindowMaker on a daily basis. A few months of using Mac OS X, and this setup feels ancient and cumbersome.

Gentoo

Matts on 2002-11-07T23:07:27

I just can't bring myself to the idea of using gentoo. The idea that you compile it for yourself seems fine if there were 30 people each using different CPU's, but the fact is that there are 5 million people using P4's and 10 million people using P3's, and 2 million people using AMD's, and so on. It just doesn't seem worth it to me to extend the installation time so much for all those people.

The install time probably isn't so bad for people using Gnome apps, but for those using KDE it must be significant. Compiling C++ apps takes forever with gcc, and for me that translates directly into time I'd rather be actually *using* the app, not waiting for it to build.

So I feel there has to be a better way - build a distro like gentoo but let there be pre-compiled (but optimised) binaries for your particular platform distributed for everyone.

Of course this is pure rant + speculation, because I have no solid solution to this. I'm just bemoaning the loss of time it takes to get gentoo up and running in an optimised manner.

Re:Gentoo

ziggy on 2002-11-08T00:10:19

The install time probably isn't so bad for people using Gnome apps, but for those using KDE it must be significant. Compiling C++ apps takes forever with gcc, and for me that translates directly into time I'd rather be actually *using* the app, not waiting for it to build.
Oh, boy do I feel that now. KDE has been compiling for about a day now. I forget what I installed that got X installed, but I'm running WindowMaker again at the moment with rxvt until KDE is ready. Even then, I'm not sure how much of KDE I'll be using...

Of course, I found out about emerge -b a little *too* late. I have a sneaking suspicion that I'll get the gentoo build set up, and wipe the disk clean for one reason or another. I do not want to spend a week downloading and compiling again if I return to gentoo. (I've already saved all of /usr/portage elsewhere; all that's left is to figure out how to make packages out of what's installed instead of recompiling them.)

So I feel there has to be a better way - build a distro like gentoo but let there be pre-compiled (but optimised) binaries for your particular platform distributed for everyone.
Perhaps. I just remember the early days of RedHat when they'd ship distributions that couldn't self-host, and srpms that couldn't build the rpms they distributed.

Also, once you count the number of platforms and configurations out there (various mutations of x86, dozens of OS choices on SPARC, PA/RISC, PPC, Mac OS X, etc.) then it's a huge burden on a distributor or a maintainer to compile, test, check, distribute and maintain every possible combination. Doubly so when you factor in multiple incompatible file system and configuration setups with many popular Linux distributions.

So I'm not exactly sure that letting a thousand precompiled binaries bloom is One True Solution. Especially when software gets updated so frequently. Then again, if there ever was a time for that approach, it would be today, with 120GB disks and broadband pipes becoming increasingly common...

Re:Gentoo

chromatic on 2002-11-08T06:55:49

Internet-distributed ccache?

(I can't believe I just said that.)

Re:Gentoo

pdcawley on 2002-11-08T07:30:27

I think the 'customized optimization' thing is something of a red herring. The Gentoo approach tends to mean that you compile the system the way you want it, in terms of the kinds of packages you want to install.

Take a look at an an average ebuild, say XMMS, and in the DEPEND specs you'll see a bunch of lines like:
mikmod? ( >=media-libs/libmikmod-3.1.6 )
esd? ( >=media-sound/esound-0.2.22 )
xml? ( >=dev-libs/libxml-1.8.15 )
gnome? ( <gnome-base/gnome-panel-1.5.0 )
opengl? ( virtual/opengl )
oggvorbis? ( >=media-libs/libvorbis-1.0_beta4 )
Those are optional dependencies and they're the really good thing about Gentoo. If I want a system without, say gnome, then I can say so, and when I go to build anything that could be configured with a --with-gnome switch, it'll be configured using --without-gnome instead. On the other hand, if I do want oggvorbis, but haven't installed it yet, then installing XMMS will force a fetch and compile of the oggvorbis support tools.

Once you freeze something into a binary package, you magically freeze its dependencies too, and those dependencies are going to be wrong for a large subset of the folks who want to use it.

Re:Gentoo

Matts on 2002-11-08T12:58:58

Also, once you count the number of platforms and configurations out there (various mutations of x86, dozens of OS choices on SPARC, PA/RISC, PPC, Mac OS X, etc.) then it's a huge burden on a distributor or a maintainer to compile, test, check, distribute and maintain every possible combination. Doubly so when you factor in multiple incompatible file system and configuration setups with many popular Linux distributions.


You're thinking in terms of ftp or http hosting though. Do it p2p. I think it's easily the best use of p2p possible.

Re:Gentoo

ziggy on 2002-11-08T16:33:15

You're thinking in terms of ftp or http hosting though. Do it p2p. I think it's easily the best use of p2p possible.
Yes, specifically because there needs to be a level of trust between the user and the "distributor". That's why I tend to use RPMs from one of two places when tweaking a RedHat installation -- either they come from RedHat, or they come from the project itself (e.g. MySQL). Part of that is because I don't trust Joe's Garage and RPM Cellar to make precompiled software that I can trust and will run as expected on my system. (Trojans are an issue, but coredumps and such are more of an issue.)

As piers points out, the OS+Architecture is only one set of dimensions that need to be addressed. Software configuration is another set of issues. (There used to be 32 different and somewhat incompatible ways to build Perl on any particular platform; the number has probably gone up recently, but I forget what the actual figure is today.)

P2P isn't an answer to the problem of geometric complexity. But it is an answer to global distribution of a large amount of that complexity.