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.
how about this? (Score:1, Insightful)
Re:how about this? (Score:4, Insightful)
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.
Re:how about this? (Score:2)
I can not '$>man OkButton()', while I can 'man find', or 'man ksh', etc...
Re:how about this? (Score:2)
Re:how about this? (Score:2)
How do they make any money? (Score:2, Interesting)
Re:How do they make any money? (Score:2)
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.
Re:How do they make any money? (Score:4, Informative)
Re:How do they make any money? (Score:2)
- 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
The Easier the Better (Score:2)
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.
Re:The Easier the Better (Score:4, Insightful)
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.
Re:The Easier the Better (Score:2)
Your comment reminded me of a ManPower temp assignment I got a while back. It was a 2-3 day temp assignment that involved data entry. When I arrived at the business and received my instructions, it turned out that they wanted me to take all the data in an "ACT" database and manually enter it into an Access database. At any rate, this made me start twitching uncontrollably. I started off doing the assignment the way I had been instructed (that's just what you do when you are temping). As soon as my supervisor left for lunch, I did an export/import and was done by the time she got back. The moral of the story is, people waste enormous amounts of time because they don't understand the software tools they have.
Here's another example. My sister was temping for an online information publishing company. They had been outsourcing their Resume/Job application stuff to a third party who was going out of business. They needed to move something like 10-20 thousand applications/resumes from the third party to a new provider of the same service. After talking with both the old and new vendor, HR came up with this wonderful idea. The original vendor would email the publishing company all of the applications/resumes. The publishing company would then print them out and ship them to the new Resume/Application company. The new company would then manually scan all the resumes into their system using scanners/text recognition. The whole process took a little over a month. I kept telling my sister that it could probably all be done in a couple days with proper coordination and maybe a little perl script, but then of course, she'd be out of a job.
Re:The Easier the Better (Score:2)
Most of the world, however, has a long, hard slog in front of it. This isn't helped by the culture of dispowerment that Microsoft promotes under the ingenious guise of empowerment. Open Source software doesn't deliberately disempower it's users as it has no particular motivation for doing so whereas proprietry products essentially want to lock the user in for the longer term.
Where OSS often falls down is in assuming that anyone with an interest in it will already be a hacker. This is just plain wrong, especially when you take the poorer majority of the human race into consideration. They don't have the necessary skills/cultural exposure for OSS or the $$$ for M$ and, therefore, for most of our species computers may as well not exist.
The best thing about Open Source software is that it doesn't lock it's users in.
It's main failing is that it locks them out in the first place by setting the skills bar unnecessarily high.
Re:The Easier the Better (Offitopic: -1) (Score:2)
Good luck with all of that!
Now back to the topic at hand....
Re:The Easier the Better (Offitopic: -1) (Score:2)
Re:The Easier the Better (Score:2)
You Dumbass!
YES (Score:2)
Re:YES (Score:2)
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.
Re:YES (Score:2)
Re:YES (Score:2)
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)
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:Red Hat users note (Score:2)
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.
Re:Red Hat users note (Score:2, Informative)
http://www.ximian.com/products/ximian_red_carpe
Re:Red Hat users note (Score:3, Informative)
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 ~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;libvorbiWhat 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.
Re:Red Hat users note (Score:2)
Re:Red Hat users note (Score:2)
Don't be an elitist asshole [penny-arcade.com]. If you don't understand what the problem really is, don't comment on it.
This problem has nothing to do with rpm. The problem that Red Hat advertises WRT Ximian is that an upgrade may not upgrade all of the GNOME packages, since Ximian's may be newer (and this is the correct behavior, according to any packager). However, because some packages may be updated, and others may not, you don't have a tested, known-stable GNOME platform. dpkg and apt don't do anything special that prevents that from happening.
Re:Red Hat users note (Score:2)
I used to think that way about them too, until I found them to have the most functional distrobution out there.
In fact, RH is much more supportive of open xsource software standards than the "united Linux" also-rans. At least RH supplies source code. United will not.
RH, while famous in our own little Linux world, are not very corporate at all. Your larger sized supermarkets (not a chain, just a single store) have more revenue.
RH is functional and is dedicated to open-source standards.
Well, it's already here in a lot of ways (Score:2, Insightful)
Re:Well, it's already here in a lot of ways (Score:3, Insightful)
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?
Re:Well, it's already here in a lot of ways (Score:2)
Go to bed!
i just dont get the gentoo system, why dont they have i386 binary packages?
Are you using a 386?
TWW
Re:Well, it's already here in a lot of ways (Score:2)
Ximian Rules.... (Score:5, Insightful)
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
Re:Ximian Rules.... (Score:3, Insightful)
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.
Re:Ximian Rules.... (Score:2)
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.
Re:Ximian Rules.... (Score:2)
Re:Ximian Rules.... (Score:2)
Re:Ximian Rules.... (Score:2)
There's this [cofradia.org], but I don't know if anybody made a RH 7.3 version.
Flexibility Is Key (Score:4, Insightful)
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
Re:Flexibility Is Key (Score:5, Interesting)
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.
Re:Flexibility Is Key (Score:2)
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...
Re:Flexibility Is Key (Score:2)
Dude, your definition of easy software is wizards? You misunderstood what I am saying. Intututive software is what we need, and not needing to dig around in text files.
Again, this elitist attutude is not helping anybody.
Re:Flexibility Is Key (Score:2)
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.
Re:Flexibility Is Key (Score:2)
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)
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
Re:No (Score:2)
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?
KISS and the GUI M$ approach (Score:2, Interesting)
Great, but has its downside (Score:4, Informative)
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
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!
Re:Great, but has its downside (Score:3, Interesting)
# 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.
Re:Great, but has its downside (Score:3, Interesting)
What if you had some distro-installed library packages which Ximian came in and updated? If you do the "rpm -e
This is a good way to "break" a lot of your favourite programs.
Don't ever use --nodeps like that (Score:2)
Back to Dos (Score:2, Insightful)
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 got rid of Ximian (Score:2)
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)
TuxReports had snapshots of the Ximian installer.
KDE needs this badly (Score:2, Interesting)
Re:KDE needs this badly (Score:2)
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.
Re:KDE needs this badly (Score:2)
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
Install the library/support packages first (including the devel packages, if you want them). When installed, move the packages into another directory (say
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
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?
personal experience (Score:2)
Take a note from Apple (Score:4, Insightful)
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
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:Take a note from Apple (Score:3, Informative)
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...
Take a note from GNU (Score:2, Insightful)
(if you don't know what I mean by free, then click on my sig)
Re:Take a note from GNU (Score:2)
Absolutely. And, well, my senses say that something like that is cooking.
Re:Take a note from GNU (Score:2)
As far as ease of use, we have that. From what I've heard, GNOME 2 has taken out a lot of its configuration options. Additionally, Sun has been doing a lot of usability studies on the GNOME interface.
Really, with KDE and GNOME, GNU/Linux is very easy to use.
Just remember, ease of use comes at a price. Making things too easy just isn't worth it.
Re:Take a note from Apple (Score:2)
For the record, I'm anti-mac - we don't need another repeat of the Windows debacle. However, this is a technical issue, so I'll try and be unbiased. Here is what I've learned from asking the same question:
Mac's don't have shared libraries as such, the closest there is (in os x at least) is Frameworks. Frameworks are collections of features, I'd guess they're made up of shared libraries but I'm not sure. Frameworks can be installed by dragging them into the frameworks folder (in the library). However, I've never heard of anybody actually doing that, basically Apple are the only ones who put new frameworks on the system.
Many Mac apps are atomic, ie they are stored in a folder with a special attribute. To "install" them, you just drag the appfolder to the Applications folder. This is great from the users point of view, it keeps things simple. I looked into it for my autopackage project (see another post i made for details). However, it turns out this is a technically extremely poor way of doing things. It means there is virtually no code reuse on the Mac, as there is no dependancy tracking engine. It means that apps distributed as appfolders also do not have any install process AT ALL, so they cannot ask for EULA agreements, check your system for stuff it needs, alter its configuration and so on. The appfolders system is good enough only for very simple apps.
So Apple ship an "Installer" program also. This is used by some more complex apps, but I'm not sure what it's capabilities are. Usually, the result of the install program is simply a new appfolder, except in cases like XDarwin which add files outside the Mac namespace. Sometimes if neither of these approaches work well enough, Mac programs ship with InstallShield style installer stubs, with the problems this entails (no headless network install for instance).
So we can see that the Mac has the most inferior software management system of all the platforms (even linux, which at least tries) from a technical perspective. From the users point of view, it is ideal. Typical Apple design here - I'm not going to comment on whether this is a good or bad thing.
Conclusion: the Mac has the simplest and most direct method of managing software you can get, but at a big sacrifice, as there is no code reuse (there is no equivalent to COM/CORBA as far as I can see either) and apps are incredibly limited as to what they can do during installation. Because of this, some apps work around the appfolder system by using installer stubs, negating the whole point of the system (simplicity, consistancy ) in the first place.
Re:Take a note from Apple (Score:2)
You can also build non-framework dynamic libraries and put them in /usr/local/lib or /usr/lib just like you can on any other unix.
I never said Macs didn't have shared libraries. What I said was they aren't used to nearly the same extent as on other platforms. Also, frameworks are largely only addable by Apple. How do you ensure your program always has a particular framework? There is no way, except by using an installer stub like InstallShield/Wise. It's easier to simply say "requires 10.2" or whatever, which isn't really code sharing.
Re:Take a note from Apple (Score:2)
You could probably by 10 macs a month if you really really wanted and had a bit of luck (and a lot of persistence).
Beign said that, you shouln't but a mac just because you afford it. I don't think I will buy one!
There are only a few installer packages (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Re:There are only a few installer packages (Score:2)
> 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?
Re:There are only a few installer packages (Score:4, Interesting)
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 (Score:2)
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.
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?
Re:There are only a few installer packages (Score:2)
Re:There are only a few installer packages (Score:2)
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.
Re:There are only a few installer packages (Score:4, Interesting)
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.
I use checkinstall (Score:2)
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.
Good luck (Score:2)
Re:There are only a few installer packages (Score:2)
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.
Who needs installers? (Score:3, Interesting)
Actually, I'd like to see Linux preinstalled on more computers so that users don't have to install at all.
Package installer version 66.6 (Score:3, Funny)
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";
Not just for newcomers (Score:2)
I think linux needs something like a VISE installer, that will follow the LSB.
Naw (Score:5, Funny)
Re:Naw (Score:2)
already? (Score:2, Informative)
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: (Score:2)
Only one installer question should be needed:
Any more than that, and half the world would not be able to install it right.Installing isn't the problem anymore (Score:2)
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
Re:Installing isn't the problem anymore (Score:2)
Yes. To read some of the comments here one would think that Windows users never had a problem with their installs.
TWW
from /usr/lib/anaconda/upgrade.py (Score:3, Funny)
# 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
Will wait for Ximian's Gnome 2.0.x (Score:2, Interesting)
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!!
Hiho! It's off to work we go... (Score:2)
The problem is when different installers disagree (Score:2)
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...
Re:no... (Score:2)
Hrmn. Well, it's not as though redcarpet is *replacing* debs or rpms. It's a GUI, nothing more, nothing less. That it's easy to use and looks sharp is a nice bonus.
You're still able to install things by building from source or via deb or rpm. It's merely giving you more choice and making it conceivable that your mum can keep her own system up to date / install software for herself.
Re:no... (Score:2, Informative)
Re:Easy is good for veterans too (TM) (Score:2)
Have you not heard of Debian before? Or Gentoo? Your argument is utterly invalid. I have been using Linux for nigh on 2 years and have not experienced a single dependency related problem, excluding the ones Ive helped RedHat users with on IRC!
Re:Easy is good for veterans too (TM) (Score:2)
It's not a distro war. It's just a suggestion. RedHat does have problems with dependencies. Debian does not have problems with dependencies. Debian just works, and keeps on working, no matter how much you upgrade it. apt-get update; apt-get upgrade have never given me troubles. And it has saved me a lot of time, compared to earlier times when RedHat, Mandrake or Slackware forced me to do a reinstall every 6 months (if I wanted something new to play with). I realize that there are other reasons to like RedHat (such as commercial support (nah, probably not), or that it's the preferred target of most commercial application vendors (yes, that's really a good reason). But if solving the dependency problems are more important to you, then Debian is the way to go.
Re:Making it easier.. (Score:2, Interesting)
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).
Re:Making it easier.. (Score:2)
Frex, in Windows I can either use TweakUI (handy GUI that present options in a format the average user can understand) or RegEdit (hand-edit where you REALLY need to know exactly what you're doing -- anyone here want to claim the registry is "dumbed down"??); in DRDOS, I can configure the system by using the installer configuration doodad, which makes config decisions easy for newbies, or I can hand-edit the config files myself (again, needing to know what I'm doing) and achieve the exact same end result.
Now, if DOS and Win32 can both manage this, why not linux??
I swear, the real problem is linux bigots who measure their self-worth by the degree of superiority they feel because THEY can handle an abstruse OS, but lowly average folk can't.
I don't need no monkey accessories (Score:2)
If I wanted to make Linux accessible to monkeys I would shape it like a stick and place it under a banana tree.
Seriously, though, a nice user interface never hurt anybody. Just let us geeks keep our command line and we'll be happy.
Re:Definatly! (Score:2)
Re:Standard installers (Score:2)
Re:Red Carpet in great but the Installer isn't. (Score:2)
but UM... here is where the power and verstile nature of the Linux file system structure comes to play. You have at least two possible options.
1-symbolic links... [first move the redcarpet dir, then link the location that the app expects to find the files to the new location]
mv
ln -s
2- Mount a bigger disk in
Re:Cute graphical installers... (Score:2)
I mean, a gui has to give all the options through visual elements, meaning a lot of buttons/menus to navigate. The only way to keep any reasonably powerful application from being unwieldy is to stick options into many submenus. While this helps those who do not know what options or available, or need prompting to remember what to do, for people who do know and remember, the command line allows entering it directly. Hell, with a nice shell and good completion functions, tab completion could show what can be done at any point. GUIs are nice to complement command line utilities, but people using the command line are not simply doing it to be 'elite'.