Point-and-klik Linux Software Installation? 212
bfree continues: This is not the only change in klik recently however, now applications are built into compressed image (cmg) files rather then stored as application directories. This means that you can store the application on any filesystem and move it around at will. Klik no longer totally depends on kde. Where previously klik could only be used with konqueror, now you can also use firefox and elinks, and where previously kdialog was required, now any of dialog|Xdialog|kdialog should work.
Klik now also supports more distributions fully. The officially supported list of distributions is now Knoppix (3.7), Kanotix (BHX), Linspire 5.0 and Simply Mepis (2004.04). Klik assumes that you will have installed at least the lowest version of any package which is present in all supported distributions and build the applications as such. If a package you want klik to install depends on a package in this base system it will not be included in the cmg so you must have it installed or add it to the cmg by hand afterwards. If you want to try using klik on another distribution, your results will primarily depend on whether or not your distribution has the packages the cmg depends on and assumes are present. So you will certainly fail to install kde applications on a distribution with no kde (as all the supported distributions have kde), but programs with simpler, or less common and therefore missing from some supported distributions, dependencies can work just fine.
One of the best ways to demonstrate the power of klik's techiniques is with the Christmas present from probono, an OpenOffice.org cmg for version 1.9.65. With this cmg (which runs on far more distributions then klik's supported list, especially as it uses Linux transparent iso compression rather then cramfs) you can download one 100M file to try out the preview release of Ooo, no need to upgrade any parts of your system and if the system has been setup by root to use cmg files there is also no need to even be root. I think this demonstrates the very best feature of bundled applications, you can try a potentially reckless preview release of software without having to upgrade your system.
Nice, but... (Score:4, Funny)
Re:Nice, but... (Score:3, Insightful)
Re:Nice, but... (Score:2)
This Is What I Get At The Site Using Windows Opera (Score:5, Informative)
If you were visiting this site with Linux, you could install thousands of applications simply with a klik. You can download a free copy of Linux here. Please come back with a standards compliant operating system and browser.
This site is optimized for Konqueror and Firefox."
I don't like this shit when it happens with IE and I don't like it when it happens with Linux.
Fortunately I use Red Hat, so it doesn't matter...
Re:This Is What I Get At The Site Using Windows Op (Score:3, Informative)
Re:This Is What I Get At The Site Using Windows Op (Score:3, Interesting)
Re: (Score:2)
Re:This Is What I Get At The Site Using Windows Op (Score:2)
Re:This Is What I Get At The Site Using Windows Op (Score:2)
Er, read it while I happen to be using Windows?
Duh...
Re:This Is What I Get At The Site Using Windows Op (Score:2, Interesting)
Being a Windows user and being interested in Linux are not mutually exclusive things.
I first tried Linux back in high school after hearing about it from friends and even bought a copy of Red Hat Linux 6.2. I've installed Slackware after seeing it mentioned a lot on the Internet, and Gentoo I discovered one day probably through Slashdot, and after reading their installation guide I thought "cool, I'll give it a try." In fact, I'm downloading GoboLinux right now after being reminded of it through the last li
Re:This Is What I Get At The Site Using Windows Op (Score:2)
Re:This Is What I Get At The Site Using Windows Op (Score:2)
In short, while the webmaster may have thought they were being cute, this is just plain stupid. W3C standards are good, use them
Re:This Is What I Get At The Site Using Windows Op (Score:2)
Re:This Is What I Get At The Site Using Windows Op (Score:2)
K-naming jokes follow (Score:2, Funny)
Oh, wait. This isn't related to KDE.
User Agent String (Score:2, Informative)
Re:User Agent String (Score:2)
That's true, but the same thing happens if you run Opera and spoof your agent id, which is the problem here.
KDE-centric worldview? (Score:2, Insightful)
Re:KDE-centric worldview? (Score:2)
Most likely, they just didn't bother to make it work with anything until it was good enough that this fact even mattered.
Re:KDE-centric worldview? (Score:5, Informative)
Actually, the latest version of gtk-qt [freedesktop.org] is pretty damn good. I think it has the potential to become a "standard" for KDE users once all the little bugs are worked out.
Re:KDE-centric worldview? (Score:3, Insightful)
Surely no Gnome-user would have a gnome-centric world-view ever.
Re:KDE-centric worldview? (Score:2, Flamebait)
Re:KDE-centric worldview? (Score:2)
It looks nice, but is among the most frustrating software I've ever tried to use. Gourmet garbage is what it is.
Re:KDE-centric worldview? (Score:2)
Seriously, if takes a hundred megabytes, a gigabyte, whatever, so what. If it takes you even five minutes to troubleshoot an application you're never going to recuperate your e
Re:KDE-centric worldview? (Score:2)
time is expensive
Yes, it is. Adding extra libraries not only increases resource usage (agreed, not particularly important) but also fragments the code and slows load and execute times. That is important.
Both gnome and KDE take far more time than they should to do simple operations. It needs to be fixed.
---
DRM - Democracy Restriction & Manipulation
Re:KDE-centric worldview? (Score:2)
Both the desktops are putting more effort into optimisation now they have most of the functionality required.
Re:KDE-centric worldview? (Score:2)
"Premature optimisation is the root of all evil" as somebody once said.
True for code/peephole optimisation but less true for functional/design optimisation.
Too many software projects assume that any functional design will be fast enough. For instance, they often don't appear to understand the difference between an O(n^2) algorithm and an O(nlogn) algorithm, nor the major timing differences between a polled interface and a callback/callforward interface, nor the way many small delays accumulate into a
Re:KDE-centric worldview? (Score:2)
I get the feeling that a lot of Free software developers are like me: people who can program well enough, but have little formal education in development techniques.
It's been a difficult learning cu
Re:KDE-centric worldview? (Score:3, Informative)
Re:KDE-centric worldview? Or parent is trolling? (Score:5, Informative)
2.) klik was first developed to install applications on in Knoppix (which uses KDE). Since Knoppix is on a read-only medium (CD-Rs) the dependecy on KDE was a real one.
3.) klik on longer depends on KDE. Just RTFA for once please.
4.) As far as I know, probono the developer of klik is not a official KDE developer.
Try googling or reading instead of posting First forum post by probono about klik back in Jan of 2004 [knoppix.net]
Finally maybe someone gets it (Score:5, Insightful)
we call them EXEs.
Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!
Re: (Score:3, Insightful)
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:2)
Let's try that again.
Just to bad you can't upgrade all your Windows applications with a command or two.
I want to see a single klik way to transparantly upgrade my parent's WinME box to Linux. Not because they have lots of trouble with it, it's just because it's WinME.
poor excuse (Score:2)
As a rule I only download a new version when security issues appear.
You must spend a lot of time keeping track of security vulernabilities if you plan on keeping all your software up to date manually. How do you even keep track of the updates? Do you visit the web page of every software package installed on you
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:3, Informative)
It's pretty neat and for the most part worked. Sometimes (rarely) it asked me for permission to put something onto my system outside of the application's folder.
So I think it's great, and something like this will probably be the future of applicat
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:2)
It has nothing to do with comptency. Indeed, if you package everything into a static executable, it is at least bad practice, if not incompetent. It makes a program suck up 10x as much memory as it needs to.
neither does Firefox!
Firefox certainly requires installation.
neither do a good deal of my games
What games don't require running an installer? No mainstream game I've used since the early 1990s comes without an installer!
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:5, Informative)
This is actually a much harder problem that you might think. There are a few different solutions. The Windows solution has been a combination of trying to bolt down a core set of libraries that everyone can be expected to have, and generally completely ignoring dependencies/shared libraries and letting the installers either trample each other, or install multiple versions of the same thing in different places. It kind of works, but does have drawbacks.
On Linux you could effectively do this by just having all packages statically linked, or have each package bundle up its own versions of all the libraries it will ever need. Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep). The problem is partly that open source has a release early, release often approach, which means the base set of libraries (which Microsoft simply bolts down) tends to be an ever moving target (Microsoft simply does everything in huge upgrade jumps every now and then instead... except for a few things like DirectX). The other half of the problem is that with all that source code out there being shared freely there's an awful lot more code reuse and a much broader range of shared libraries and hence dependencies. This is a good thing most of the time, but causes issues for installing software.
Linux got around these dependency issues by having distributions which package up all the dependencies for you. This works very well, especially with apt, apt-rpm, yum, portage, and all the other fun dependency resolving tools, but has one drawback: If you aren't installing a distribution provided package the system has a lot more trouble tracking (and especially resolving) your dependencies. That means installing and maintaining a Linux system is easy, but adding new software from third parties can be a pain in the ass. Debian and Gentoo attempt to solve this dilemma by havign so many packages available from the distribution that you don't want for anything. As well as this works, it again isn't quite a complete solution.
Which finally brings us around to the open source attempts to try and provide systems to allow third parties to package software. The principle now is: You let the distribution do the hard yards of installing and maintaining the syste with their packaging and dependency resolving systems, and simply provide some distribution neutral package format that can still slot in amongst all of this. There are several solutions, each taking a slightly different approach such as ZeroInstall [zero-install.org] and Autopackage [autopackage.org]. They are still in the works, but look to have some surprisingly good solutions. They are definitely worth a look.
So, in summary, Windows manages to have their system by:
(1) Locking you down on base libraries, and having a slow upgrade cycle on those.
(2) Windows developers not sharing as much code, and not caring about actually sharing libraries even when they do.
That is a perfectly valid solution, and it does work, but its never going to fit with open source, which has a pretty fast developing set of base libraries (which is a good thing), a lot more emphasis on code sharing, and an eye for efficiency. That doesn't mean open source can't have easy to install software (it already does for anything distribution packaged, and various solutions for third party software are well on the way), merely that, because of some fundamental philosophic tenets of open source, it is a harder problem than on Windows, and requires more cunning solutions.
Jedidiah.
Re:Finally maybe someone gets it (Score:5, Informative)
Actually it is more like a base API, the various libraries constantly go through upgrades and such, more of a feature lock.
On one hand this is a bad thing, Windows did not even have a (decent!) built in dearchiver until Windows XP, but on the other hand it is also a good thing, as the free market allowed a number of competing (and ultimately superior) archival formats to come forth and not have to fight against any one single OS-supported format.
A key question becomes, on client workstations, are shared libraries REALLY all that much more efficient, a good trade off for the hassle that they cause?
Honestly, a good HTML renderer, sure, Windows software has found a million and one ways to make use of that (A good portion of Visual Studio.NET's UI is basically a fancy IE window from what I can figure out, at least it behaves like one!), and other things like built in sound and video acceleration are (of course) handy to have around, but honestly, how often is some huge shared library really going to be used?
Lets see, if I have a 3D modeling app open, Winamp playing tunes in the background, and my browser of choice (Firefox or IE which ever) up and running, what use are shared libraries to me?
The UI, sure, but Windows has that, granted the options kind of blow, Win32 or
A standard image manipulation library? If I install a new image manipulation program I want something revolutionary, something different, from it. Heck, $400+ painting programs sell specifically because the programmers have developed some kick'in libraries that are limited just to that program. Besides, I don't want a shared library that specializes in doing a Physics Simulation of paint on paper!
Games? Sure, to some extent I guess, but how many games am I going to be having running at once? Honestly? 2 tops, even that is rare, most likely, just, well, 1.
On server and application server environments, shared libraries are a blessing, but for a client environment, flexibility and the capability to rapidly deploy applications to the end user seems to be higher priority.
Re:Finally maybe someone gets it (Score:2)
So like any powerful tool, there is a tendency to overuse it, or use it where it's not appropriate. Without shared libraries we could not have systems like Windows XP, Linux or MacOS X because n
Re:Finally maybe someone gets it (Score:2)
Note that I don't use GNOME or KDE, so the actual savings are quite high. The top two memory hogs are Mozilla and X at the moment. My GTK+ apps are using about 4 Mb of RAM each, but 3 MB of that is shared memory, so the effective use is about 8 MB or so.
Re:Finally maybe someone gets it (Score:3, Insightful)
I had complaints with this simple scheme. So I had to make the a self extracting archive. Sigh.
Re:Finally maybe someone gets it (Score:2)
When I originally created the Windows version I simply put all the files into one directory, zipped that up [...] I had complaints with this simple scheme.
No wonder, considering the fact that Windows did not ship with any kind of unzip until Windows XP. I too hated zip installs - mainly when I was reinstalling Windows or helping someone else install stuff - and most of all when the machine wasn't on the Internet. And WinZip is like 3MB, which takes a while on a 28.8 modem.
It is really quite funny tha
Re:Finally maybe someone gets it (Score:3, Interesting)
Re:Finally maybe someone gets it (Score:2)
Re:Finally maybe someone gets it (Score:2)
Yup, it's called static linking, and it's actually not all that good. Linux could do it, but made a chocie not to go that route - open source went the hard way and ended up with lots of dependencies. That has meant solutions have been slower (we're still waiting on solutions for third party apps, but they're coming), but it will be worth the effort.
St
this is wierd, totally (Score:2)
Somebody mentioned earlier this is like apt with web access. Well, reading that, it's more like brain-extracted rpm with web access. You want it, take it.
Re:this is wierd, totally (Score:2)
BTM
Re:this is wierd, totally (Score:3, Insightful)
Re:this is wierd, totally (Score:2)
BTM
Re:this is wierd, totally (Score:2)
What package does that? If package b includes some files that are commonly used by other packages, those files should be packaged separately in, say b-common. Debian has lots of *-common packages.
If it's just a few icons, another alternative would be to simply ask the person who packages a to include those icons in a (renamed or in another directory, so a doesn't conflict with b).
Re:this is wierd, totally (Score:2)
Re:this is wierd, totally (Score:2)
OO is NOT "the best way to demonstrate klik power" (Score:5, Insightful)
OpenOffice is one of those huge projects which come in preinstalled preconfigured and self sufficient package which have to be decompressed in one directory.
So having a "klik" package is not a proof of technical achivement, as it would be trivial to have a, say, loki setup or even a script which untar the package and put the missing entry in PATH.
No, give me a klik package of some kde or gnome program wich installs and works with every distro, aka fit nicely in every distro and rely on dynamic and present librairies. THAT would be a true demonstration.
How does it work without root help? (Score:3, Interesting)
I believe this klik system could have real application across all kinds of distros, even RPM-based. However klik still doesn't truely offer (due to how linux works) apps that are dependency free. For example the galeon.cmg would still require mozilla and a few other things. I suppose they could make each cmg independent, but then we'd have tons of glibc's in memory, plus multiple copies of gtk, etc. How do they get around this issue?
It appears the main target of klik is to allow the downloading and running of software in a liveCD environment. How will this work in a real environment?
Re:How does it work without root help? (Score:2, Insightful)
You can break your system hard.
Post inst script of rm -rf / will wipe yor system. So I really need some more explanation before I Klik from my Debian PC.
Osamu
Re:How does it work without root help? (Score:2)
Re:How does it work without root help? (Score:2)
As for mounting the compressed file systems, they could use avfs (relative of fuse) to virtually mount the cmg file and intercept all file i/o calls to make it appear as though the cmg was mounted and give transparent access to these files. Such a scheme would not require any root support at all, since it would al
A step in the right direction (Score:3, Insightful)
As a bonus, the linked application only runs with the user's privilege level. That means if it's a malicious app, it won't hose the whole system, and security/recovery becomes much easier.
It almost makes me want to try out desktop Linux again (using OS X right now).
Similar to .app or .dmg on OSX (Score:2)
It's a good start.
Hmm (Score:2)
step backwards (Score:2, Insightful)
Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when
Re:step backwards (Score:2)
Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when they are going to get upgraded and whether the different pieces that are installed are going to be compatible. That is not progress.
The .app packages that OS X use combine the dependencies within the .app directory so you don't have to worry about incompatibilities or causing problems with other apps in case the version of the d
Re:step backwards (Score:2)
Not difficult at all, it just doesn't work.
First of all, applications have dependencies on operating system libraries,
Re:As a Gentoo user (Score:3, Interesting)
Sure you can be opposed that's fine but nobody's telling you to go for it or nobody's telling the guys at gentoo "ok, follow the klik's way!"
It's simply more choices and the ones who will prefer this are the migrating users who come from windows. They have to point & click the most possible to get confortable with an o/s environment.
Re:As a Gentoo user (Score:2)
As someone who isn't 3133t (Score:2, Funny)
Re:As a Gentoo user (Score:3, Insightful)
Re:As a Gentoo user (Score:2, Insightful)
What I'm seeing now is that Portage has a couple really cool advantages over other packaging systems, and with those features come a horde of less wacky e
Re:As a Gentoo user (Score:2)
Re:As a Gentoo user (Score:2)
Re:I wonder if it works on laptops (Score:3, Insightful)
Re:Sounds good to me (Score:5, Informative)
Unfortunately I don't think klik, as nice as it is, is quite the solution to this. I would suggest, instead, that Autopackage [autopackage.org] is a far better solution for providing a means for installing third party packages. The people writing autopackage have spent much time carefully considering the difficulties involved, and have some very cunning solutions to some of the problems.
What does Autopackage do well? For starters it does the basic things that you'd expect well - it's got a nice GUI installer, it can fall back to a console installer, and it nicely wraps up a binary package in a "download and run it to install it" system. It has other bonuses that are more subtle, but for third party packages, suprisingly necessary. For starters it is distribution neutral, but at the same time does dependency checking and resolution. That's not so easy if you actually think about what it requires.
Autopackage is, of course, still in development. The really nice features (integrating in with rpm and dpkg databases etc.) aren't coming for a very long time yet. For now though it does work, and can install packages. If you're writing software it may be worth your while to look at what Autopackage asks of developers (you do need to do a little work to make code autopackageable) and keep it in mind as you go.
Jedidiah.
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
It does not solve what is the real difficulty with installing Linux software: Installing something that has not been prepackaged for you by your distribution.
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
Klik is a very nice system, and it works admirably for Debian based systems, but ostens
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
Welcome to "The Problem". How do you know what's installed, and which version it is? If it's Debian it's easy because it's all standardised, if its any distribution then it gets very hard very fast (particularly on version of li
Re:Sounds good to me (Score:2)
Is there a seperate package repoisitory somewhere?
They have so few packages because they are still in development on the packaging system. As I said, an application (or library) developer does need to make some changes to the code to make it autopackage ready. The changes are small, and are very little work, but they do need to be made.
As to other repositories - anyone can set up their own autopackage repositiory, so a third pa
Re:Sounds good to me (Score:4, Interesting)
Then we're talking around each other, because you seem to have missed my point.
Debian's "easy" system isn't easy because of its size (as the autopackage faq suggests) but rather because of their strict adherence to policy standards.
We're talking about installing some software. It is "easy" to install software on Debian if it is in the Debian package repository. If it is not, then how exactly are you planning on installing it? Compile from source? Not "easy". Download a third party provided DEB package? That ought to work, but that's hardly easy for the developer who has to provide a DEB package, a Fedora RPM, a SuSE RPM, a mandrake RPM etc., and then there's the issue that maybe the DEB was for Ubuntu and linked against some libraries in Ubuntu that aren't in Debian stable yet. In short, installing software that is not in Debian's repositories is hard. This mostly doesn't matter because Debian's repositories are BIG so the odds of wanting to install something that isn't there are rather small.
You can discuss policy standards all you like, but in the end if the software isn't in Debian, it isn't likely to be following those standards.
Let's be clear anyway: Autopackage is not a replacement for dpkg, apt, and all the usual Debian goodness. It is complementary to all of that, and is meant to provide an easy way for those "not in the Debian repository" packages to still be easy to install (and at the same time allow developers to package once, instead of "once for each distribution").
And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators.
Autopackage is about empowering users not just administrators. A user can go to the homepage for [insert random application here], download the autopackage file provided there by the developers, then just double click to run it and up comes a little installer that checks and resolves dependencies. One of the key points of Autopackage is for binaries to be relocatable. That means a non-root user can still install an autopackaged file - it just gets installed to their home directory instead of systemwide. Autopackage is not meant to manage a distribution - Debian and Redhat and SuSE already do that pretty well. It is about providing a way for extra third party application not already in the distribution to be easily installed by users.
Jedidiah.
Re:Sounds good to me (Score:2)
So the easy way of installing third party packages on Debian is to compile it from source? That being what stow (which I use), and from the look
Re:Sounds good to me (Score:2)
It is best described as a hybrid between NSIS/Loki Setup type installers, and package managers such as dpkg and RPM. Autopackages are programs that understand the quirks of vario
Re:Sounds good to me (Score:2)
The right way to solve this is by providing binary relocatability support in core libraries and small utilility files that can be statically linked. This is what binreloc is, you can find out more at the autopackage homepage, and it's designed to be trivial to drop into pre-existing software. It
Re:Sounds good to me (Score:2)
Also in future we want autopackage to know how to use apt to install things it needs, as well as being able to resolve dependencies from other autopackages.
Aut
Re:Sounds good to me (Score:4, Insightful)
If Linix is ever going to be a real force on the desktop in general, and not just the corporate desktop, it needs to do some serious work on how programs are installed.
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
Indeed, I can see such a system actually working better on Linux than it does on OS X due to the ability for the package to contain executables for multiple OS's. A single package could contain executable code for Linux on x86, x86-64, PPC, S390, Alpha, MIPS, and all other Linux architectures (along with Mac OS X if one wanted to). Have a buddy running a different architecture you want to share an application with? Just copy it to their system as-is: the loader selects the correct executable and libraries within the package to use, with all the architectures sharing common application resources.
Installing applications on Linux is one of the major hurdles for Linux to 100% pass the "Mom test" here (my mothers system is running Fedora Core 3, because it's vastly easier for me to manage and maintain for her remotely than Windows ever could be, and I don't have to worry about her accidentially deleting system files or otherwise munging up the system somehow, besides being stable and damn good looking!). Mom recently wanted me to find and install a bunch of card games and little arcade games for her, and besides having a hard time finding many such games that suit her tastes on Linux (she doesn't want online multi-player, and doesn't need 800 different solitaire games), the ones I was able to find were a PITA to install (as most of them were source-only, build-it-youself, and then go in and manually create the necessary data files to add them to the Gnome menu, the latter of which I continue to believe there is no excuse for anyone to have to do).
On top of this, IMO the Open Source community needs more package maintainers, especially for smaller projects. It's hard enough for a moderately popular project to keep up with development, user requests, bug reports, end-user support, web site maintanence, and documentation as it is, nevermind trying to ensure your project gets packaged for the myriad of different packaging formats out there (and not just for Linux either if your project is portable to other OS's).
Okay, rant mode off. I neeeded to get tthat off my chest :). Linux program install has a long way to go before it's going to be friendly enough for the average non-sys-admin user.
Yaz.
Re:Sounds good to me (Score:3, Interesting)
Re:Sounds good to me (Score:3, Interesting)
Re:Sounds good to me (Score:2)
Overall, good comment. Some things I'd like to respond to:
I'm sure you know this, but just for those who may not (and interpret your message incorrectly), Mac OS X does indeed have a shared library mechanism.
With that out of the way, as you've
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
Re:Sounds good to me (Score:2)
I've done this by ssh'ing into a computer from many miles away, emerging the app, waiting for it to compile, and it will appear in the gnome or kde menu. This is why command line package systems are nice, you can easily use them using ssh without having to worry about X forwarding. And portage will put the little icons in the menu which is very nice.
Re:Sounds good to me (Score:2)
The Mac OS X application packages can also be "installed" via the command line by mounting the disk image (if any), cd'ing over to it, and then using "cp" to
Re:Sounds good to me (Score:2)
Yggdrasil (Score:2)
One of the first simi-live cds with a truly GUI install. I even bought a copy back then. ( doing my part to support OSSish development )
They were a bit wierd thou.. explains why they dissapeared.