Loki releases an installer 79
Loki Entertainment has just released their Installer program under the LGPL license. This installer uses an XML description file to describe a package, and provides both a console and a GTk front-end to install it. I think this installer is excellent for newbies. What do you think?
The Installer (Score:1)
How does it handle the different distributions? (Score:1)
different distributions and windomanager/desktop environment menus?
There is also a project zenguin [zenguin.com] that is supposed to handle the same probs. But their page
doen't seem to be updated frequently. Any info
about their progress?
Re:The Installer (Score:1)
However, Cleansweep was very very good. It actually could monitor an application as it installed (registry settings and all) and COMPLETELY remove everything - not only that - it continues to monitor the application whenever it's run and monitor everything it does (new files/registry entries etc).
It was extremely cool, and even uninstalled shareware applications that left behind "time out messages" *somewhere* perfectly (meaning I could reinstall them again
Pity the company that made it died or got bought up by symantec i thik (Quarterdeck i think the company was)
dependancy (Score:1)
But I still dont know whether this is in the best interest of new Linux users. I thought most of the point of Linux was learning how to set up everything so you dont have to rely on the OS to try to figure it out for you. It may be useful for when you're lazy or new, but the concept of automation might spread to other areas and be abused. I hope that the newbies who do start to run Linux with the aid of the program dont become fully dependant on auto-install features. After all these automated install routines should be considered only as training wheels and disposed of after the necessary experience is gained. Otherwise, why switch in the first place?
Re:Examples of use? (Score:1)
Re:How does it handle the different distributions? (Score:1)
I would hope they would stick to the tarball format. Then they will have a cool installer for other unix flavors as well.
As far as differing file trees go, you could have detection built in much like the Make programs do for Unix detection.
Re:dependancy (Score:1)
I would say that if Linux is going to really make it as a mainstream O/S then it is going to have to be "dumbed down" to allow basic users to do simple stuff.
If breaking into the mainstream is not a directing Linux is going then what is with the Corel distribution and office suites? I think that many people would like to see Linux as a viable "dumb user" desktop alternative.
Things like simple installers, drag & drop file managers, etc are what is going to make it happen. Having spent a few years in support, I feel that what people (read "dumb users") want from their O/S is pretty animations, screen savers, and sound. What they *need* are simple and consistent interfaces to do basic tasks.
I applaud Loki's contribution here as I think installers are one of those essential things that you shouldn't notice: but you know a bad one when you see it...
This is about the last thing I want to have... (Score:1)
Why for the gods sake would I need an installer on pacage-based system? Does it produce an ".rpm" (or ".deb" , in case the system is debian-based) package on the fly?
If it doesn't, I do not see what is it good for. I certainly do not want to get the same situation as in Windows - A program gets installed, breaks some dependencies and you may re-install the system to get it fixed.
Re:The Installer (Score:2)
http://www.gnu.org/software/stow/
Does it detect and support package managers (Score:3)
If it doesn't, that is something that should be added IMHO. And to make the installer lightweight, each distribution could come with a loadable module that the installer could load to talk to the package management system.
I think it's good thing (Score:1)
How good this loki entertainment's installer is for huge and complicated applications (like server software, etc..) is the different story, but I think it performs pretty well on simplier software.
Re:This is about the last thing I want to have... (Score:1)
Well, if you read the README at
http://www.lokigames.com/development/download/s
you will see that the installer is for those products that don't come in
Ack! No! (Score:3)
WE ALREADY HAVE INSTALLERS which are best suited to the distributions on which they run!
You want this to make it easier for the newbie? Why ask the newbie to learn yet another installer when he already knows one for his distribution?
Re:This is about the last thing I want to have... (Score:2)
Should I be happy because a crappy way of installing the program gets easier to do?
No thx. Commercial products should be made as packages and thats it. They should check the dependencies and put entries into the install-database, so that I can spot them, check the integrity and uninstall them later.
If supporting several different package-systems troubles the commercial vendors, they can always think of something to make package "on-the-fly":
1) Check the system, decide on type of the package
2) make a binary-only package with pre-install, post-install and post-uninstal scripts.
3) install using the native package-manager.
If they want a colorfull interface, it is OK with me, but installing stuff on its own is completely irresponsible - this is a job for the "RPM"-, or "DEB"- package manager. Magic words are:
DEPENDENCIES, and UNINSTALL!
Re:RPM for idiots (Score:1)
Sounds great.
step backwards (Score:1)
The good news is, when I want a new application on my machine, it is as simple as typing "apt-get install xbill" and that's it. I'll never go back to the nightmare of proprietary software, which (in theory) requires reading a pages of legal jargon just and clicking ok about five times just to set up a single program. Linux has the rest of the computer universe beat hands down in software distribution and maintenance infrastructure, mainly helped by the fact that we don't have to deal with eight zillion intellectual property barriers before making a system that works well. Let's not throw it our biggest advantage!
By the way, software collections like debian are almost perfect -- if the applications could just be easily run off a distributed file system like Coda for those of us on LAN's, we'd really have it made.
Re:This is about the last thing I want to have... (Score:2)
Important software (Score:3)
Sure, there's rpms, debs, glint, apt, kpackage, etc. However, none of them are as easy as they could be. Look at the mac and windows: click-click. They don't require the user to know what the packaging format is, or what programs are used to install them.
We need fire and forget installs. Execute the package, and start the program. It doesn't matter what format it uses, rpm's deb's slp's or tgz's. Does it want to compile on its own? No problem, pop up a dialog with a progress bar.
I think Loki could well have a winner. An installer targeted towards the game-player crowd could well be what we need.
I'd love to hear more about it, perhaps see some screenshots.
Hhm.. what I do like, though... (Score:1)
On the other hand.. just using this installer for the windows version and using rpms or whatever for the linux one might not be such a bad idea
Tal.
Re:Ack! No! (Score:1)
Re:This is about the last thing I want to have... (Score:1)
How many people actually want to go through and make multiple packages? Two, maybe.. but 4+? I think not.
Re:Ack! No! (Score:1)
I just wonder why everything should be so complicated, if it can be implemented somehow easier? If you want to, you still can install whole linux by using the compiler, make and the source code.
Re:Ack! No! - Rather, Yes! (Score:3)
Er.. Yes we do. Tried to install xyz deb on Redhat? vice versa? alien is not a panacea. How about either on Slackware? Redhat RPMS on SuSE -
I have had ones that failed, even with compat installed. tar.gz is the only distribution neutral system - and for what do you need package management when commercial software is supposed to install into
Its also a hassle to package for each obscure little variant of Linux with different packagmanagement, libc's, et al, and then try and do installation support.
/*You want this to make it easier for the newbie? Why ask the newbie to learn yet another installer when he already knows one for his distribution?*/
What newbie ever learned to use their package manager at levels lower than point and click? They don't have to use anything else for this installer either.
George Russell
News are always good... sometimes (Score:1)
Re:Ack! No! (Score:1)
Re:step backwards (Score:1)
So what do I type to install, say, StarOffice? WordPerfect? RailRoad Tycoon or Call to Power? Lets try Quake 3? One of the new DBMS systems like SyBase? Realaudio? apt isn't looking so hot is it?
apt and the Loki installer are aimed at different software types. apt is system maintence for Debian. Lokis installer is an installer for software supplied on a physical medium (ie a CD) licensed to be installed on one machine. That it is open source means it can be made to work well, unlike other similar purpose installers, seen on Windows.
hth
George Russell
Re:Ack! No! - Rather, Yes!... I'm not convinced (Score:1)
Let me rephrase my post. The point of a distribution is to package and distribute. Debian does an excellent job of providing Debian compatible installers for lots of commercial apps. (Netscape, Real Audio, etc.) By going through Debian, I know that these installers aren't going to fsck up my system because my system wasn't configured the way the vendor was expecting. I know it's not going to overwrite any files that might be under another package system control, and I know I'm going to be able to automatically get updates with "apt-get update" without needing to track down ten million different sites all over the net and see if a new version has been released or not.
tar.gz is the only distribution neutral system - and for what do you need package management when commercial software is supposed to install into
For dependency checking and for easy updating.
Its also a hassle to package for each obscure little variant of Linux with different packagmanagement, libc's, et al, and then try and do installation support.
Of course, it's a hassle for the vendor, but not for the distributor. That's the distributor's job! Let Debian make debs and RH the rpms, etc. etc.
What newbie ever learned to use their package manager at levels lower than point and click?
apt-get update
apt-get install package
apt-get dist-upgrade
That's it. That's all you need to know for basic Debian package management. How is that hard for a newbie?
Why use packages? (Score:1)
Re:RPM for idiots (Score:1)
*wink*
Re:Ack! No! (Score:1)
Yes.
At least you can't have both packages on one CD.
Yes, you could.
This is currently how Debian distributes stuff it can't distribute. (sort of) Like Real Audio, for example.
Re:Hhm.. what I do like, though... (Score:1)
http://www.jordanr.dhs.org/isinfo.htm [dhs.org]
The link above lists some of the nice features.
Re:Ack! No! - Rather, Yes!... I'm not convinced (Score:3)
1) Debian will never, and cannot, give Debian friendly installers to all commerical Linux software products. Even now, when they are comparitively rare.
1b) Every installer I have seen allows you to choose a destination path. Put it in opt, install as not root if you want to be *SURE* your system will not be gratuitously messed with.
1c) apt get upgrade requires Debian packages to be made. See 1a
2a)Dependency checking and easy updating go out the Window when I must strip a deb to tar.gz , and don't convert well when making deb
2b) Dependency checks suck on different systems using the same package management system - see the three way problem of using non native RPM's on SuSE, Caldera && Redhat + others.
2c) 2b will happen to Debian when its derivatives become popular and differ, even in trivial ways.
3a) Making hassles for vendors makes vendors Distribution specific or limited for support reasons (and also library problems)
3b) I don't like Software for Linux version 5.2, do you?
4) What newbie is going to be upgrading an entire distro - its much more likely that they want to install a single package, with a click, install. They probably do not know of dpkg -i or equivalent, and would not be too happy with it if they did. Newbies also do not know what they want or need to install / upgrade, so are unlikely to do so one package at a time, or all at once (over a typical net connection
4b) You expect newbies to use the shell?
George Russell
The right way to do the wrong thing (Score:4)
On the other hand...
I have a great aversion to installing random cruft on my system. I have an even greater aversion to letting a random program install random cruft on my system. Is there a separate file to run to uninstall each program? (looks like it, in fact you have to build a custom program for each app that needs to be uninstalled) So to delete stuff installed with this program I have to hunt down the uninstaller. Probably better to just install in
Loki would be doing a much greater service to themselves and the world by having the installer auto-generate packages from the generic package description. InstallShield-type stuff, where each program in the world ships with its own special installer, is an ugly and inelegant hack. The most redeeming quality this installer could have would be if it took command-line options to specify all the attributes of the install (eg, bindir=, datadir=, etc) and skip the interactive stuff -- this would allow halfway-useful packages to be made fairly easily. Ah well..
Daniel
Re:Why use packages? (Score:1)
However, package managers exist for a reason. (or reasons).
What I like:
- Version control/tracking
- dependancy info [although I've found it often doesn't work, probably because half of my progs are not RPM installed]
- Easier on a newbie
What I dislike:- Harder to "see" what's happening
- If it doesn't work you are out of luck. (Shades of Windows....)
- Can't set compile options.
- binaries (usually), so platform dependent
So it seems to me what we really need is a pretty graphical wrapper forAfter all, in my mind the power of linux is that it doesn't remove control from the user. As everyone works to not frighten said user with this power, we should make sure we don't interfere with that primary point.
Not too hard (Score:1)
dpkg, rpm etc.
Debian packages are easy to build automatically, you simply put your data file in a tar.gz and a few control files in control.tar.gz and combine the two into an ar archive. (And tweak the archive for some bizzare reason)
To build an RPM I think you have to use rpm, by passing it a
I have a self extracting archive format that spawns a control script that converts in into the appropriate package format then attempts to install itself. Grab it here [b0rk.co.uk]. I only wrote it out of idle curiousity, but I think the principles involved could probably be wrapped into Loki's installer.
Re:A good thing. Or perhaps not? (Score:1)
Sigh.
Re:Important software (Score:1)
And they don't work, either. They write a load of shit outside their own private directory and often to the system directory, some of which may be incompatible with old versions, sometimes even without checking version numbers. Microsoft's installers are particularly bad at this. Witness how service packs have to be re-applied after installing new components/extensions of an application.
Re:HELP! I need a GUI installer for the installer (Score:1)
Go to http://www.gnome.org and follow the Ftp link.
Re:step backwards (Score:1)
apt-get install staroffice3 downloads a wrapper script that uses the standard staroffice commercial package and installs it in a debian compliant way. This is done with the Quake* products too.
I think that the Loki installer has to integrate into the sytem or it will freak out the distro quite annoyingly.
Re:Ack! No! (Score:1)
Re:How does it handle the different distributions? (Score:1)
Installers? I hates 'em. (Score:2)
Back in the good old days, on good old RISC OS, we didn't need installers. To install a good old program, one copied its good old 'application directory' (that's enough goodness and oldness. -Ed.) from a CD, floppy or the 'net onto wherever you wanted it to be on the hard disc. To move it, you moved the application directory. To run it, you double-clicked on it. To remove it, you just deleted it. It didn't hide stuff in lib or man. It didn't scatter keys about the registry with reckless abandon. No shortcuts copied into a start menu, no changes to user paths, it just worked.(*)
I would really, really love to see a decent form of application encapsulation on Unix OSes and, even more, on Windows, where a half-installed application more often than not requires a complete OS re-install. Which is a bit crap. In case you didn't notice.
* - well, it just worked, until some of the bigger software companies decided to start using installers, usually in order to implement some hideous copy-protection scheme, or because installers were the trendy way Windows did it, or sometimes just to be contrary. After that, one tended to find that moving programs didn't work, upgrading the OS didn't work, installing them on newer versions of the OS or hardware didn't work, and applications would occasionally just refuse to run, claiming they were corrupt. Just like good old Windows. (That was a sarcastic "good old", BTW, so it doesn't count.)
An installer is just one more part of an application that can go wrong. I wish we could rid the universe of 'em.
--
This comment was brought to you by And Clover.
No more installers! (Score:1)
Linux would onbiously make the perfect choice for booting on the CD-ROM. A small kernel which autodetects the graphics, CD-ROM and sound hardware could be provided (as in Corel Linux) and that would be all.
Anyone else think it's a good idea?
Re:Ack! No! (Score:1)
and now they have GPLed it.
This behvior is one that we _ought_ to be applauding, as they are at this point GPLing anything they can, legally... (the actual source of the games is owned by the various game studios, so Loki is stuck)
moreover this sets a precedence outside of Redhat et al, that GPLing is cool and ok for commercial ISVs, who need to keep SOME code proprietary (yes, I know, it would be nice if Adobe made all of its products GPLed, but that is not exactly likely...)
The last reason this is good is that it is more code... when redhat and the debian committee-in-charge sit down to create the spec for the
We are all in the gutter, but some of us are looking at the stars --Oscar Wilde
Re:Examples of use? (Score:1)
Stéphane Peter
Re:The Installer (Score:2)
Stéphane Peter
Re:Does it detect and support package managers (Score:1)
I yet have to find a good way to arbitrarily add new entries in the RPM databases for files installed manually. Dunno about Debian though.
Stéphane Peter
Re:How does it handle the different distributions? (Score:1)
It currently supports tar and cpio archives, gzipped or not.
This is good for us since RPMs and the like are not always the best solution for games (when sometimes some data files have to stay on the game CD, etc).
However we welcome any contribution, if somebody wants to hack in
Stéphane Peter
Re:Ack! No! (Score:3)
We can't limit ourselves to any package format, since we need to support all Linux installations. So whatever archives types we support we have to make sure that they can be installed on whatever Linux distro the installer can be run on.
Stéphane Peter
not everything is an app (Score:1)
Shared things, by definition, have to be discoverable by other software on the system...
Re:Does it detect and support package managers (Score:1)
Well, as a first step, you could use the --justdb option to rpm, which updates the rpm database without installing anything.
Bad Thing(TM) (Score:1)
Now back to the buisness: In order to install software on a (single) linux system properly, following steps must be performed:
1) check for dependencies and all the other troubles the package may nead or may break. For example: Will I overwrite something? Are the libraries I need on the system
2) prepare for the instalation (PRE_INSTALL script), if nessesary
2) unpack the software-package and put the files where they belong
3) do the nessesary changes in etc-files, (re) start some demones etc => POST_INSTALL script
4) write down a protocol about the installed files, packages this one depends on, and what has to be done if one wants to deinstall it later (i.e. POST_INSTALL script). Obviously, if there is some kind of a package manager on the system this "protocol" shouls be handed to it.
In my opinion, there is only one way to do this properly: by generating the binary packages on-the-fly. I will call the hypothetical program which generates packages "translator" (not installer) from now on.
If you generate packages on the fly, a tarball including binaries + "description" in combination with the "translator" is suficcient to get your program installed on "any" linux system.
I suppose, we could call this kind of distribution a "binary meta-package". I can imagine all kinds of troubles one would run into with these "binary-meta-packages" - because every distribution is a little bit different, but if one concentrates on lets say debian (or RedHat/SuSe/whatever), separates the distribution-related stuff in modules and puts the code under GPL, most of the distributions would make the nessesary modules themselves.
+++++++++++++++++++++++++++++++++++++++++++
The situation gets even worse in case you want to install the software on many machines as I do: In case I have a
However, ever standard
An "installer" which produces custom-made
However, the end-product of this (more-or-less painfull) pre-instalation should be a package custom-made for my system. With all the dependencies, pre-instal, post-install and post-uninstall scripts in place, as well and all the configurations files fixed so that i can say "rpm -i package" and install it and start working with the program later.
Having a big green smiley with "PRESS ME TO INSTALL THE SOFTWARE" on it in the end of the instalation (which does rpm -i package" in my case) is OK, but I really want to have this binary RPM, otherwise i have to make one myself later and that is an utterly annoying and unnessesary work.
+++++++++++++++++++++++++++++++++++++++++++++++
In case someone really does not want to use the package-manager, he should make programs which get installed under
However, I cannot see what good is an "installer" in such a case - All there is to be done is unpacking the tarball and anyone can make a "graphical installer" which unpacks tarballs in a few minutes. For anything more complicated - give me an rpm or I will yell at you.
By the way - i have had a "priviledge" of installing some win95 machines (virtual, under vmware) lately. Instalation of programs was a major pain in the ass:
- press on the "install" icon, answer some questions, wait (you can watch some stupid animation while waiting, though) part was not so bad, but "reboot the PC", followed by "Oh, someone has changed the libraries, should i put them back" was really annoying. As I heard, even win2000 will have some kind of a package-manager.
Re:Ack! No! (Score:1)
The newbie should already know the the single most popular installer, it's called reading the README.
Right on bro ! (Score:1)
A good thing (Score:1)
Our clients are not computer experts. Half the time they can barely boot the damn things up - expecting any of them to do any manual configuring is out of the question. Even if they were knowledgeable enough to do it, why shoud they? They pay us big bucks to solve their computing problems. A simple installation is just part of the package.
And no, they will not look at the README. No they will not manually enter anything into a configuration file. And no, they will not look up what switches to use to unpack a tar ball. The most we can expect them to do is double click on "setup".
And this is how it should be. They are computer USERS. Let me repeat that word. USERS! They want to use their computer as a tool. Just like most of you can not rebuild your car engine, they do not care about the internal workings of the operating system. They want the program installed without having to know ANYTHING about their computer. They want it to create pretty little icons that will launch their programs.
Let's face it. Most users are idiots. We don't want them mucking about with the internals.
Finally, just because a feature is in MS Windows does not make it bad. Microsoft has stolen the best ideas from other operating systems. Someday they might even figure out how to get it to work!
Usability and the average user (Score:1)
Closed-source in a free software world (Score:1)
Re:Does it detect and support package managers (Score:1)
Stéphane Peter
No gzip... bummer (Score:1)
Dopey software companies, M$'s failures and /opt (Score:1)
Some people are saying that that an installer without interaction with all the assorted package managers is pretty silly. I think is is quite smart.
What tools do you put on your system when you do a robust (I'm avoiding saying full because a full Debian would be insane.) install? Just about everything smaller than a bread box and lots of larger things to. Would you use this type of installer to install GNU-Utils? Net-tools? No you wouldn't. That stuff is already there cataloged in the existing database. The type of program somthing like this would install would be external to the core operating system. So I say install it in /opt/package.
"But this breaks the whole UNIX philiosphy.", you say. I agree, I have used the method of sorting config files, binary's, system binary's, home directories and so on to my atvantage many times. "So why do it?", you say? In a three byte extention .dll
How many times do you thing M$ has been blamed for dead or broken OS's that weren't their own doing? Probably more than you or I think. Can you picture a user who dosn't know the system that well, installing a new commercial software package every week. How long is before one of those dumb companies overwrites svgalib?, gtk+?, a kernel module? Yes this problem is part solved on Debian (kudos to the developers) but what is really needed is a standard(all distro's) compare and autoupdate system that will fix any damage a program could do to core libraies.
A broken system should be able detrmine it's broken, to get on the net (yes the net not a cd), and ask how to fix it's self, double check with the user(a "yes" should do it.), download the fix, and commit it. Silly? Crazy? I don't think we can advocate letting just anyone write a .rpm or .deb without it. Let the programs install everything they need in /opt and the /home/user/.program directories.
Yes, I'm aware the GPL would force companies to allow fixes to made to said broken libs under the GPL. That dosn't mean people will know how to install them.
The bottom line is very soon Unix(Linux) will be everywhere and people will think Linux is broken if closed source commercial programs are allowed to romp around the system and change things. If you were one those tens of millions of new users, and you thought Linux is broken because of such things, you would be right.
Here's to two systems, a package manager for the core and system wide apps, and one for commercial closed source apps in the /opt directory sorted by subdirectory package name. A user who is a member of an opt group, should be able to to do the install.
The problem you're complaining about... (Score:1)
The reason things don't 'just work' anymore is because of all that stuff hidden in the 'lib' directories... shared libraries, they have to match in version to the software or it won't work right.
'Installers' in windows deal with this by writing the 'correct' version of the
'Installers' in linux, depending on your distribution, generally install -either- libraries or apps, and in the case of apps, check the versions of libraries (and other shared resources, drivers for example). If they don't line up, it balks and refuses to continue.
The 'solution' to this 'complexity' is to go back to static linking - or the modern variant, putting the shared libs in program-local directories, and not really 'sharing' them. The difficulty with this 'solution' is your 2meg program can becom a 100meg program mighty quick. IMHO, Windows has enough bloat and Linux doesn't need it, so I'll take the 'complexity' over the 'solution.' After all, the complexity was originally a solution to the bloating caused by repeated copies of the same code being linked into each program.
Re:Important software (Score:1)
Or rather, it seems to be something that most people are relatively comfortable with... moreso than the howlings would indicate that they are with the way linux currently does things.
Don't get me wrong... I install everything via "tar -zxvf && less README &&
But for a newbie, a standard GUI interface that hides the background mechanism, installs into a location the user can supply interactively, and provides a consistent user-friendly uninstaller would be a Good Thing (TM).
Hell... who knows... if it ever matured at all, I might be convinced to use it myself.
--
- Sean
Re:The Installer (Score:1)
It goes... "rm -rf"
--
- Sean
Ummmm.... multitasking? (Score:1)
As an example (I'm at work right now, so running NT, but the principle still applies), I am currently running:
- Outlook 98
- Word 97
- Excel 97
- PowerPoint 97
- Access 97
- Opera 3.6
- WordPad (5 copies)
- MSIE 5.0 (3 copies)
- Notepad (about 10 copies)
- VB 6.0 (2 copies)
- VC++ 5.0
- MS Peer Web Services
- CD Player
- Calculator
- Various explorer windows
- ICQ
- QuickADS (a program I'm developing)
- VShield
- Various other crap.
So, how do you propose I do that off of bootable CD's? PC's aren't consoles, and they don't work like consoles. My PC sure as hell isn't just a game-playing machine (although I do run games on occasion, yes). It has very different needs. Unless you can figure something out, then thanks but no thanks.
And I have zero intention of waiting while each one of these loads itself off a CD into memory. That just ain't happening. Bzzzt! Thanks for playing...
Next!
--
- Sean