Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Ximian

Ximian Desktop Installer, Red Carpet, and MonkeyTalk 316

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.
This discussion has been archived. No new comments can be posted.

Ximian Desktop Installer, Red Carpet, and MonkeyTalk

Comments Filter:
  • how about this? (Score:1, Insightful)

    by MrSloth ( 544065 )
    I think that the OPTION of being able to use an installer wizzard is nice, but in an OS that is known to be so versitile and let you configure EVERYTHING the way you want it, it is a bad idea to require an installer script
    • Re:how about this? (Score:4, Insightful)

      by flsquirrel ( 115463 ) on Sunday July 14, 2002 @11:36AM (#3881720)
      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.
  • I know they've got deals with various Unix hardware vendors, but how does Ximian plan on making money off of Red Carpet?
    • Red Carpet can make money by offering subscriptions. Subscribe and get access to the high bandwidth, high availabilty site.

      Ximian also plans to make money through the sale of things like it's Exchagne Connector which allows Evolution clients to utilize Microsoft Exchange 2000's services including the calendaring features.
    • by kerskine ( 46804 ) on Sunday July 14, 2002 @11:59AM (#3881828) Homepage Journal
      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.
      • they should also make a...
        • Red Carpet Alert, which should send a user an alert. After a Red Carpet install, alerts should popup to notify users when newer versions are available.
        A cron task would check the Red Carpet database and then compaire it to what is available for download. If thier was a difference, it would alert the user with a visiual notice, then go back to sleep. Users should be able to cancel the notification one of three ways. Download the newest versions, Elect Never to update current version, or put in a version tag (regexp). The version tag would allow the user to specify "notify me when XYZ app gets to version 2.5.

        my .02.

  • "Do you believe that all Linux distributions should use such a friendly series of dialog boxes in order to attract more users to Linux?"
    God, yes!

    The potential of OSS won't be truly realized until it's actually easier to deploy than commercial offerings.

    I was particularly impressed by PostNuke's no sweat installation procedure... it made me realize just how much more far-reaching it's effect on society is going to be if society is actually able to use it.

  • by Apreche ( 239272 )
    This is exactly what every piece of linux software needs. If I could install any piece of linux software with a friendly series of dialog boxes just like with install shiled in windows, I would use linux much more often. The number 1 reason I don't use linux as much is because I don't want to have to manage all of the different versions of software. Mozilla has a nice graphical installation, so do some other things. Not having to deal with rpms and all the other types of source and binary packages would be a great weight off my shoulders. You apt-get guys and you linux gurus might disagree. But I hope this is a trend that continues and becomes the standard for linux software.
    • actually, apt-get does make it simpler, just not in a graphical way.
      I use apt-get and debian because it takes the work out of maintainence. However, I'm thinking of actually switching to another distro for my girlfriends computer just because it will be easier for her to get use to.
    • What about Apple's even easier system? Some applications are just a drag and drop installation (including MS Office). Even the apps that come in packages are uber-easy. It even does prebinding for you.
    • If I could just install any piece of Windows software by typing "make install" instead of having to use useless installers, I would probably use it more often, too.

      Especially if that would include that I could tweak the installed software to my pleasure (and I'm not talking about ./configure, I'm talking about vi), or just installing it without having to start a GUI. But I guess Windows just isn't user-friendly enough.

      Hint: There are quite a lot of kinds of users, and not a single way to please them all.

      Not to mention that compilers are sexy, but I guess you have to be a geek to understand ;-)

  • Red Hat users note (Score:5, Informative)

    by GigsVT ( 208848 ) on Sunday July 14, 2002 @11:34AM (#3881707) Journal
    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 have done exactly this recently on three boxes with no trouble. Of course YMMV.

      What I did was do a standard RH upgrade to 7.3 on a fully up-to-date ximianized system. The RH installer complained that "third party applications" might no longer function. I had the option to continue and did. The system was quite functional when I was done. I ran redcarpet and had to re-subscribe to my Ximian channels and then do a substantial number of Ximian updates at that point. If I had continued without the Ximian updates it is possible I would have had problems.

    • by Anonymous Coward
      You can install Xmian Red Carpet without installing Ximian Gnome. That way, you can intall programs such as OpenOffice and update your computer with the latest RedHat security patches using red-carpet without losing the ability to upgrade Red Hat Linux.

      http://www.ximian.com/products/ximian_red_carpet /

    • 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.

    • I was able to upgrade from Red Hat 7.1 to 7.2 with apt-get for RPM (http://freshrpms.net) indeed I had to remove manually Ximian Gnome and use Red Hat Gnome instead.
  • I hate having to manually install things myself, so I use gentoo linux with a nice bsd style fake ports system, so when I want to install gnome for example, I just type "emerge gnome". Personally, I find that a lot simpler than waiting for that gui client to load up and then check through a bunch of boxes. The idea is simply great though. I think debian also has a lot of this, except that the packages are too often slightly out of date. When I ran red hat, the ximian red carpet was a godsend. Personally, I think it should come standard with red hat, for all those newbies who have trouble dealing with dependencies themselves.
    • 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?

  • Ximian Rules.... (Score:5, Insightful)

    by reaper20 ( 23396 ) on Sunday July 14, 2002 @11:37AM (#3881726) Homepage
    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.

    • by battery841 ( 34855 )
      Ximian and Red Hat, in some ways, are competitors on two fronts.

      First, Red Hat provides the Red Hat Network [redhat.com] which is a competitor to Ximian's Red Carpet CorporateConnect [ximian.com].

      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 [ximian.com] to help speed up Red Carpet downloads.
    • 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.


      Ximian is a company with a product, that product being Ximian Gnome. It's not freely available to be packaged without the consent of Ximian. If RedHat agreed to this they would then become Ximian's whipping boy. What would be smart of Redhat to do is acquire Ximian and make it it's desktop division if they think the desktop is going to go somewhere; then we can yell and scream about how RedHat is like Microsoft. Anyway the whole acquistion process would have to take place now as Redhat risk losing market and mind share to Ximian. Ximian would gain a foothold if they decided to do their own Linux Distribution just to make things easier for themselves and not having to support all the other distro's out there (this would also mean they would have to grow and likely lose focus on what they are good at). The primary people who use Ximian are also the primary people that would switch. So to make a long story short if Linux on the Desktop is coming then Ximian will have everyone by the balls in a corporate sense; but for right now you just play your position and you play it well and that is what RedHat and Ximian are doing. Obviously people will still be able to choose KDE, XFCE, Enlightenment 17 whatever else there is and for the people that don't use DE's then Window Managers etc or just the command line.
      • Oh by the way.. the above is what a free market is about.. One company doing what they are good at really well and another one doing something they are good at really well.. Mergers have taken the place of general scientific/public discussion of ideas in places like forums. So you get a little bit more bottom line, cut more people outta a job and a less quality product. Gotta love CEO's and the board.
    • My complaint is this: Why aren't distro's packaging ximian gnome as the default gnome distro?

      There's this [cofradia.org], but I don't know if anybody made a RH 7.3 version.
  • Flexibility Is Key (Score:4, Insightful)

    by MasterOfMagic ( 151058 ) on Sunday July 14, 2002 @11:37AM (#3881727) Journal
    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.
    • by Pengo ( 28814 ) on Sunday July 14, 2002 @12:08PM (#3881864) Journal
      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.
      • Configuration files were made to be edited by hand! This is why Linux is so popular, flexibility. ....

        This is exactly why Linux is NOT popular. I would hardly say that most people want to sit and jack around with config files. ....

        You know, I hate to say it but I think you're both right. The existing popularity of Linux is due to its stability, and much of that stability comes from traits it picks up from Unix brethren. That includes smaller separated programs and data transparency (both in input/output and configuration). Transparent configuration means, almost by definition, text file configuration. I happen to love it.

        But Pengo is taking the word "popularity" as a measure of abolute popularity, and he's correct, the "masses" can't handle text file configuration.

        I don't really see any need for change though. If Linux is an OS run by text file configuration, for which you can access a smart GUI wizard _if you want to_, then IMHO we will create the greatest OS in all time. And that seems to be the way we're going. I'll tell you right now how I would treat that - I would have a handful of configurations that are very important to me, like httpd.conf, smb.conf, named.conf, etc. that I will insist on hand-editing and make it my business to know all the commands for, and then I'll just use whatever's convenient for all the rest. For maintaining my web servers at work I need to know exactly what's in the config's, but when I come home and configure my home X server for casual use, I sure as hell don't need to edit the file, I'm happy to use a wizard.

        The difference is in the importance of that app to me. Note that, for example, to other users Apache will be a side item and so they will not open httpd.conf but use a GUI for that.

        Ahh. Freedom from registry bullshit but with the convenience of clickety-click when I choose it. Let's all join hands and sing Kumbaya...

    • ...now with all of the wizards..., people don't have to learn to use their computer.

      Not everyone wants to learn to use their computer, they just want to use it. That is a huge difference, and one that is keeping Linux off the desktop. I recently built a new computer for my parents, and I was *this* close to installing Linux on it instead of Win98. But they use it to email, look at pictures, check their stock prices, and surf the net a little. That's it. It was hard enough switching them over from Netscape 4.72 to Opera 6.02. I still get statements like "Well, it wasn't like that before", or "this just isn't what I am used to".

      I have a Windows and a Linux machine, and I spend much more time on the Linux machine (it is always running). I only boot up Windows when I want to play a game, or get pics off my digital camera because I haven't gotten gphoto to work with my camera yet. But I don't expect everyone to want to tweak around with Linux. You shouldn't either, and neither should the developers. The great thing is that we recognize this as a fault, and some people, different types of people with different ideas, can try to solve it. I don't mind the pretty gui install that came with Redhat 7.3. I liked that it was easy to install. Sometimes I like to have my hand held, and other times I like to compile things and mess with config files. The beauty of Linux systems is that you have the option. As long as distros have both options, tech and non tech configurations, I will be happy.

    • I hate wizards exactly for the reason noted -- they usually only know one way to do things. But GUI config tools are another matter. Here's a concept I've been waggling that I wish someone would grab and run with:

      A configuration manager that has a GUI with the checkboxes and such suitable for new users, while *simultaneously* displaying the actual result in the config file that is actually being edited.

      That way, as a new linux user, I can get the config job done without tearing out the last of my rapidly-greying hair, while *learning* (by being shown what I really just did) how to hand-edit that config file, if I so choose.

      You know how Dreamweaver 4.0 updates both WYSIWYG and raw HTML windows as you type in either window? So even if you don't know the first thing about HTML syntax, you have *opportunity* to learn as much about it as you wish, just by watching the raw HTML display of what you just typed. Anyway, what I have in mind is something like that, except that the user would only be "typing" (selecting checkbox options or whatever) in the GUI part.

      Alas, IANAProgrammer. (But when/if this ever flies, I *am* "the beta tester who can break anything" :)

  • No (Score:2, Insightful)

    by M&M ( 34839 )
    Do you believe that all Linux distributions should use such a friendly series of dialog boxes in order to attract more users to Linux?

    No. I don't think all distributions should include such dialog boxes. Not all users want all the hand holding. There should be different distributions for different types of users.

    I'm not comfortable on a Red Hat or Mandrake box because I like to do things myself. On the other hand, those who just want to "do stuff" wouldn't be comfortable with a Slackware or Debian box.

    Just my opinion

    • I'm curious, what exactly can't you do yourself on a Red Hat box?

      Just because they include some tools to try and be helpful to regular users doesn't mean that you have to take advantage of them. I can configure my install to do just what I want. If I'm setting up a server, it gets no X at all. No fluff. There is no problem in hand editing any configuration files. No problem installing anything out there. You're not restricted in any way that I can see.

      You made the statement, so please tell me, what task does Red Hat force you to use their tools to accomplish it rather than doing it yourself?

  • Keep It Simple Stupid! The more transparency to hide more of the detailed options from the users will help, especially considering I just installed WinXP onto a machine (as a test - to see what all the fuss was about) and it was a breeze. M$ may make crap operating systems, but they do know how to make good interfaces (maybe I should have stayed awake during my first year HCI lectures). But the option of hiding all the 'difficult' settings shouldn't come at the price of not letting the more knowledgeable user from being able to access those functions that are hidden, i.e. take WinXP vs. Win2k user accounts, hmmm lets go from multple user options to two -> 'root' and 'user', they hid so much stuff they lost it (a bit like their ethical backbone i suppose). Remember guys, KISS!
  • by warmcat ( 3545 ) on Sunday July 14, 2002 @11:42AM (#3881747)
    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!
    • 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.
      • 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.
      • Two better options:
        • Install apt-get from freshrpms and use to uninstall Ximian. Dependencies will be satisfied as necessary.
        • Reinstall ximian Gnome after your Red hat upgrade
  • Back to Dos (Score:2, Insightful)

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

    I think that it is vital that we keep the FUD about Linux being difficult to configure and setup true. I mean, why make it easier for end users, if they aren't geeks and contributing to the OS community, do we care?

    Wizards are for weenies... That is why evil Bill uses them so heavily, its not to make it easier for people to use his software... Its to limit feature creep... If you can guide the user right down the hall and not have him looking into each office along the way, you can reduce testing costs, less security etc.

    Damn, I hope Linux will start having more Wizards... It saves so much time and gives users a feeling of satisfaction and confidence... and with the Cancel button always there, a way to back out should they become concerned.

    What a dumb question to ask... Should we make software easier to use..

    Yes!!!!!!!!

  • I had a couple of major problems with Ximian's distribuion of gnome and ended up taking it off my system. Way back when, it corrupted the RPM database on a machine I was using. Though I found a few posts on the web about the problem, which was apparently due to an upgrade of RPM, no one had any solutions. I finally ended up formatting the system and installing Debian. Another time I installed it on Debian then later wanted to remove it to go back to the "Standard" version of Gnome. Removing Ximian and its assorted package dependencies turned out to be no easy task. So now I avoid Ximian. Apt-get does just about everything red carpet does anyway.

    Of course, I wouldn't ask my Mom to use apt-get. I'd put it in a cron job for her.

  • Correction (Score:5, Funny)

    by JoshuaDFranklin ( 147726 ) <joshuadfranklin ... AT yahoo DOT com> on Sunday July 14, 2002 @11:46AM (#3881766) Homepage
    TuxReports has snapshots of the Ximian installer.

    TuxReports had snapshots of the Ximian installer.

  • KDE needs this badly (Score:2, Interesting)

    by WCMI92 ( 592436 )
    I've been using Linux for the past 3 years. Love it dearly. I used to use Ximian GNOME, but have come to prefer the more mature and cleaner GUI of KDE (personal preference, NOT intended as a flame). Unfortunately, KDE is very hard, at least in my experience, to upgrade. I've used Red Hat and Mandrake distros, and have settled into using Red Hat mostly. I've never sucessfully upgraded a KDE installation on my box. Yes, I should try harder to learn how to do it, but I usually wait for another distro to come out with the upgraded version. Seeing as how painless Ximian GNOME is to install and to maintain/upgrade, I see no reason why KDE shouldn't have something similar. This is KDE's greatest weakness, IMHO.
    • mod him up. This is so true, I usually prefer KDE better but when new versions of KDE and GNOME come out, I always manage to easily and successfull upgrade GNOME but KDE on the other hand, I don't think I've ever managed to upgrade it. But sure enough their's usually a new version of Mandrake that comes out a little while later bundled with the newest KDE version. So I download it and voilà everything is installed and ready to go.

      Yeah you can call me dumb if you want, but if I can't upgrade KDE properly I'm sure that many others can't either. Do I really have to install a new Linux distribution every time a new version of KDE comes out? That's kinda ridiculous.
    • [ Warning: RPM-specific ]

      Yes, i know there should be an easier way for newbies. Inexperienced users should have a simpler way to install/update KDE.

      But I'm constantly amazed by the number of people who profess to be experienced Linux users who have difficulty with something like this. Jesus, is it so difficult to grasp that "programs" depend on libraries? Especially when the RPM installer tells you exactly what dependencies are not being met.

      I don't want to just add another whinge to this argument, so here's how I update KDE with RPM (on Mandrake), in the hope some-one out there will find it useful:

      Treat the KDE packages as three different levels of package:
      - the support libraries (including libqt* and (lib)arts*);
      - the central/base package (kdebase* and kdelibs*);
      - all the other kde* packages.

      Download all the packages into one directory (say /download/kde).

      Install the library/support packages first (including the devel packages, if you want them). When installed, move the packages into another directory (say /download/kde/done).

      Then install the central kdebase* and kdelibs* packages. Move them to the other directory (/download/kde/done).

      Then install the others (with rpm -Uvh *.rpm, or whatever, from /download/kde).

      If you're updating, either upgrade all the packages together, or upgrade as above with "--nodeps --replacefiles", or do it the hard way:
      rpm -qa|grep kde
      rpm -ev [each of the KDE packages]
      - leaving kdelibs* and kdebase* until last
      Then upgrade/install the new packages.

      Of course, on Mandrake, you could also use the badly-underestimated 'urpmi' command. But that would be too easy........ ;)

      Jesus, is this really so difficult?
  • I've been using Ximian with a boutique distro based on Red Hat (KRUD [tummy.com], a highly secure red hat put together by the guy that did the Linux Security HOW-TO, Kevin Fenzi) for over a year now. KRUD sends out an update CD every month with all the latest security patches, updates, etc etc and so far I haven't had any trouble doing upgrades. I also use Red Carpet for updates, but the KRUD CDs have a lot of things that aren't in the Red Hat or Ximian Desktop channels so I upgrade from both and have had no complaints so far. The only real complaint I have is that when the remove function warns you that package x will also have to be removed, it doesn't tell you which package caused that so that if you've chosen to remove 20 packages, and one of them causes something of moderate importance like XFree86 to be removed, you have to go back and deselect them one at a time and try again until you figure out which one you shouldn't remove. More verbose reporting of dependencies would be nice, is what I think I'm trying to say.

  • by dowobeha ( 581813 ) on Sunday July 14, 2002 @11:58AM (#3881819)
    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.
    • 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 [gnustep.org]. (See also LinuxSTEP [linuxstep.org], and the overview at GNUstep.net [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...

    • All software should be free.

      (if you don't know what I mean by free, then click on my sig)
  • by crovira ( 10242 ) on Sunday July 14, 2002 @12:05PM (#3881854) Homepage
    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.
    • by IamTheRealMike ( 537420 ) on Sunday July 14, 2002 @01:29PM (#3882152)
      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 [mailto]. This should go a long way to solving the software management mess that Linux has somehow got itself into.

      • > 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.

        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?

        • by IamTheRealMike ( 537420 ) on Sunday July 14, 2002 @03:46PM (#3882635)
          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.

          • This isn't the ideal approach

            I can say from my own experience that the user experience of running a "verify" command is actually surprisingly good.

            You probably know about the new installer technology for Windows (Microsoft Installer). One of the applications installed using msi is Microsoft Office 2000.

            I'm using Office 2000 (no flames please) and once had a problem with Excel, it would crash whenever I tried to use a certain feature (don't remember which one). Well, all MS Office apps have a menu item "Detect and Repair" (or something similar, I have the German version, where it is called "Erkennen und Reparieren") in the help menu. So I tried that. It asked me to insert the Office CD, which I did, then it copied some files and then asked me to quit and restart Excel. Amazingly, it did solve the problem!

            Of course I would have preferred to know what exactly was wrong and what files were replaced/reinstalled, but still, I must admit that I found the repair feature quite impressive. I guess that for users who don't even want to know the details of what's going on, the feature works perfectly.

            as the user would much rather have been warned beforehand.

            I'm not even certain about this. One thing about human interface design is that warning dialogs don't work. Windows does have such a warning message, whenever you remove .exe or (I think) .dll files, it warns you that this might cause applications to stop working (which is rather silly -- deleting any file might cause them to break, this isn't limited to DLLs and executables). I always simply click "Yes" when that dialog appears, and I guess most users do that.

            It would be very hard, if not impossible, to design that dialog in a way that makes sure that it is always read and understood by all users (including those users who do not know what dependencies are).

            And since unless you actually prevent users from deleting required files (which wouldn't be accepted by the majority of users, nor would it be a good idea technically), there will always be at least one case where files got deleted accidentally, so you need the "verify" feature anyway. So why not make it the easy-to-use default for solving installation problems?

      • 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. Sure, it's more convenient when it's already done, but if I see something in source form (or even a binary tar.gz), 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.

        Once you have an RPM or deb, the steps needed to actually install it are very easy (GnoRPM, cli rpm, RPMdrake, etc.). 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. Because there will always be something newer (newer version of something already packaged, or just something not yet packaged) which you'll want.

        • by IamTheRealMike ( 537420 ) on Sunday July 14, 2002 @03:55PM (#3882679)
          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.

        • Checkinstall is slick set of scripts wrapped around installwatch. Basically you do the ./configure and make parts as usual. Instead of "make install" you type "checkinstall" and pick slackware, rpm, or deb from a menu. It then installs the package and builds an rpm, deb, or tgz if it needs to be reinstalled later. The best part is that the package can be removed using the distro's normal package manager.

          It can even take an alternate command if "make install" isn't what installs the package. The other nice thing is that the resulting package can be installed on other machines running the same distro.

          It isn't good for "core" stuff like glibc but it's great for all these little proggies and utilities that I try out from Freshmeat. I used it with good results to get the latest Audacity and Galeon when they weren't in Debian testing.
      • We already have a standardized packaging system and I don't think autopackage will change that. Why not create a good apt-get frontend? Or, if you need to actually change somethign within RPM, submit your changes to the RPM maintainer. I wouldn't install autopackage on my system the same way I wouldn't install any other unpackaged app: the effectiveness of *any* management system is linked with its ubiquity.
      • Sounds a bit like my project LInstaller. Except I'm going the C route instead of bash script. I decided to use GTK+ 2.0 as the GUI side of the installer, but I'm currently rethinking that decision. The main problem I'm having is shared object filenames. Most distros are fairly similar, but I'll be damned if 90% of the libraries on any system don't have their "soname" field properly filled in. Hence compiling any application against them will produce binaries that insist on an exact version, rather than any version of the same major version.

        I suppose I could try to find an ELF header editor, so I could manually change the program dependancies to the correct values.

        On a side note, Mandrake didn't seem to provide libXft like Redhat does. Apparently Mandrake decided on their own Xft'less way. *shrug* Doesn't matter now, I've already switched back to developing on a Redhat system.
  • by Wesley Felter ( 138342 ) <wesley@felter.org> on Sunday July 14, 2002 @12:16PM (#3881885) Homepage
    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.
  • by dowobeha ( 581813 ) on Sunday July 14, 2002 @12:17PM (#3881894)
    ...

    /* 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";

    ....
  • But for experts as well, sure we know how to use configure; make; make install; but how tedious is that ? The homegrown RPM tools for the RPM based distros take time to learn and are slow, and if you're an expert already you know how to use the rpm commandline faster than the GUI. But wouldn't it be nice to just click on setup.sh or just run setup.sh and have the program do everything for you ?. If anything, have a GUI frontend to configure, so configure -d gives you all the options and you just check on them ?.
    I think linux needs something like a VISE installer, that will follow the LSB.
  • Naw (Score:5, Funny)

    by B3ryllium ( 571199 ) on Sunday July 14, 2002 @12:33PM (#3881944) Homepage
    I think most people here would prefer to install linux by manipulating the hard drive with magnets ...
  • already? (Score:2, Informative)

    by MrVinz ( 592837 )
    wow, something that people been yelling for years.. are they finally going to make things more user friendly? The ONLY thing keeping me from changing to linux (windows user now of course) is the userUNfriendliness.

    Seen the setup of KYLIX? (Delphi for linux) that's how it's s'posed to be.

    Cheers.
  • Only one installer question should be needed:

    Do you really want to install (insert name of program to install here)?
    Any more than that, and half the world would not be able to install it right.
  • How many people have had real trouble installing anything on a Linux box, really? Not upgrading (that can quickly get seriously bad), but the initial install.

    I've recently installed OpenOffice, Gimp, Gimp-Print, QT3, Ogg v 1.0 (released today!), and Ghostscript - some source, some binary - and all I had to do was follow the short instructions in the INSTALL/README files.

    It just doesn't get much easier than that on a system that's worth having.

    Like I said, though, upgrades of binaries quickly becomes a nightmare with things like KDE where there's lots of interdependacies between lots of packages but installing isn't that hard any more.

    Even then, if you are Joe Average you'll probably just wait for the next point-release of the whole distro and that will generally update everything in one fell swoop anyway.

    Maybe even upgrades are just a problem because the sort of people that use /. are the sort that fiddle with their systems all the time and get themselves into trouble.

    TWW

  • by toolz ( 2119 ) on Sunday July 14, 2002 @02:24PM (#3882350) Homepage Journal
    # 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
  • To each his own. I enjoy that I have the option of tweaking an application the way I want it it work, however the real question lies with this:

    How many end users, meaning workstation users actually do this? I want the ability to install a powerful desktop management software tool like gnome2, however I cant justify clouting my system with libraries that remain even after a "full" removal. We get into the very same problem we saw back in windows 3.11 where removing a program REALLY didnt remove all of its contents. What we are looking for is a system that doesnt need to cleaned, but one which is self contained within a packaging system. Ximian has the right idea and thats why i will wait until they put out GNOME 2.0, rather than painfully going though each rpm, each tgz, each bz2 file. It just plain sucks, Ximian offers a CLEAN approach to installing GNOME2.0. To them and however they do make money, I say thank you!

    All the linux community wants is easy package management that handles dependencies somewhat transparent. For those of you who have wasted hours of your precious life trying to install these components separately, my hat goes off to you...

    Beware, the trend of OSS is in danger by commercial entities claiming stake to what is rightfully GPL'ed...SLASHDOT I do believe this another issue.

    FreeBSD AND Mandrake you guys ROCK!!
  • ...and at the end of the day, 99% of people just want to get their work done. We /. readers forget that we're in a vocal minority. Most people could care less about 'flexibility.' They simply want to get their work done. That's why Mac OS X has taken the world by storm (and Linux has failed to outside of the small geek subculture). Case in point: I had a party the other night, with a mixed group in attendance: everyone from engineers to musicians to sculptors. When I mentioned Linux, I got mostly blank stares. However, when I mentioned OS X, people said, 'Oh yeah! Macs rock!' In fact, my next non-Windows system will most likely not run Linux. It'll run Mac OS X.
  • My only problem with red-carpet is that it considers the -ximian version as an update to the ones that the distro has for the EXACT same release.

    What happens is that redhat's up2date putss the RH version of the item, and then redcarpet wants to reinstall it as the -ximian version.

    I understand that they do this to make sure that the dependancies are completely known to their system so that their own apps dont break... but still... annoying...

    PS: this also makes it so that when upgrading a RH72+ximian system to rh73, you get that annoying warning... Luckily going ahead with the update (ignoring the warning, which installs RH versions of some of the same files that red-carpet had updated); and then RERUNNING red-carpet again on R73 gets things working correctly again by reinstalling the -ximian versions of things...

Keep your boss's boss off your boss's back.

Working...