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.

Comments

Red Hat users note

[GigsVT]

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.

Re:how about this?

[flsquirrel]

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.

Ximian Rules....

[reaper20]

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.

Flexibility Is Key

[MasterOfMagic]

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.

Re:Flexibility Is Key

[Pengo]

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.

Great, but has its downside

[warmcat]

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!

Correction

[JoshuaDFranklin]

TuxReports has snapshots of the Ximian installer.

TuxReports had snapshots of the Ximian installer.

Take a note from Apple

[dowobeha]

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.

Re:How do they make any money?

[kerskine]

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.

There are only a few installer packages

[crovira]

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.

Re:There are only a few installer packages

[IamTheRealMike]

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.

Re:There are only a few installer packages

[IamTheRealMike]

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.

Re:There are only a few installer packages

[IamTheRealMike]

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.

Re:The Easier the Better

[donnacha]

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.

Naw

[B3ryllium]

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