MadPenguin reviews and details the new XFce visual installer.
XFce Installer Something To Be Proud Of
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
WOW! That’s great! An installer that compiles from sources!!! That’s really impressive.
GOOD WORK XFce!!!
The installer is really something nice. It’s very well done and I think sets the bar high for other projects.
It’s not that ./configure && make && sudo make install is such a terribly hard thing to do, but with XFce including so many small packages that have to be compiled separately and in specific order, this sure makes it a lot easier.
It works across multiple platforms too. Very cool.
This is really a great installer .
Take notice kde , gnome , …….
Sorry, but I don’t get. Why don’t rely on traditional package managers such as Portage or apt when they get the job done nicely?
Well, you could of course. But not every app is packaged for every conceivable distro. Plus, if you want to bleed on the edge, it’s nice to be able to install the latest version with an easy to use installer.
But the system doesn’t know about it. This is especially bad for libraries, which are listed as a dep for manu packages. If let’s say QT had such an installer and one would apt-get or pacman kdebase later on, QT will probably be either overwritten or installed next to another version of QT. This will unevitably lead to conflicts.
It would be nice if such an installer could detect the package manager an install a fake package or something like that.
So what happens if you don’t have all the required libraries installed? Or if you don’t have gcc (e.g. a default Ubuntu installation, IIRC)? Also, being a stand-alone installer means that everytime you download an application that uses this installer, you’ll also be downloading the installer. This might not be a biggie if the installer is small enough, but it’s still annoying.
The only thing that’s currently missing in most distros (IMHO) is being able to install software by simply clicking on a URL. Right now, if you want to install a third party package in e.g. Debian, you have to first add the repository to your list, and then update/install. While this isn’t so hard if you use Synaptic, it would be nice if you could just click a link, which brings up an installer that offers you to optionally add the repository and then install the package and any dependencies.
If such graphical installers were to become prevelant people may focus on using them instead of the package managers that come with their distros.
Those that benefit most from a graphical installer are people who don’t know enough to install packages by hand. When they start installing various software on their own they are likely to start having library issues and in the end create more of a mess.
For apps like kde and gnome, they have too many libraries that various programs depend on, and it would be better for the package manager to install them.
Personally, I don’t understand the obsession with package managers. Sure, would be cool if there was one that worked for all distros, but seems people are hellbent on each distro having its own package managers, so that you have 20 individual distros all duplicating each other’s efforts.
I dunno, I plan to reinstall XFCE4.2 via Portage when I get back to the university, but for now I just stuck it in /opt/xfce where it doesn’t touch anything. For now, it was easier to download that graphical installer of RC3 with everything than to try to download all the pieces (of RC2) portage needed, and make that work.
The only problem I had was the inability to install the goodies package unless I was RUNNING XFCE4.2. Though then each of the goodies showed up the ‘add item’ bar as it finished compiling, which was impressive.
I have to say, it looks a lot nicer than an xterm with portage.
Talk to Gradma and you will understand the “obsession” with package managers, graphical installers etc.
QUOTED” There’s no doubt about that. Even though most of us prefer to build our software the old fashioned way”
Forgive my ignorance but is there anywhere anybody can point me which descibes these processes in more detail. I feel I’m missing something..
I agree with Luk van den Borne. This is not that great at all. We don’t want the Windows way of each application having a individual installer that doesn’t care about other package systems, which leads to DLL hell.
Even if it’s not perfect, it’s way better to even have a different package manager for each distro. At least you will not get conflicts in your system. The GUI tools for package managers will eventually get better.
The traditional way consists of reading the documentation included with the source package (the files README and INSTALL) and following the provided instructions.
For most programs this would be:
$ ./configure && make
$ sudo make install
An installer that compiles from source? Am I the only one who thinks that’s a bizarre idea? You end up with pretty much the same binaries (“extensive optimizations” make hardly any difference here …) but it’s much slower.
The right way to do this is provide Linux binaries (with or without an installer) on their website.
the is only possible because the many small modules that xfce provide all compile cleanly and consistently. i tried it a few times over the last many months. this is unlike almost all other source code compiles i have had to do where it was never as simple as ./configure; make; make install.
Good package managment is good managment on both sides. That’s partially why Debian works so well. Maybe we need tools to address that fact.
I don’t get why people who say graphical installers are the devil would actually be using a graphical desktop in the first place.
Can someone explain the reasoning behind that?
I think the FreeBSD ports/package system is the perfect solution… you can install binary packages, and source packages, and they all work together perfectly. Maybe there should be a Linux distro that duplicates this, rather than just ones that have a binary package manager, or are source-based.
The right way to do this is provide Linux binaries (with or without an installer) on their website.
But the installer works on BSD as well. It becomes a slippery slope of binary packages on the site after a while, the more targets you support.
There is one. The distro’s Gentoo and the package manager is portage. It was even based on ports itself.
Quote from article:
it appears to be a frontend to the common configure, make, make install method of installing packages we are all too familiar with, with the option of passing configure flags along the way.
I see that some of you didn’t read this. If “configure, make, make install” can preserve/update library dependencies correctly, why should frontend break that?
About BSD – does this installer run on FreeBSD? Although I’m satisfied with BSD way – one “make install” or “portupgrade” and all done correctly, I’ve nothing against using nice graphical installer.
Somehow me feels that some of linux people are very scared about linux getting too easy and eye-candy:) This is not windows way, btw – this is just natural way.
@Space-Cadet
In FreeBSD you cannot always use packages and source interchangeably. I just lately broke my FreeBSD – I decided to not waste time with compiling and installed latest xorg from latest (6-CURRENT) packages. Because I’ve 5-STABLE system, X didn’t run after. Of course this was my error (and hard way to learn things:).
Somehow me feels that some of linux people are very scared about linux getting too easy and eye-candy:) This is not windows way, btw – this is just natural way.
—-
the setup wizard isnt anyway natural with all those compile time options and stuff in there. wizards are not used by many OS either
Couldn’t it use checkinstall instead of make install, so that it would make a binary package for the distro in question, and then install that? I was under the impression that Checkinstall supported building/installing rpms and debs, besides just tgzs.
Or is checkinstall too much of a Slackware phenomenon for it to be picked up by something aiming for universal support?
… or does this reviewer have a really screwy system?
First, he says “As a matter of fact, shadowing and transparency on an AMD Athlon XP 2400+ with 1GB of PC3200 (DDR400) RAM renders the machine almost useless.” Now I know people’s perception of what constitutes acceptable performance varies, but on my Mobile Athlon 1400+ with 256 MB RAM, it’s at best a bit slow.
Then he says it takes him 45 minutes on that system to compile XFCE the old fashioned way.
Which is twice as long as it takes me … on a system with less than half as much performance.
Weird …
A great step backwards, to be more specific. We have package management, now let’s go back to individual installers that cannot handle dependencies and take the possibility to perform auto-updates away from you. Because of stupid rumours about a “dependency hell” (which is only existant on certain RPM-based systems) we move on to installer hell.
Just because your average Windows user isn’t familiar with package management, that doesn’t mean that package management is inferior or more complicated or less user-friendly.
In fact all my friends that i converted to Linux found it very practical and easy after having growed accustomed to it.
I have to admit that both the XCFE and Firefox installers are well-made and structured, but they would be better off creating packages for the various distributions.
I think modern package managers need to be able to read some sort of universal package datafile. so that anyone writing a stand alone installer can have that program and all installed packages listed so that the package manager can read and understand what was installed. this datafile could be something universal and have nothing to do with the package managers, they would just need to read the file. /etc/universalpackagedata , portage then reads this file when run to see what was installed. or mandrakes drake-thinggy can read it.
i think the many linux clans need to get together and start standardizing install processes. their is no reason why an installer cannot read a $PATH for installing programs.
USERPROGRAMS=/usr/share
CONFIGPATH=/etc
INITPATH=/etc/init.d/
DATABASEPATH=/etc/universalpackagedatafile
so on and so forth. then the package installer can intelegently write or link files to the appropriate directories for ANY distro.
i, for one, am sick and tired of 100 different package formats. even worse is 3+ different kinds of rpms.
This is a schizophrenic attitude. On one hand people like you constantly speak about Freedom, in reality they would like to control every piece of software and/or driver. It is totally unrealistic to believe every program could be packaged for every existing distribution. Modern computer platform must provide enough flexibility to allow independent software developers to serve their customer niche. It’s the reason Windows dominate today. May be Linux is technically superior, but for several reasons fails to provide this service yet. XFCe installer is certainly a move in the right direction.
I for one am waiting the day that gentoo and debian merge their projects together and make a package manager that is as simple as Portage and with official binaries like debian. Then if you need XFCE 4.2 and they only have 4.1 in portge/dpkg you take the ebuild and modify it to work with 4.2 sources and build packages easily. This could be automated and guified to be at disposal of any power user.
what is wrong with a directory/application?
where firefox is in /opt/firefox, and has no other programs required to run firefox outside of this except core libraries. for instance, QT would not be in the /opt/firefox/QT. and firefox’s config file would be in /opt/firefox/etc/firefoxconfig, then that could be linked to /etc/ for consistancy and easy of system configuration.
install xfce4?
/apps/de/xfce4
ln -s /apps/de/xfce4/etc/xfce4_config /$CONFIGPATH/
ln -s /apps/de/xfce4/xdm/xfce4.desktop /$CONFIGPATH/xdm/ (whatever)
ln -s /apps/de/xfce4/xfce4-package-data /$CONFIGPATH/packages/
ln -s /apps/de/xfce4/init.d/xfce4-init $INITPATH/(yeah i know it’s isn’t needed, just and example)
done! all xfce4 stuff is in /apps/de/xfce4
to uninstall,
sudo rm -rf /apps/de/xfce4
and each system should have a script to search and destroy broken symlinks.
sudo /bin/symlink-correct
so, xfce4 is installed, configuration file in place, xdm/gdm/kdm files in place, and a package description file is in place in a package directory, this file contains all of xfce4’s dependancies and version data so that a system profile manager or package system can read and determin what system libraries need ot be installed. of course the install script would be more detailed with some if/then cercumstances and dependancy checking. all packages should basically be set up to do such a thing and output it’s deps to a file so a library package manager can be aware. other apps would only check for the xfce4 config file if they had an ability to integrate.
so i think we have everything we need for a solid package system complete with centralized configuration, init script placement for many distros, though some would require and alternative init file, that could be provided with the package and determined by if/thens.
thoughts??
I can. Even though I use app’s on XFCE & X, i still want to be able to install software whether or not I happen to be sitting in front of the target machine. As an example, it’s not possible to do a system-wide install of openoffice remotely (without allowing remote root GUI login, something I’m not willing to do)
Seems someone else other than the XFCE regulars did the gui installer. Hopefully that means we will be left with a choice between the “old fashioned” way and the GUI
Personally, I don’t understand the obsession with package managers. Sure, would be cool if there was one that worked for all distros, but seems people are hellbent on each distro having its own package managers, so that you have 20 individual distros all duplicating each other’s efforts>
There is one, it is called Autopackage. I wonder why not many people are utilizing this wonderful packaging tool.
http://www.autopackage.org/
@DonQ
I see that some of you didn’t read this. If “configure, make, make install” can preserve/update library dependencies correctly, why should frontend break that?
Autoconf’s “configure” doesn’t fetch or install dependancies. It complains if dependencies are missing, but you have to install them manually.
@Receding Hairlines
The problem isn’t the fact that it’s GUI based. There are already GUI based package installers, such as Synaptic, YUMGUI , Yast and others. The problem is that this installer doesn’t integrate with the distros’ package management system and doesn’t automatically handle dependencies.
@dano
And how is that easier than apt-get/yum (or suitable GUI frontend)? How do you define “core libraries”?
I’m a firm believer in package managers. When used properly package managers (other than those RPM-based systems) make software management easy. I love you portage
I think have individual installers is a step in the wrong direction. I think installing software by simply extracting an archive containing the software into its own directory makes this easy… TOO easy! Just like being able to click on a link to install software, by making installation too easy, you’ll end up with a messy system. Software will end up getting installed in awkward locations. It would also make it easier to accidently install malicious software because there would be no “repository” of approved software. I figured if you want to install something not available in your package managers, run ./configure –prefix=$HOME/Apps or something like that. Then, if the program works well, go ahead and MAKE a package for it so others can enjoy it.
I do agree with a previous post about having some kind of file all package managers can read. I’m not saying package managers should merge. If you like RPM, use it, DEP, use it, etc… But it would be nice if package managers came with a tool that can read a special file. One the software developers can create, listing basic info like app name, and dependancies. This tool can then, at least partially, create a package for your package manager.
By mtts
… or does this reviewer have a really screwy system?
First, he says “As a matter of fact, shadowing and transparency on an AMD Athlon XP 2400+ with 1GB of PC3200 (DDR400) RAM renders the machine almost useless.” Now I know people’s perception of what constitutes acceptable performance varies, but on my Mobile Athlon 1400+ with 256 MB RAM, it’s at best a bit slow.
For some, that’s enough to be totally worthless.
Then he says it takes him 45 minutes on that system to compile XFCE the old fashioned way.
No, it says with the installer it takes 45 minutes.
“The right way to do this is provide Linux binaries (with or without an installer) on their website.”
C’mon Mike, I don’t think you should be too humble here 🙂 It’s called Autopackage, don’t be afraid to name it — I think you can be proud of your creation 🙂
By the way, XFCE is an excellent candidate for autopackaging since it’s all C. Why hasn’t anybody done it already?
As for the installers compiling from source, I wouldn’t rely on this as the primary method of installing third party software, but when there’s no other choice — why not?
packages aren’t different between distributions because of package managers. Red Hat, SuSE and Mandrake all use RPM packages – do they all use the same packages?
BTW, where does this installer install to? If it’s /usr , that’s *baaaad*. If it’s /usr/local , great….
thats because autopackage is still in its infancy. they just released their first api stable release a couple of days ago. it still has many bugs to be sorted out. read the autopackage devel list or ask mike for details
The only thing that’s currently missing in most distros (IMHO) is being able to install software by simply clicking on a URL. Right now, if you want to install a third party package in e.g. Debian, you have to first add the repository to your list, and then update/install. While this isn’t so hard if you use Synaptic, it would be nice if you could just click a link, which brings up an installer that offers you to optionally add the repository and then install the package and any dependencies.
>
>
Get real. The last thing anyone should want is to be able to install software by simply clicking on a URL.
Hasn’t the amount of spyware and other crap downloaded through IE taught Windows-using idiots like you the dangers of installing *ANYTHING* from the Internet via a single click on a URL.
Hopefully a KDE version comes, this is great news.
Rox is heading towards this, where you can create an application with it’s “components” inside a folder. Rox loans this idea from RiscOS of course, which was a British product from the 90’s designed by Acorn.
For those who’ve not seen this, applications were really just folders (or directories to use the correct Acorn term ;-), but with a name starting with a !, so !draw was the system drawing program, !paint, !edit etc etc.
Double-clicking caused the application to run, shift-clicking opened the folder/directory, inside which you’d find all of the scripts, modules and icons for that app. Part of the run script took care of ensuring the correct modules were loaded at runtime.
The Mac also does something similar, certainly with OSX, but they now have extended attributes so there’s no need for the old ! which I rather liked, oh well 😉
I love xfce btw, and have used the installed both on Ubuntu for a friend, and my own Gentoo install, where I too got pissy with portage and compiled using the installer instead…hehe!
The xfce4 installer from os-cillation takes 15 minutes on my Gentoo machine, p4 2.6GHz 512MB …make sure you have “ccache” installed to speed things up a little 😉
As for the transparency slowing things down, make sure you have the right options set in your xfree/X11 config. When I first compiled xfce4 my GForce card was missing an option and it took almost half a second to refresh!
Fixed the options, now it’s faster than XP! 😉
The most important (and obvious) one to check first is Option “RenderAccel” “true” for Nvidia cards. You can find more flags in the various wikis and forums, good luck! 🙂
I don’t know if anyone who could change something will notice if I write this down here, but who cares anyways…
Some ideas I have for an installer:
-Online Installer, download about 100kb as executable and get the rest via the installer (at best a bit torrent client would be integrated…)
-This is especially usefull if the installer would support multiple package formats:
I noticed that it is almost impossible to install say vlc on ubuntu, just because it isn’t listed in the deb archives and the ones from vlc don’t seem to work. (This same problem would go for many distros not having the newest software in the archives) So the installer would know what files ubuntu would need and would install them. Because the installer is downloading only what it needs, suse rpms, red hat rpms or whatever wouldn’t bloat the download size at all. If the installer can’t find a matching package for the distro it would fall back to install from source.
If it would be done this way there would be no problem with the native packaging system and the installation would be way easier than to let the user find which archives or files they need.
The only thing that’s currently missing in most distros (IMHO) is being able to install software by simply clicking on a URL.
It is possible to do that on Fedora Core 3. However, it uses rpm manager. Downloading sofware via url using apt or yum will bring some issues about some packages needed to include if not available to solve dependency.
I am not sure if it is apply to other distros.
A great step backwards, to be more specific. We have package management, now let’s go back to individual installers that cannot handle dependencies and take the possibility to perform auto-updates away from you.
Auto-updates do become less practical, however I liked the way the installer handled dependencies – first it checks if the dependency is met, but if it isn’t it provides you with a way to indicate where the library is installed.
I have to admit that both the XCFE and Firefox installers are well-made and structured, but they would be better off creating packages for the various distributions.
Well, there are. Most package-based distros have XFCE and Firefox packages in repositories. However, a source-based graphical installer is interesting for developers as it doesn’t require maintaining packages. In any case it’s the distro maker’s (and enthusiast users) to provide packages, so this is only another proof than there are always more than one way to do something in Linux. And that’s good! 🙂
This is a schizophrenic attitude. On one hand people like you constantly speak about Freedom, in reality they would like to control every piece of software and/or driver.
Whoa. People like you. What do you mean by that, exactly? I smell a sneak attack on the GPL!!
I support collective freedom and free software, I also support proprietary software and the freedom to make a buck (as long as no one’s getting a bad deal). I happen to think that package managers are a great idea, and make software management easy and powerful. I also happen to think that graphical, whether they are source-based (like the XFCE installer, which I think is based on Arkollon), binary-based (OpenOffice, Codeweavers) or just something else (autopackage), are really cool.
Chill, guys. To each his own, depending on the task at hand or the personal preferences of each!
I don’t agree either. Third party packages are a pain, because they pollute the system. The xfce devs write xfce. They don’t know how Mandrake or Fedora or SuSE like to have things packaged, necessarily. I’d much rather have projects distribute source code or a neat installer like this – *SO LONG AS IT INSTALLS IN /USR/LOCAL AND DOESN’T POLLUTE /USR*. IMHO, packages should be the distro’s sole preserve. Mandrake already has XFce packaged; if I want to install XFce I should *either* install Mandrake’s packages, which fit in with the rest of the packaged Mandrake system and will be properly updated by MandrakeUpdate or the installer between releases, *or* I should build manually (or use a neat compiling-installer like this) and install the result in /usr/local , where it is completely separated from distro-packaged stuff and doesn’t pollute the RPM database.
Why not just slap a GUI on most package managers, wait thats already been done (synaptic/porthole/gentoo-macosx iPortage).
is a deceptively simple and brilliant alternative to “packagers” and “installers” and offers a world without upgrade anxiety.
Check it out
http://0install.net/index.html
The only way to solve the problem of being able to make one binary and run it on all linux distros is if all distros agree to one package format and all associated mechanism that go with the distro to make this happen. Is this in the works yet?
“emerge xfce4” workd perfectly for me… why graphical?
grandma isnt installing software on any system, her kid is, or the neighborhood computer kid is.
grandma barely uses email, so i dont think we need to dumb everything down to the level to which she still wont be using it.
C’mon people, look out of the window, there’s more than your particular Linux distro and there’s more than Linux. It wouldn’t be very useful to provide binary packages or to use AutoPackage. Why exclude Unix users or users of other (unsupported) Linux distributions?