Slashdot Mirror


Ximian Desktop Installer, Red Carpet, and MonkeyTalk

An anonymous reader submits: "Long-time Linux users forget what it is like to try to install something for the first time. Ximian has done a nice job writing scripts to hide the inner workings of a Gnome installation. TuxReports has snapshots of the Ximian installer. Do you believe that all Linux distributions should use such a friendly series of dialog boxes in order to attract more users to Linux?" Update: 07/14 21:13 GMT by M : Tuxreports has provided a non-PHP page for us to link to... whoops. Sorry about that.

24 of 314 comments (clear)

  1. Red Hat users note by GigsVT · · Score: 5, Informative

    If you corrupt your box with this Ximian Gnome, you will not be able to upgrade Red Hat without uninstalling Ximian beforehand, or manually replacing all Gnome RPMs after the upgrade.

    This is something they don't tell you in all those "friendly installers".

    Other things may break, such as the Red Hat Network, when a Gnome related updated comes down the line. Of course if you plan to only use Red Carpet after installing Ximian, then that's not a problem.

    --
    I've had enough abrasive sigs. Kittens are cute and fuzzy.
    1. Re:Red Hat users note by martinflack · · Score: 3, Informative
      If you corrupt your box with this Ximian Gnome, you will not be able to upgrade Red Hat without uninstalling Ximian beforehand, or manually replacing all Gnome RPMs after the upgrade

      If you use rpm -qa along with the --queryformat option and grep for vendor "Ximian" you can build a list of Ximian rpm's post-install and then ask up2date to avoid updating those packages. This is what I did, and it works beautifully. up2date keeps my base system humming and Ximian Red Carpet just updates the desktop components.

      Try something like this to get you started:

      rpm -qa --queryformat "%{NAME}\t%{VENDOR}\n" | awk '$2 ~ /Ximian/ {print $1}' | sort | perl -pe 's/\n/;/'

      This is what my actual list looks like right now, although it may have a couple non-Ximian additions.

      pkgSkipList=kernel*;ORBit-devel;perl-PDL;libvorbis ;gnome-audio;nautilus-mozilla;eel;eel-devel;libgla de-devel;mcserv;gftp;libghttp-devel;Gtk-P erl;libole2;gnome-libs-devel;gdk-pixbuf;gnome-core ;gnome-pim;libgal18;gnome-core-devel;libgtop;gdk-p ixbuf-devel;libgtkhtml16;pygnome-libglade ;gmc;mozilla;gtkhtml-devel;audiofile;gaim;pygnome; gal;libgtkhtml20;helix-sweetpill;control-center-de vel;ORBit;nautilus;libxml;ammonite;bonobo ;abiword;gnome-games;monkeytalk;gtkmm-devel;gnumer ic;xscreensaver;libgal11;libgnomeprint11;libgtkhtm l17;imlib-devel;ximian-menus;gnome-games- devel;ximian-utils;libgal7;bug-buddy;libogg;audiof ile-devel;libglade;rep-gtk-gnome;ximian-wallpapers ;glimmer;libgtop-devel;grdb;imlib;bonobo- devel;nautilus-devel;gtk+;gphoto;gnet-devel;libsig c++-devel;mc;libgal12;libnspr4;libghttp;libunicode -devel;perl-Parse-RecDescent;pygtk-libgla de;gnome-vfs-devel;GConf-devel;sawfish-themes;mozi lla-psm;ghex;oaf-devel;libvorbis-devel;control-cen ter;libogg-devel;libgal13;gal-devel;xchat ;g-wrap;gtk-engines;libgtkhtml13;red-carpet;gtk-th emes;gedit;Guppi;glib;librep;gnome-applets;gnucash ;libnspr-devel;gnome-print-devel;rep-gtk; xmms-gnome;gimp;ximian-doorman;dia;libole2-devel;g nome-pim-conduits;aspell;mozilla-mail;gdm;ggv;gnom e-libs;gnome-media;esound-devel;gtkmm;pkg config;gimp-devel;ximian-faq;libgal8;scrollkeeper; grip;gnome-pim-devel;gnome-vfs;GConf;xmms;mozilla- xmlterm;imlib-cfgeditor;pan;slib;libxml-d evel;libgtkhtml15;libunicode;gtk-engines-thinice;o af;gimp-perl;libgal6;mozilla-devel;sawfish-themer; gnucash-devel;gtop;gdk-pixbuf-gnome;gtkht ml;rep-gtk-libglade;gnapster;gnome-print;gnome-use r-docs;glade;librep-devel;pygnome-capplet;pspell;e og;pygtk;libgal14;gnomeicu;libgnomeprint1 5;pspell-devel;memprof;gtk+-devel;gqview;libsigc++ ;pygnome-applet;gnet;xmms-devel;librsvg;esound;saw fish;glib-devel;gnome-utils;pilot-link;

      What would be even better is an up2date configuration command called skipVendor (or something similar) so the user doesn't have to make this list.

      Why don't I just use Red Carpet for everything? Simple. They made a GUI and I can't cron red-carpet. (For these types of programs you really need a CLI first, then a GUI.) If a security patch for sshd comes out, my automatic up2date will grab it that night and install it. I'll never use Red Carpet for system stuff because I shouldn't have to babysit those type of updates.

      My previous comments notwithstanding, I think Ximian is an excellent company and they make an excellent desktop, and I hope they do very well.

  2. Re:how about this? by flsquirrel · · Score: 4, Insightful

    I think a lot of it depends on the Distro. Let's face it, I'm not sure Debian will ever be as friendly as Mandrake, but I don't think that's a bad thing. Personally, I would much rather have the Debian staff working to get woody stable than be writing cute little graphical wizards. Mandrake on the other hand, yeah, I think it's wonderful what they're doing trying to get linux into the hands of more people by easing the installing process. But isn't that why despite wild differences many Linux distro's fare reasonably well in popularity?

    So to answer the original article: What Ximian and others are doing is a wonderful. But I think there's no reason for all the distro's to jump on the user-proof bandwagon.

  3. Ximian Rules.... by reaper20 · · Score: 5, Insightful

    If the Ximian release of gnome2.0 is anything like their 1.4 release, we should really be in for a treat. They manage that slick easy to use polish without dumbing everything down. My only complaint is the 'doorman' or whatever it's called goes a little bit too newbieish.

    Other than that, I always point users to the Ximian stuff, especially if they're coming from windows. It doesn't behave like windows, but it's set up really professionally.

    My complaint is this: Why aren't distro's packaging ximian gnome as the default gnome distro? We all know Redhat kind of ignores the linux desktop, concentrating on the server stuff. If I was them, I'd package ximian and have an instant polished gnome desktop. Redhat employs enough gnome hackers, that in a sense, they're already subsidizing the cost of Ximian gnome anyway.

    Not to take anything away from the RH gnome install, but why reinvent the wheel, Ximian has done most of the work already.

    And I think everyone agrees that jimmnac and tigert could be the best linux artists anywhere ... droolworthy work from those two.

    1. Re:Ximian Rules.... by battery841 · · Score: 3, Insightful

      Ximian and Red Hat, in some ways, are competitors on two fronts.

      First, Red Hat provides the Red Hat Network which is a competitor to Ximian's Red Carpet CorporateConnect.

      Second, Red Hat provides "priority downloads" with the Red Hat Network, so you can download packages from Red Hat faster. Ximian on the other hand, offers Red Carpet Express to help speed up Red Carpet downloads.

  4. Flexibility Is Key by MasterOfMagic · · Score: 4, Insightful

    I agree that wizards are good for people that don't know the basics about configuring packages and programs. They are a good way to get people to use software that they might not otherwise may be able to set up properly. However, wizards often suffer from WYSIAYG (What You See Is All You've Got). If a setting that may be important for a small number of users is left out of a wizard, then you hinder their ability to configure. However, general GUI configuration utilities are good too. For example, SWAT is a great example of a GUI configuration utility that is not a wizard.

    While graphical is good for beginners and some advanced users, you also should provide flexibility. Configuration files were made to be edited by hand! This is why Linux is so popular, flexibility. By hiding configuration behind a wizard and storing that configuration in a proprietary, non-text format like some large software vender who shall remain nameless, configuration files provide for flexibility. Not to mention that big configuration files (sendmail.cf for example) allow the user to learn from their mistakes, and it is a right of passage to set up one correctly for the first time. It used to be the same for X, but now with all of the wizards (which don't work on all new cards :-)), people don't have to learn to use their computer.

    1. Re:Flexibility Is Key by Pengo · · Score: 5, Interesting

      Configuration files were made to be edited by hand! This is why Linux is so popular, flexibility. By hiding configuration behind a wizard and storing that configuration in a proprietary, non-text format like some large software vender who shall remain nameless, configuration files provide for flexibility. Not to mention that big configuration files (sendmail.cf for example) allow the user to learn from their mistakes, and it is a right of passage to set up one correctly for the first time. It used to be the same for X, but now with all of the wizards (which don't work on all new cards :-)), people don't have to learn to use their computer.

      This is exactly why Linux is NOT popular. I would hardly say that most people want to sit and jack around with config files. If you want the flexibility , install from the source.. but it's going to be efforts like Red Carpet that take Linux to the masses, not the continued 'Flexibility' you speak of.

      When Linux can breach 25% of the desktop market on the merit of this flexibility you speak of, I will eat my words.

  5. Great, but has its downside by warmcat · · Score: 4, Informative

    Installing Ximian is sticky in the same way that Installing an updated IE on a Windows system reached in and changed operating system components.

    I had Ximian on Redhat 7.3, then when I upgraded to the Limbo beta the installation notes warned of dire conflicts between unnamed ximian RPMs and recommended removing Ximian from the machine.

    There is no option I could find to roll back Ximian, the same way that there was no option to roll back an IE upgrade on Windows.

    In the end I used GnoRPM to nuke eavery rpm with .ximian in the name and was able to successfully update to Limbo. But it ate a couple of days threshing around.

    Worth bearing in mind that Ximian is a major brain transplant for your OS and that may have impacts later. But on the positive side, it was very slick and the red carpet thing was nice.

    But I am happier with the stuff in Limbo, it rocks!

    1. Re:Great, but has its downside by chabotc · · Score: 3, Interesting

      The easiest way to do this (disclaimer: only do this when upgrading your distro or the like, restoring it all by hand would be a nightmare!)

      # rpm -e `rpm -qa | grep ximian` --nodeps

      This will remove any package with 'ximian' in the name from your system. (Used my self it more often then i'd like to)

      If only ximian had a 'restore original configuration' option in redcarpet, then i wouldnt be so afraid of using it! I love ximian gnome, their gnome2 snapshots and all their polish, but the idea that upgrading or changing my instalation is gonna be a nightmare is a showstopper for me.

    2. Re:Great, but has its downside by mickwd · · Score: 3, Interesting

      Be VERY careful if you're doing this, and realise what it's doing.

      What if you had some distro-installed library packages which Ximian came in and updated? If you do the "rpm -e ... --nodeps" trick above, those libraries will be removed. Any non-Ximian programs which happened to rely on those libraries (but which worked fine with the updated library versions Ximian provided) will no longer work, since you've removed those libraries and not replaced them with anything.

      This is a good way to "break" a lot of your favourite programs.

  6. Correction by JoshuaDFranklin · · Score: 5, Funny
    TuxReports has snapshots of the Ximian installer.

    TuxReports had snapshots of the Ximian installer.

  7. Take a note from Apple by dowobeha · · Score: 4, Insightful

    I run a Mandrake box. My wife has on OS X laptop. No point for guessing which system is easier to install new software on (hint - it's not the one that has an AMD inside).

    I love Linux. I love GNU. I love open source software.

    But my next machine will be a Mac.Why?

    Because package management is a breeze. I don't have to know the difference between /bin, /sbin, /usr/bin. Because I can drag a program I'm tired of to the trash can.. Because I can go to one location - the Applications folder - to find any new program I install. Or, if it's a command-line app, I can go to one location - /bin - for everything.

    If the open source community wants to know how break into the desktop market, look no further than Mac OS X. Whether you like the system or not, in OS X is a *nix system that has a highly user friendly interface, excellent graphic-based package management, and all the other bells and whistles that the mass desktop market craves.

    --
    I am concerned about any program, any piece of hardware, any treaty, any law that treats me as a consumer, not a citizen
    1. Re:Take a note from Apple by hysterion · · Score: 3, Informative
      If the open source community wants to know how break into the desktop market, look no further than Mac OS X. Whether you like the system or not, in OS X is a *nix system that has a highly user friendly interface, excellent graphic-based package management, and all the other bells and whistles that the mass desktop market craves.
      The unbelievable truth is that there is a project doing just that, and that's GNUstep. (See also LinuxSTEP, and the overview at GNUstep.net.)

      I fully agree... To go beyond command line Unix, NeXT and its stepchild OS X set a alternative standard to the (unnamed) platform which (unnamed) others have been busy cloning (with great success, too). Here is hoping that observations like yours will finally create enough of a synergy...

  8. Re:How do they make any money? by kerskine · · Score: 4, Informative
    Actually, there are two ways we make money on Red Carpet:
    • Red Carpet Express, which offers customers fast, dedicated bandwidth for getting software updates.
    • Red Carpet CorporateConnect, which is a hosted service that enables organizations to manage their own internally developed software in addition to getting updates of Linux, Ximian, and other software offered by Red Carpet.
    --
    ****

    "I'd never want to join a club that would have me as a member" - G. Marx
  9. There are only a few installer packages by crovira · · Score: 5, Interesting

    for the Mac & Windows. Some are "blessed" by the OS Distributor and some are crafted according to written guidelines provided by the OS Distributor. The OS X installer is GREAT in that respect.

    The situation MUST become the same for Linux. There must come to be some "blessed" slick GUI installer that can also run "headless" from a command line.

    It should implement a state transition engine and run from a state machine which goes from an initial state "not-installed", through paths for the distros, dependencies to a terminal state of "software registered."

    To make the situation complete, it must detect the distro (and therefore the install paths, dependencies and destination directories,) the GUI in use, if any, and be able to completely install AND UNINSTALL by walking backwards through the installer log undoing what was done and cleaning up all debris.

    The installer "experience" is standard for the user because everybody is using the same packages or near clones of these packages to install any and every ol' thing.

    And this is a lot easier for a user (or a SysAdmin,) to deal with than the ideosynchratic and often badly written readme.txt files written by somebody who just doesn't "get it" and can't remember what he didn't know when he first started out.

    And the excuse that "it wasn't easy to write so it shouldn't be easy to install" is the refuge of lazy-ass, elitist, nerdy schmucks who don't have friends to watch over their shoulder, correct their grammar and actually try and test out their installation instructions to detect all the "missing" information.

    Its called QA folks and you'd better get used to it or you're wasting your time pretending that you're IT pros.

    --
    MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
    1. Re:There are only a few installer packages by IamTheRealMike · · Score: 5, Interesting
      Interesting you should mention this. I'm working on something called autopackage, which does exactly this.

      The situation MUST become the same for Linux. There must come to be some "blessed" slick GUI installer that can also run "headless" from a command line.

      Check. Autopackage is (currently) written largely in bash, but has a clean split between the backend and front end for exactly this reason. The BE and FE are actually two separate processes which communicate via a simple protocol based on unix named pipes. Right now, there is only a terminal front end, but when it's released as an OSS project (soon) I'll be looking for people to help me write KDE and GTK based installers.

      It should implement a state transition engine and run from a state machine which goes from an initial state "not-installed", through paths for the distros, dependencies to a terminal state of "software registered."

      Check. Autopackage deals with dependancies differently to other package managers, as it doesn't have a huge central database of everything that's on the system (it keeps enough information around to uninstall packages though obviously). Instead, it probes the system for everything the package needs - for instance it currently checks for libraries using ldconfig. If it's in the Linux Linker cache, the check is passed. This means you can install stuff from the source, or even just copy files from a friends computer without worrying about your package manager database getting out of synch.

      To make the situation complete, it must detect the distro (and therefore the install paths, dependencies and destination directories,) the GUI in use, if any, and be able to completely install AND UNINSTALL by walking backwards through the installer log undoing what was done and cleaning up all debris.

      Check. An autopackage is actually a program that you run (don't worry, the overhead is tiny). If you have autopackage installed, the scripts are processed and the user is greeted with a friendly GUI installer (if run from X) or if run from the command line you get the tty front end. If you don't have autopackage installed, it'll offer to automatically fetch everything the user needs from the net including a distro profile.

      The profile contains all the information needed to slot files into the correct places, and perform the correct actions for adding menu items etc. If there is no profile for the users distro, I intend to have a way of letting the user easily create one (though this will probably not be an operation that can be performed by a total newbie) and then optionally upload the resultant profile for checking and inclusion. This deals with cases where people have built their own systems, or have customised them a lot.

      The installer "experience" is standard for the user because everybody is using the same packages or near clones of these packages to install any and every ol' thing.

      That isn't going to happen soon, which is why autopackage will integrate (at least to some extent) with RPM and perhaps Debian too. However, I intend to eventually create something similar to the apt repositories, except decentralised so it acts more like DNS rather than having huge libraries of packages that must be manually updated. I hope, dream, that one day Linux software authors will provide an autopackage as standard as well as the source tarball (they are pretty easy to make), which will plug into the autopackage network and allow you to install and update them using an apt type system.

      Umm, what else? Oh yes, it's pretty flexible about asking the user stuff. The user can be asked questions during the install like which prefix to use (defaults chosen from the profile), or for commecial software they can be asked for license keys, to read EULAs and so on (commercial software is coming to linux like it or not, so i thought I might as well add these features). However, I had a bad experience once where I spent a whole week installed IE5 on each and every machine in a company by hand, so rest assured, being able to do automatic remote installs is high on my list of priorities.

      I still have some basic foundation and design work to do on it, but I'm hoping it'll be out on freshmeat and ready for hacking by the end of the summer. If you're interested, then please email me. This should go a long way to solving the software management mess that Linux has somehow got itself into.

    2. Re:There are only a few installer packages by IamTheRealMike · · Score: 4, Interesting
      So say I copy package A from another machine. I then install package B, which requires something that package A has. Your script just sees that it exists and continues on with the install. Then I uninstall package A. Without a database to keep track of dependencies, how do you know what will break by doing an uninstall?

      You don't. If you do copy stuff from another machine, then it wouldn't be in a database anyway, so you still wouldn't get any warnings if you deleted it if you were using RPM.

      The approach autopackage takes here is that having a database of everything on your system is a bad idea, as that db will invariably get out of synch. The system is the best database. So let's say we have the situation you described. You somehow remove something that another program needs, and you do it manually so there are no warnings. Suddenly, a program will break. In this case, you run the apkg-verify command, which will look at the dependancies of this package (let's say you install package "genst" that needs libxml, and you remove libxml).

      The verify command now loads up the package skeleton for libxml as it knows this is a dependancy of genst (the package skeletons describe uninstall info/file lists/dependancy tests). It runs the test in the libxml skeleton, and sees that it fails. It now offers you the option of redownloading and installing the package.

      This isn't the ideal approach, as the user would much rather have been warned beforehand. However, other than by overriding the "rm" command (which could be done, but I doubt it'd be popular) there is no way of stopping the user mangling their system in such a way. Being able to copy files from another machine or install from the source will always have this problem, as it's not registered in any database.

      If you can think of a better way of doing this, then please tell me. I've been thinking about it for most of the afternoon, and for the rare cases in which you delete things like this (most users would use the uninstall commands and not copy files from other computers) the verify mechanism would work, and not require too much implementation effort.

    3. Re:There are only a few installer packages by IamTheRealMike · · Score: 4, Interesting
      The problem I see with all those package repositeries (such as Debian's, RedCarpet, Gentoo portage's, freshrpms, autopackage's, etc.) is that you must wait for somebody to do the work of the packaging for you if you want to install something.

      Exactly, this is why the autopackage network would be different. Rather than having huge teams of packagers like Debian has, which will invariably miss stuff, it works in a way similar to DNS. Let me explain:

      You install package "genst" - it generates simple source trees by the way, and I'm using it for development because it's simple. Genst has 2 dependancies, on libxml (developed by the gnome team) and on the dialog utility which has floated around in various versions for a long time and doesn't really have an official home site anymore.

      In the autopackage, some dependancy checks are made to ensure you have the correct versions of libxml and dialog. If these tests fail - now what? In the Debian system, your computer would try and download the needed files from ftp.debian.org, a huge collection of packages, all hand maintained.

      For autopackage however, what happens is that a resolution process begins. Each package has what's called a root name which looks like this: "@gnome.org/libxml/2.0" or "@advancedresearch.org/dialog/0.9". It leverages off DNS for keeping names unique by the way. Your computer now attempts to turn this root name into a URL from which the necessary package (which could be an RPM) can be downloaded. The difference is that that's all the autopackage network does: responsibility for building and maintaining the package is the software developers responsibility whenever possible. That's why I'm focussed on letting the production of autopackages as simple as possible, so the developers themselves can package their software with minimal effort. I think the attraction of being able to offer a binary download that'll work on all distributions will be enough to get started with, along with some gentle persuasion ;)

      Anyway, the route by which root names are turned into URLs is pretty flexible, for instance your distro could override it (similar to apt.sources) so that if you try and upgrade X, it'll get the package from the distro servers rather than the xfree servers. Hopefully we'll end up with a hybrid system, whereby most packages reside on the project servers, rather than a central database, and therefore the packages are always up to date.

      I'd like to be able to install it correctly (ie, using my package manager) alone, possibly sharing the method used (spec file or equivalent) afterwards. Doing a RPM or a deb is actually quite easy for standard packages (the configure; make; make install kind of packages). But it could be even simpler. I'd put my efforts on that part of the packaging system.

      Nice idea, but not always practical. For starters, most people don't want to compile software from the source. When it works it takes ages. It often doesn't work, and you must install large numbers of -devel packages to get the C headers etc. RPMs are also limited - there's no way of customising the install based on user interaction for instance.

      Limiting the source of the packages a user can install on their system by using said repositeries, even if they're comprehensive and large, is a counterproductive step IMHO.

      Exactly, that's why autopackage tests the system directly rather than having a big repository. You can get the files you need from anywhere, not just your package manager.

  10. Re:The Easier the Better by donnacha · · Score: 4, Insightful

    Why do you want ALL distros to use it? I use debian because it is complete, yet minimally so. I want my configuration to be done with joe or vi, not pretty menus. This is good for a redhat or mandrake, distros that are geared towards n00bs.
    Well, obviously, it should be a choice but, when you get down to it, we're all n00bs outside our specific areas of expertise and most people just don't have time to develop macho,hacker cred.

    I may be envisaging too rosy a picture here but, it seems to me that all the people who spend so much time contributing to OSS projects do so because they want to see as many people as possible benefiting from "what computers can be".

    It's just plain wrong that, for instance, millions of office workers in poorer countries are laboriously doing by hand tasks that can, with simple, existing tech, be automated. If the only path towards eliminating this waste is an "easy" option from M$ that costs $$$$$, or a free alternative that's too tricky to actually implement, the waste will remain.

  11. Who needs installers? by Wesley+Felter · · Score: 3, Interesting

    Do you believe that all Linux distributions should use such a friendly series of dialog boxes in order to attract more users to Linux?

    Actually, I'd like to see Linux preinstalled on more computers so that users don't have to install at all.

  12. Package installer version 66.6 by dowobeha · · Score: 3, Funny

    ...

    /* Package installer version 66.6 */

    printf("Translating all source code for requested package.\n);
    printf("--- Successful ---\n");
    printf("Half of text in requested package will print in Esperanto. The other half will print in pig-latinized-Klingon.\n");

    printf("Creating random name for package executable...\n");
    printf("Searching drive for obscure installation location...\n");

    printf("Oops! There are 348,899,001 extra dependencies that this package relies on. Do you wish to go through them one by one?"\n);

    printf("Just kidding. Compilation was successful. Package is hiding in...\n");

    printf("...You don't actually think I'm going to tell you where to find this, do you?! Hahahaha!\n";

    ....

    --
    I am concerned about any program, any piece of hardware, any treaty, any law that treats me as a consumer, not a citizen
  13. Naw by B3ryllium · · Score: 5, Funny

    I think most people here would prefer to install linux by manipulating the hard drive with magnets ...

  14. from /usr/lib/anaconda/upgrade.py by toolz · · Score: 3, Funny

    # I'm going to try to keep this message as politically correct
    # as possible. I think the Ximian GNOME is a very pretty desktop
    # and the hackers there do an extraordinary amount of work on
    # them. But it throws a huge wrench in our upgrade process. We
    # just want to warn our users that there are packages on the system
    # that might get messed up during the upgrade process. Nothing
    # personal, guys. - msw

    --
    You aren't remembered for doing what is expected of you
  15. Re:Well, it's already here in a lot of ways by __past__ · · Score: 3, Insightful
    I honestly hope that this won't end up in a flamewar, but I have a question to all gentoo-users that I wanted to ask for quite some time now.

    If the outstanding feature of gentoo is its BSD-like package management, why don't you use BSD in the first place? For example, FreeBSDs ports tree is quite mature, huge (~7,300 ports last time I checked, and there isn't the distinction between libfoo and libfoo-devel common in the Linux world) and comfortable, especially with the help of portupgrade and friends.

    I my understanding (as a BSD user coming from Linux) the cool thing about ports/pkgsrc/emerge is the elegance through simplicity. You just know whats going on on your system. (Try that with Windows ;) You have a chance to tweak things, and - important if you, like me, use some rather obscure packages noone else would ever think of including in a distribution - it's braindead easy to create a port/pkgsrc/whatever-gentoo-calls-it yourself.

    IMHO, this elegance is found in every place of BSD systems. For example, the kernel config file is, well, just that - a simple, documented file. No make menuconfig. No xconfig. No applying loads of cool patch sets found anywhere on the net.

    So, for someone who likes ports/pkgsrc/emerge, I'd say a BSD ist a cool system to use it on ;-). However, I only read comparisons between Gentoo and other Linux distros, not between Gentoo and the BSDs. Could anybody using both please share his/her opinions about the relative merits?