With BitRock Installbuilder, BitRock aims to make easier to install and distribute Linux applications. It allows you to create easy-to-use installers that can be run in GUI, text, and unattended modes.
BitRock Installbuilder: New Linux Application Installer
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I must say, it looks really nice, I hope it catches on.
I just hope they will also support Slackware’s TGZ-based packages (in fact this might be very easy to support) and also FreeBSD.
This application reminded me another such installer engine, but for BeOS: http://www.omicronsoft.com/beos/easyinstall.html
It was really nice too.
It’s neither free nor open source, so 99% of the zealots will pass it right over…
(Not saying that’s my opinion btw, I think an app installer standard is very much needed.)
looks pretty good. something like this is needed, but not at the price.
is it dual licensed? so gpl projects can use it for free?
something like this, which during the install process gave you the option to create launchers on the desktop/menu would be cool…but we need a more open version. something that would work with rpm/deb/ebuild.
but thats the problem, there’s too much fragmentation at the moment, something like this done the right way would be hard to do…
It says in the “Coming Soon” section on the product page that they plan to support RPMs and DEBs. If it doesn’t support either of those, does that mean that it currently works by its own sort of package management scheme? If so, someone could probably port it to TGZ in a day.
Well, I am sure this product is not targetting these zealots.
It targets companies which now start to port their applications to Linux and they need an elegant way of distributing their applications for easy installation under various Linuces. In this regard, this InstallerBuilder product was much needed.
For example: Real, Flash, LimeWire, Moho, TheKompany apps, Opera, IntelliCAD, MainActor, ThinkFree, Adobe Acrobat, VMWare etc, they can all benefit from it.
$495 per developer seems like a lot of money for any small-time or not-for-profit establishment.
I do believe it’s directed more towards bigger software companies.
Hopefully it’ll draw at least one company to Linux.
I wish, the website can show the more info about it. Hope, I didn’t miss anything in the website so far as I surfed in there. I am wondering how does it deals with the dependency?
To answer this question, you have to understand who this product is TARGETTING. It mostly is targetting companies with closed source software (or big OSS software houses), and these companies often offer binaries with many things statically linked, so they can run on many distros at the same time using the same binary, more or less.
In this regard, this installer is not and should not be considered with dependancies. This is something that software companies bundlers will have to figure out. As for the times where e.g. a debian binary can’t work with Red hat no matter how much you tweak it, in these cases you just offer two bitrock installer binaries, one for debian and one for red hat. In other words, dependancy is not really needed and not necessariy is wanted by these binary software houses.
More here about this:
http://www.bitrock.com/products_installbuilder_features.html
Looks like a good multi-platform solution, but it is very pricy. There are very few companies who actually support OSS OSes, and off the top of my head I can’t think of one who would actually benifit from using this. The price is also way too high for any `amateur’ programmer who is looking for an alternate way of distributing his/her packages. Perhaps BitRock might consider making a personal edition available for personal and non-profit projects, that maybe the only way this packager would catch on.
They’ve made a Linux installer, but their webpage with screenshots of it does not display screenshots in Firefox.
But it does in Internet Explorer.. ?
Funny.
There are plenty of Linux based software installers that look great AND are GPL. We have used some of them for our software products. Just look <a href=http://freshmeat.net/search/?q=%2Binstaller§ion=projects&x=….
It’s all nice and great, but if it’s already being done under the GPL, what’s the need of something not GPL’d?
And I’m not a zealot, I’m practical.
I agree with you Jack. I think their software is a bit expensive to easily “catch on” and get enough mindshare in the Linux market.
That BeOS installer I mentioned earlier, it has similar capabilities and features, and only costs $49, which I believe is actually a bit cheap if you had that on Linux or Windows (its price is fair for beos though because there are not many who would need such an app on BeOS today).
On the other hand, such an app for MacOSX (with many more features, granted) like InstallAnywhere, costs between $995 and $3000 USD! Yup:
http://www.versiontracker.com/dyn/moreinfo/macosx/14688
http://www.versiontracker.com/dyn/moreinfo/macosx/10714
http://www.versiontracker.com/dyn/moreinfo/macosx/10715
Personally, I believe that a per-release license for about $100 or $300 for per-project, might be best for Bitrock’s Linux version. But currently at $500 does seem a bit steep for the Linux market (however it does sound logical for the Windows/OSX market).
Garret,
I took a look at your Freshmeat URL and checked out all the Installer Builder apps. Here is the lowdown from the ones that are actually distro-unspecific Installer builders (that means, they are not just for RPM or just for DEB files but they can build their own independant packages with or without dependancies).
From that bunch, the following are out of the question because they are built in java. Not all distros have Java installed and not all users have it installed manually (remember that Bitrock’s targetting customers need to be able to get to as to many users as possible). The best bet is to go with Motif or TCL/TK, but these days, GTK or Qt is maybe an even better bet.
So, these are out because of their java dependency:
http://freshmeat.net/projects/jexpressprofessional/
http://freshmeat.net/projects/vainstall/
http://freshmeat.net/projects/freeinstaller/
http://freshmeat.net/projects/install4j/ (seems to be the best of the bunch)
http://www.izforge.com/izpack/
Close, but looks like crap:
http://freshmeat.net/projects/noodleinstaller/
This is close too, but it is not the same as Bitrock. This one sorts out dependancies, it is like a universal front end for DEBs or RPMs more than anything else, however it does have Bitrock’s characteristics. It is in early development still though:
http://freshmeat.net/projects/autopackage/
Now, this one seems to be the only one that is really close to what BitRock does, but their site is not offering much info of its features and what not, so it is difficult to say if this can compete with Bitrock:
http://installbase.sourceforge.net/main.shtml
I am using Firefox and the screenshots display just fine if you click “Screenshots” on the left side
It’s always disappointing to watch someone try and knock something down before it even has a chance to get started especially in this case where the particular software is much need(well in my own opinion at least). What makes it even worse is when the person is wrong. Or does that make it better? I dunnoooo. You all can decide.
Eugenia, that was quick.
I typed my post on the way out the door and headed home, and I see you’ve already been hard at work.
The last one does look pretty good though . . .and maybe I’m a bit more of a zealot than I let on to be. 🙂
Thanks
yeah, they don’t work in firefox here either.
They work, but it’s buggy and the workaround is non-intuitive. After you’ve already clicked on screenshots and let the page load, click it again and the screenshots will load. Screwy, but it works.
I am grateful someone is trying to validate this stuff commercially, but I am extremely sour on the prospects for anyone trying to make money on software these days that doesn’t have an already huge legacy market (i.e., Oracle).
The market for selling software is just vicious. I would feel more confident in the longevity of this code if the developers had other jobs to see them through rough patches.
Man it took all of this time for someone to finally come out with a installer that can be text,gui,etc. I don’t know why the geeks were like “man it’s impossible you can never have an installer thats text and/or gui.” I don’t know why not, personally they sounded like the people saying “the world is flat” and the world would somehow collapse if something like this happened. Look the world hasn’t ended you haven’t lost any advanced options, quit complaining.
This is the first step BADLY needed to make Linux easier to use. Now if only the linux developers would get out of denial and start making linux easier. I just wanna get in, do what I want and get out without having to configure stuff that really should just be initialized to defaults. Until then Mac OS X & (unfortunitely) Windows will be the os’s I use most with linux a distant 3rd on my list. It may not be free, but at least someone has finally gotten around to creating something that should have been completed years ago.
I really hope this is just a stop-gap solution for certain companies distributing binaries. God knows I’ll be happy if I never have to see another Motif installer again! Maybe Sun will take a hint and use this to make Java less of a bitch to install?
But going forward, I think something like Ximian’s Build Buddy is the best way to go. Face it: installers are obsolete. Intelligent package managers take the “Add/Remove Programs” concept to the next level, by letting you actually add programs as easily as removing them. Not to mention who much nicer things are when upgrades and dependency-tracking are done automagically.
One of the few remaining problems with existing package managers (aside from GUIs that need to be simplified) is that the package you want isn’t always available for your distribution. Build Buddy solves that by making it extremely easy to package your software for multiple platforms. It automates the procedure of generating .deb’s, .rpm’s, etc. Combine this with a way to easily add repositories to your configuration (perhaps with a special web link type like mailto:) and you can consider application installation/removal solved.
Couldn’t agree more… You hit the nail on the head, Rayiner. Linux does not need a Windows-style installer. Isn’t that one of people’s primary complaints about Linux: They only copy other platforms? Shouldn’t we come up with something original, and more-powerful? Instead, many of the readers of this site only what Linux to regurgitate an antiquated installer paradigm.
This is a networked world: I should not have to download a 33 meg binary when I’ve already got the 25 megs of libraries installed.
In the world of fast internet connections and GBs of hard drive, this is irrelevant, sorry. You sound like the assembly programmers in 1995: “but, but, our program runs in only 512 KB of ram, and it only takes 300 KB of space, oh and it is 3% faster than your C++ 1 MB program!”
My point is that these qualities of “relative speed/efficiency” is a geek thing. Real users just want the ease of use much more than the under-the-hood efficiency. That’s the reality of the market, and this is why OSX and Windows do things the way they do it and they don’t have a source-based packaging system.
And before you reply to my above comment and say “but we are talking about Linux”, remember again who is the target market of Bitrock: commercial companies who want to deliver an easy-to-use installation for their products. For all Bitrock cares, all the GPL people can still use whatever tools they want to use, these users are not their target market.
For sure, OSX and Windows don’t span on many architectures as linux and others unix, and don’t have so many configuration options. That is what make linux so hard to target by a binary general package tool, be it text or graphical or whatever, and the reason source code compiling is still so frequently used.
I think it was discussed already here in osnews.
Personally, I would like to see more collaboration from linux distros, not to use a common package manager, but to publicize an common style sheet of what options they used for their distros. That should help a lot.
I’m not saying anything about geeks. Real users should love package managers, because they get lots of real benefits from them:
– Code reuse. This isn’t just a developer thing. Users notice when their apps are more stable because they all use the same well-tested libraries. They notice when things are more consistent because they all use the same libraries. Linux might not be as consistent as OS X, in a lot of ways, but without code reuse by shared libraries, it’d be way less consistent than it is now.
– Download size. Nero is a 22MB program. k3b is a 5MB program. Most people, at least here in the USA, are still on dialup. 17MB makes a difference.
– Ease of use. It is much easier for a newbie to understand a UI like Synaptic or KPackage, than to understand the quite complex procedure of running a Windows installer. The Windows installation method brings lots of different factors into play. Before they ever start the installation, they have to be able to find the installer, download it, find it in their filesystem, and run it. Then they have to understand the installer itself. I recently taught my mom to use e-mail. I’m certain I could teach her how to use Synaptic. After all, both are very straightforward tasks where you just click certain buttons in a certain program in a certain order. I could *not* teach her how to use a Windows installer — its simply way too involved.
– Ease of maintainance. Crappy installers is a primary reason why Windows installs, if not carefully maintained, decay over time. They leave junk all over your system, old DLLs, registry entries, etc. With a package manager that tracks every file, you just don’t have to deal with that. And don’t forget ease of upgrading. Linux software evolves quickly. Upgrades must be done efficiently. Windows-style manual installers would be *unusable* for Linux in the general case. Also take into account that many machines are on a corporate network, and smart package managers make things a lot easier on network admins.
The primary problem, now, with package managers is availability. Hopefully, tools like Build Buddy will remove that problem too, by allowing developers to easily make many binary packages availabe.
Package managers are a step *forward* for usability because they free the user from having to do anything other than simply selecting what software they want installed. It doesn’t get any easier than that, at least not until computers develop telepathy!
I downloaded the builder and will test it out over the next few days. Though I must admit, at $495 a pop, I doubt I will purchase it – my business cannnot justify that cost at this time.
While they may be targetting larger businesses, I think that for the most part, Linux apps will be coming from smaller groups of independant programmers, working alone, or in small teams, and the cost would not appeal to this market. Perhaps they should rethink their marketing position.
If the application is everything it purports to be (and I have no reason to doubt it is), then they may find a lower cost will result in further sales from the frontier oriented mindest of the Linux community.
One thing I learned from my travels in the Linux wilderness is that many models used in business, government, and (dare I say it) law do not apply to the changing digital landscape. One thing has not changed – it is still a darwinian process.
I ran the screenshots page through an html validator (wdg http://www.htmlhelp.com/tools/validator/ ), and found it full of errors.
Incredibly, I am seeing this in a lot of mainstream sites – web developes take note – broken code will behave irrationally in different ways in different browsers. Check your code befor releasing it!
and I should check my spelling before posting ( sighhhh…)
Oh come on. Not all of us who care about free software are zealots. A lot of us just don’t want our basic computing tools to be out of our control. Just because you do not care does not mean there is no merit in the fact that other people care. After all, to most people a circular saw is just a tool, but if you are a carpenter, you can bet that you yours intimately enough to fix problems when they arise.
What happened to autopackage, that was some great stuff!
It’s still in development. In fact, we’re going to release 0.4 in the next few days.
Face it: installers are obsolete. Intelligent package managers take the “Add/Remove Programs” concept to the next level, by letting you actually add programs as easily as removing them. Not to mention who much nicer things are when upgrades and dependency-tracking are done automagically.
Bulding packages for even the most used distros is hard. Maybe this will be easier in the future due to Build Buddy.
However, package managers are not yet a good solution. I *really* love apt-get for its dependency tracking but a the graphical front-ends are nearly useless althought that’s not the fault of their developers. The overwhelming number of available packages, their irrelevance (being not interested in package written in an outdated widget set, for example, or in stuff I never heard of as a newbie: what is kerberos or lib-gervddsdf_26.3.4 good for?), and additionally their questionable categories (in Debian, at least) makes synaptic not very beginner friendly.
Another point is that we don’t yet live in a networked world I believe — most windows users get their apps from journal CDs of from a friend. Now consider a Linux journal willing to pack some apps on a CD. In most cases, they can’t support more than two distribution or use tarballs, and then, the manual dependency tracking starts again.
Even when Windows users download a package via Modem, they can judge it from its screenshots. That’s something, a package manager isn’t capable of. And windows users simply install a package. When I find a nice looking new app, I first need to apt-cache search, eventually search apt-get.org or google for a backport, then eventually search for a source package in sid, then eventually download the tarball just to find out that its developers didn’t list all dependencies properly.
So, IMHO, Linux still needs a proper installer: one that is capable to interact with all the main package management systems, and that tells my package system it needs X dependencies installed. And my package management should be able to note that a tarball was installed under /usr/local by the installer, and that it lists the tarball as de-installable, and even deinstalls its dependencies if no other package needs them.
The packages don’t even need to deliver the installer – it may come with the distribution. A package needs only a proper “driver” file: “What? A fedora install of package ABC? Ok, I need dependencies X, Y, and Z filled, and then will use whatever in the binary package is, and put the files under /where/ever/ and finally drop a note to the fedoras package manager.” Wouldn’t that be fine?
Bulding packages for even the most used distros is hard. Maybe this will be easier in the future due to Build Buddy.
————-
Not really. Debian has a very nice set of tools for building packages. Certainly, its not appreciably harder than making Windows installers.
However, package managers are not yet a good solution. I *really* love apt-get for its dependency tracking but a the graphical front-ends are nearly useless althought that’s not the fault of their developers.
—————
They are not useless. KPackage, for example, is quite easy to use, and Kapture should be even better. And if they aren’t easy enough to use yet, that *is* the fault of their developers — all the infrastructure they need is in place. If the catagorization is too complicated, you could easily simplify it. Lindows and Xandros do just that.
Another point is that we don’t yet live in a networked world I believe — most windows users get their apps from journal CDs of from a friend.
————
I’d beg to differ about the networked bit — most near everyone has an internet connection these days. But either way, you can put a repository on a CD just as easily as you can put a repository on the internet. To make things even easier, you could auto-add the repository whenever the CD was inserted. The existing infrastructure would support that quite easily.
Even when Windows users download a package via Modem, they can judge it from its screenshots. That’s something, a package manager isn’t capable of.
——–
And why not? Click N Run does exactly what you’re talking about, screenshots and everything.
And windows users simply install a package. When I find a nice looking new app, I first need to apt-cache search, eventually search apt-get.org or google for a backport…
——–
Again, that’s a problem of package availability, not infrastructure. If the apps were in the repository in the first place, this wouldn’t be a problem. Again, tools like Build Buddy should make the correct packages much more widely available.
One thing that needs to be done is to make online repositories easier to add. You should be able to just click on a link to add a repository to your list. This is another way the repository model is better — once you’ve got a repository in your list, you never have to check that site again. So when the newest version of Amarok (think Winamp) comes out, you can update automatically.
You have not used Mandrake’s URPMI have you ? I am running a upto date cooker system with kernel 2.6.2, KDE 3.2.0 stable, XFree86 4.4.0 and other updates all installed via URPMI and Mandrake’s easy to use GUI control center.
Here are some screenies.
http://www.linux-central.net/snapshot1.png
http://www.linux-central.net/snapshot2.png
I think auto-packagers are the way to go so that it makes it easier for distro’s and progammer to package stuff for those who do not run the same distro or *nix versions ( i.e. BSD users ). The add/remove system of rpm’s works great IMHO, especially with URPMI. I can’t really say the same for APT-GET and Synaptic though.
Speaking of repositories, there is a problem with them as they are today. The model when a distro maker packages all the software simply does not scale. You can’t expect your distro maker to package all software, both OSS and commercial, that you would ever need. Therefore repositories must be distributed and decentralized (here’s where P2P technology comes to mind). But then you must ensure proper security, and this is not trivial, as far as I understand. AFAIK such a system is planned for Autopackage.
Secondly, I would support the point of view that package managers are useless, and here’s why. The overall process of getting software consists of two parts: search of software and the installation procedure itself. What today’s GUI package managers (Synaptic, KPackage, whatever) perform is basically the search. They don’t install packages — RPM, dpkg or something else do that instead. So how choosing a package in Synaptic is different from browsing Tucows.net from the user point of view?
Now you can say “Yes, but Windows installation is clickety-click, whereas in Linux I can do ‘apt-get install gaim’ and voila — it’s there in seconds!”. But some people forget that in many cases installation must or should be _interactive_. For instance, EULAs aren’t going to disappear in the foreseeable future. Another example when interactivity is needed is choosing installation place. You should not always decide for the user what to do, therefore the need for wizard-like installation procedures.
This is soon going to be remedied by Autopackage, though.
http://zero-install.sourceforge.net/
this is IMHO the best way to go, too bad it doesn’t get the support and attention it deserves.
We are just starting and appreciate the positive feedback!
We take note of the suggestions and in fact many of them we have plans for or are already under development :
– RPM support (and possibly DEB) will be there for next release
– Several people have already suggested Slackware TGZ support. Most business tend to use SuSE and Red Hat or other RPM-based distributions so that is our priority. We will try, when time permit, to get a Slackware machine up and running and port it. Slackware was my first Linux distribution ever (10 years ago!) so you can be sure it will eventually get done
– We come from an open source background ourselves, being active contributors to the Linux Documentation Project, Apache and Mono. We want to help Open Source software projects. If you are a contributor to an open source project and want to use BitRock to create an installer for your project, please contact us.
– About the price : our competition is the likes of InstallAnywhere and InstallShield Multiplatform which are priced around $3000 (ouch!) However, we are looking for ways to make it accessible to small companies who may not be able to pay the price. Pricing is always difficult, let us know your suggestions. If you are a small Linux shop please drop us email and we will try to figure out something.
– About the website screenshots not showing up in FireFox: We are looking in to that right now. One of the design goals of the website is that it works in as many browsers as possible. We have tried several versions of Mozilla, Konqueror, Explorer, Galeon and several designs to try to get it right, it seems it still needs a bit of work
My email is daniel @ bitrock . com
These guys know what they’re doing, and it shows. Their open source background shines through – this is certainly a useful addition to the Linux desktop toolset.
Obviously in some ways BitRock competes with my own project (autopackage). Let’s see how they currently compare:
* BitRock exists, and is stable. autopackage exists too but we don’t want people to use it until we’ve got the APIs stable – unlike in BitRock where you just add some files and they’re copied, autopackage exposes an API which you use to do the copying, so this stuff has to be stable.
* BitRock does not do dependency management. autopackage does. This is only really relevant for open source projects though…
* BitRock has a much higher overhead than autopackage does. An empty installer that doesn’t do anything is 1.7mb! Still, this is quite light compared to (oooh, let’s say) InstallShield. On the other hand, autopackage grabs stuff from the net the first time you use it. There is currently no option to include everything it needs inside it, though it’d be nice if there was.
* BitRock is simpler but more complete. For instance it allows you to view README files and so on, whereas we just haven’t implemented that feature yet.
* BitRock has a very nice GUI authoring environment, whereas autopackage is purely specfile based. We may have such a wizard program one day, but so far there are no plans for it.
Good luck guys! I hope one day autopackage will be useful for commercial/enterprise customers too, but it’s not a priority and I suspect the lack of a “sealed” and its dependencies on the various shell tools will give you guys a big head start over us there.
I’ve never fully understand why people care so much about these GUI installers on Linux. Sure, the package managers available out there could use some improvement, specially regarding creating menus and desktop shortcuts. Besides that, things like apt, portage and ports are perfectly fine IMHO.
Anyway… Loki released its GUI software installers/uninstallers years ago, which are GTK1 based under the GPL. Shouldn’t be so hard to take these projects and update them to use GTK2 and make them useful again. Even if it can’t handle software dependency, this Bitrock thing seems to be unable to do it, too.
For more information about these projects, go to http://freshmeat.net/search/?q=Loki§ion=projects.
Sometimes when some people only use only one operating system, they close their minds to others, If a system works
well, use it, most people are not going to care about the
operating system just that it works.Windows,linux, or
whatever. there are those who like the slackware/BSD way of doing things and those who dont. you can become a servant to your computer,It should be the other way around.
LoL – You are right ! I have used that installer for ages and guess what ! It works ! It even has a nice uninstall and update feature as well. The only thing missing is porting it over to GTK 2 and making sure it registers the application installation with the rpm database so that you can uninstall stuff via rpm, Kpackage, URPMI, apt-get, Synaptic, etc…
Like it or not, Linux is going to grow on the desktop as more and more consumers get tired of having someone reinstall their OS because it got inundated with spyware/malware. Try as we may, educating these people into the intracacies of installing applications is not going to fly until they have a one click gui installation.
Package managers are great, but the average user will be intimidated by them. OpenOffice and Sun Java are 2 good examples of the typical installation process the average user will require.
The difficult part for developers such as these is the number of distro’s and variant installations out there. It will require an RPM interface to perfom dependancy checks and make for various desktops. Otherwise it will be limited to precompiled binary installation only, which may not fly too well if the distributing developers have limited resources.
One thing that needs to be done is to make online repositories easier to add. You should be able to just click on a link to add a repository to your list.
I agree. But consider every project would provide a “driver” file for downloading (maybe in form of a install button) which is in fact a tar.gz’ed XML file, for example Amarok.mpd. The file lists all necessary information for all supported distributions, including possible repositories, build dependencies in case of a necessary tarball build, and so on.
When you configure your system correctly, your browser asks you to open the file with the “installer”. It can then read the file contents, start a small wizard, add a repository if one exists, updates the package list and tells apt-get|yum|URPMI|emerge|whatever to get the file and install it — or to get its build dependencies, then downloads the tarball, and builds it with a preconfigured prefix if the user prefers a most recent version instead of the one delivered with the distribution.
This would be a package manager independent click’n’run when the specs of the XML file would be a freedesktop standart — a metapackage system if you like.
I also think, sites like freshrpms.net would be a little bit more user-friendly when they would provide these tar.gz’ed XML “driver-files” instead of endless lists of search results.
This would help Linux journals to pack new software onto a CD. All they need to do, is to provide a webpage on the CD and to link the also included driver files. Thus, readers with non-supported distributions can also easily use new software without searching the web for several minutes (or wasting hours trying to build a package).
(To be honest, this isn’t my idea, I just read it somewhere but can’t remember where it was and I don’t find it again.)
Speaking of repositories, there is a problem with them as they are today. The model when a distro maker packages all the software simply does not scale.
———–
Sure it does. The distro maker doesn’t have to maintain all repositories. Many projects maintain their own APT repositories, for example. Its really not hard to do, and doesn’t take much more space than just hosting the binaries. And if you don’t have hosting space, there are *lots* of people willing to mirror things for you.
But then you must ensure proper security, and this is not trivial, as far as I understand.
———–
As long as the package repositories are on trusted websites, there isn’t a problem. RPMs (and Deb’s too, I think) can be signed, which means that as long as the project’s public key is not compromised, there is no danger.
The overall process of getting software consists of two parts: search of software and the installation procedure itself.
————
Only in the Windows world. In the Linux world, the overall process of getting software consists of one part: choosing which package you want. The installation procedure itself is handled automatically.
What today’s GUI package managers (Synaptic, KPackage, whatever) perform is basically the search. They don’t install packages — RPM, dpkg or something else do that instead.
———–
Synaptic isn’t the package manager. The package manager is APT or Yum. Synaptic and KPackage are just GUI shells for the package manager. APT and Yum package manager handles both doing the search and installing the software. In KPackage, its a matter of selecting the package you want, clicking “install” twice, and clicking “done.” The package is found, downloaded, and installed. No messing with the CLI or anything!
As for Tucows, I’d say that Synaptic makes it much more straightforward to find a package than Tucows (no selecting download mirror, etc) and after that, you’re done — no having to actually download the package and install manually.
But some people forget that in many cases installation must or should be _interactive_. For instance, EULAs aren’t going to disappear in the foreseeable future.
———–
Debconf, the configuration mechanism for APT, easily handles any interaction required. If interaction is required, it’ll pop up a KDE/GNOME/Curses dialog asking you for any input. This interface will not only handle things like EULAs, but can be used to configure the package you just installed. For example, when you install a server program, Debconf asks you whether you want to run it stand-alone or through inetd.
Another example when interactivity is needed is choosing installation place. You should not always decide for the user what to do, therefore the need for wizard-like installation procedures.
————-
In the UNIX model, the *system* decides where things go. Its left out of the hands of the user, because frankly, they don’t really need to know what goes on under the hood of the machine.
It would be nice if there was a GUI installer that a lot of developers used. But this isn’t the solution. It’s not GPL so it introduces *yet* another piece of software for a supposedly “open” platform that we just *sigh* and use because it’s the best solution we have. NVIDIA’s drivers are another example.
Thanks to whoever for mentioning InstallBase, that looks like it has a lot of potential. Also the installer that Id uses for Return to Castle Wolfenstein and Enemy Territory, Epic uses for UT2003 and the US Army uses for Army: Operations, is a decent installer, I don’t know if it costs money to use, but it gets the job done.
I don’t mind compiling software from source, but sometimes, I can’t wait 40 minutes for WINE to build itself, and RPM is not a workable option in my opinion.
Fimally
Finally