Ximian Desktop Installer, Red Carpet, and MonkeyTalk

How do they make any money? by glrotate · 2002-07-14 04:31 · Score: 2, Interesting

I know they've got deals with various Unix hardware vendors, but how does Ximian plan on making money off of Red Carpet?

KISS and the GUI M$ approach by Devoras · 2002-07-14 04:41 · Score: 2, Interesting

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!

what happen to slashdot we love of the past?? by Anonymous Coward · 2002-07-14 04:42 · Score: 1, Interesting

that's 2 years now slashdot's been really borin. two years since anythin interestin every been on it and i read it every day!!!

KDE needs this badly by WCMI92 · 2002-07-14 04:48 · Score: 2, Interesting

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.

--
Corporatism != Free Market

Re:Making it easier.. by loply · 2002-07-14 04:51 · Score: 2, Interesting

Hes right though. I dont think you can "have everything". Do we want this to be a hardcore, technical OS which is therefore highly powerfull and flexible - or - do we want to dumb it down so that its configuration and use is accessible to all and therefore less powerfull.

Nobody has ever achieved both of these to any great extent in one OS. I dont think its possbile to have Linux style power with Windows style newbie-friendlieness (note: newbie friendly != user friendly).

--
loply.com

Re:Great, but has its downside by chabotc · 2002-07-14 04:52 · 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.

There are only a few installer packages by crovira · 2002-07-14 05:05 · 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.

Re:There are only a few installer packages by IamTheRealMike · 2002-07-14 06:29 · 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.
Re:There are only a few installer packages by IamTheRealMike · 2002-07-14 08:46 · 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.
Re:There are only a few installer packages by IamTheRealMike · 2002-07-14 08:55 · 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.

Re:Flexibility Is Key by Pengo · 2002-07-14 05:08 · 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.

Who needs installers? by Wesley+Felter · 2002-07-14 05:16 · 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.

Re:Great, but has its downside by mickwd · 2002-07-14 08:44 · 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.

Will wait for Ximian's Gnome 2.0.x by mylogic · 2002-07-14 15:49 · Score: 2, Interesting

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!!

Slashdot Mirror

Ximian Desktop Installer, Red Carpet, and MonkeyTalk

14 of 314 comments (clear)