Loki releases an installer
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?
Hmm, Maybe this one than get rid of EVERYTHING that it installs! - I have never seen an uninstall routine to do that yet!
IT Technicians Never Die, Their TTL Expires!
Hmm, my post time is before yours, and you got score 0?
IT Technicians Never Die, Their TTL Expires!
First Post?
Is there any information out as how it handles the
different distributions and windomanager/desktop environment menus?
There is also a project zenguin that is supposed to handle the same probs. But their page
doen't seem to be updated frequently. Any info
about their progress?
I think this is an interesting lil program that will really help Linux become much more widespread and get the standard user more comfortable with the transition to Linux. After all one of the main reasons Windows is so mainstream is its "do everything for you attitude", and the "work it out yourself" nature of Linux seems to have deterred, and even instilled fear into the average pc user.
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?
Come on, wake up!
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.
Sounds great. If the installer detects the package management system being used on the computer and registers the stuff to install into the package database it is great to the power of 2.
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 this is quite much a application needed for newbies to get software installed to the linux box. Moving to the linux from the windows world is very confusing for a many reason. Installing software with RPM or DEP isn't quite easy task to perform after you are used to use some windows installers. (Install shield for example)
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.
Anything that makes it easier for the clueless/
lazy/inexperienced to
use Linux is A GOOD THING. The more the merrier.
I want the world to head towards a bright future
with less MS-Domination.
A new Linuz user may well learn more as they use it.
We all have to start somewhere... it may as well
be the way of the penguin.
Lazy-Coward.
"Romanus eunt domus"
This is a terrible idea. Loki should release their software in standard .deb/.rpm package formats and let the distributions handle installation, dependencies, removal, and upgrades. This is what distributions do! Let them do it! We don't need an "Install Shield".
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?
Kinda makes you wonder what the point of Linux even is. Everyday it gets more like Windows/MacOS.
Next thing you know it'll have start menus and control panels... Oh wait, it already does.
Yes RPM for idiots, RPM for people who have better things to do than fix broken dependencies, RPM for people who don't really care about RPM.
Sounds great.
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.
I don't know how to install libxml 1.4.0 :)
I don't know how to install libglade 1.7
I don't know what meab "./libs"
Where to type : " Type 'make; make install' " ?
Where is my wife ?
We need a GUI Installer for the Installer !
I think that it's important to have a standard install interface for those that want it. A uniform way to do things will make one of the most difficult processes on linux, installing, a bit more intuitive.
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.
[Science] is one of the very few things that raises human life a little above farce and gives it the grace of tragedy.
What I do like is that this seems to work for both windows and linux. Why this is a good thing for me? Because I want to write commercial programs that will work both under linux and windows (most of development under linux) -- I already use platform independent (gui) libs for this purpose and having a platform independent installer might be nice too.
;-) Anybody has any links for other free/open installers, btw.. esp. ones that work under windows (too)?
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.
I plan to plan / Dutch course in The Hague
/*This is a terrible idea. Loki should release their software in standard .deb/.rpm package formats and let the distributions handle installation, dependencies, removal, and upgrades. This is what distributions do! Let them do it! We don't need an "Install Shield". */
/opt/packagname anyway? Uninstall is through the tradtional, flexible and powerful (albeit rather unfriendly) rm -rf /opt/packagename
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
A new graphic installer should make for an easier transition for those who were just with windows, but I don't think I would really like it... I perfer the good old fashion ./configure; make; make install; It is very simple and to the point.
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
/opt/packagname anyway?
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?
Whats the point in packages? They don't achieve much IMHO. Dependencies have to be sorted out if you use packages or not. The only thing thats made easier by packages is removing software. How often does one actually do that? I rarely remove software. Who cares if a program's needed or not, the disk space is cheap. So thanks very much for the pretty installer and all the myriad of package formats out there, but I'll stick to my trusty old configure; make; make install routine. Works every time.
rpm -Uvh --nodeps --force package.rpm
*wink*
Bitcoin pyramid: Join here: http://www.bitcoinpyramid.com/r/1427 it's FREE!
Let me answer as well.
.rpm instead.
... ouch) ;-)
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
I have mixed feelings here. On the one hand, it's great that Loki is releasing this, and it looks to be a much better way of installing software than simply having a random perl script to unpack tars (VMware) or something.
/usr/local/stow and rm -rf the whole lot. And how do I track what I've installed once I install more than two or three? How do I update to the latest patchlevel? Download patches and run them? If I find a file and can't remember what program it belongs to, how do I check?
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
Hurry up and jump on the individualist bandwagon!
The install merely has to look for clues as to the distro:
.spec.
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. I only wrote it out of idle curiousity, but I think the principles involved could probably be wrapped into Loki's installer.
-Yarn - Rio Karma: Excellent
Some very good programmers are scared by the load of newbies entering Linux. Releasing a new program means that you'll have to filter a lot of email crap in order to find a patch; most people just yell for new updates and shout about bugs that you've mentioned yourselves in BUGS or TODO files.
Sigh.
'Nuff said.
How else do you expect to grow big enough to get the good companies to make software for it? You need all the users from Mac/Windows, and without a good installshield, thats one more painfull step users wont take to use Linux and you'll be stuck with some lameo shell OS that serves web pages and not much else.
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.
What I'd like to see is an end to installers entirely. Most PCs have bootable CD-ROM drives these days and could load games direct from CD `a la Playstation. Game data could be stored on floppy disks and no hard disk space would be required.
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?
Well said! I'm proud to be called an idiot, a newbie and other such names. But lazy is probably the most apt description. When I'm installing applications, I don't want to mess around fixing dependancies. You don't agree? Good - isn't that the whole point of Linux? I can use it in any way I want? Stodge in disguise - what's my bloody password!?
And if the software you're installing isn't an app? (i.e. a library, etc.)
Shared things, by definition, have to be discoverable by other software on the system...
First - may karma of the troll who marked my first posting as "flamebait" be set to -100 or so. I am quite annoyed.
.rpm package, all i have to do is check if it installs properly on one machine, then put it in a directory where "autorpm" will find it. If I do not have an .rpm package, I have to go trough the "install" procedure N-times. (I can tell you that I will hate You if you do this to me.)
.rpm packages aren't so good as they could be - Usually one has to edit some /etc files after instalation and so on - so basically one ends-up with either "installing N-times" again, or making customized rpm-s, or making a tarball ( or .rpm, or...) out of the files which have been changed after the instalation.
.rpm packages (or .deb or ...) on-the-fly, so that the package can be safely installed using the rpm-manager (or whatever tool on other systems) would be a really GREAT tool. I would be extremly happy to answer all the questions (or whatever) during the first phase - that is, while the "installer" is trying to guess the right configuration. I do not mind reading the licencing agreements or whatever during this phase.
+ ++ /opt/program.
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.
So true! Games obviously should boot off the cdrom and require no os, hard drive, etc. The installation process is a huge deterrent.
I've always said Linux would go nowhere if a simplified installation and configuration method was not developed, something along the lines of InstallShield. I may not be very knowledgeable in Linux, but I do know software deployment on the Windows environment.
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!
-- Will program for bandwidth
It seems most people have forgotten about Microsoft Plays Linux Games at Work. From that article you could reach the conclusion that the average computer user just wants to double-click and go. Sure, most Linux users are more sophisticated but that may not always be the case. Loki is a business and it is in their best financial interest that their products and the operating system they run on are accessible to the average computer user. For those who are complaining that there are package managers to use, yes there are. But they are all different and supporting each one takes more resources. If someone came up with a cross-distribution package management system that could use rpm and deb files then I would understand people being upset if it wasn't used but there is no such thing. You can't expect commercial software houses to have the same goals as the traditional Linux contributors and if you don't like the way they do things then you don't have to buy their product.
I find it interesting to note the number of things Loki has released to the community. Sure, they may be sell closed source products, but they've contributed several things under the LGPL (their installer, their smpeg library) as well as contributing to the SDL project (a video/audio library which they use in their products). Even though I don't like the idea of this installer, it's cool that they released it. I think Loki sets a great example for how a company can sell closed-source products in (and even contribute to) a free software world.
Oooh, can I sit through load times, just like my good old PSX if I have a slow CD drive?
What about music? Most modern games are smart enough to stream music off the CD, instead of having to load music files into memory. Ever wonder why you get MIDI-type music in most console games? Because it's easy to load into memory.
-AC, too lazy to log in.
Oh well... but 1 of 2 on tar isn't so bad... gzip is cool, it gives you that nice .gz extention version that ugly capital Z... well anyway, it is good to know this about Solaris and AIX.
By the way, part of the point of making the installer freely available is so that you can add your distributions support, and otherwise improve it.
Free software - you can improve it!
--Sam Lantinga, Loki Entertainment Software
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.
Novel theory: Modern Man evolved from psychopath
The problem you're complaining about has little to do with installers (directly). .dll into the appropriate directory. This may then break other things.
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.
--Parity
'Card carrying' member of the EFF.
With debian, you just do "apt-get -b source package" and it does the download/compile process for you if the binary packages don't work. You also can set compile options.
When a program is uploaded to the Debian master server, the server compiles it for all platforms (i386, powerpc, sparc, m68k, mips (?)), so, for the most part, all packages are available for all platforms.
So how can I run multiple programs at once with this scheme? Maybe I'm missing something, but...
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
It's a fine line between trolling and karma-whoring... and I think I just crossed it.
- Sean