Slashdot Mirror

This is silly. It's been raised on the Ubuntu lists time and time again. Nonetheless, they refuse to enable it, because Canonical can't guarantee security updates for it. That's also silly, in my books, but then I find the whole idea of a Universe repository very silly indeed; it's simply not possible for a distro to ever be 'finished' like that.

Unfortunately, whilst new means of distributing software are being developed, the distribution developers generally strongly dislike them and sometimes go out of their way to cause difficulty for them. At some point there'll probably be a new wave of distros derived from the current ones that take the last "easy steps" to make Linux really usable for family and friends. Hell I'll do it myself one day if need be. Fedora is so close yet so far!

Still ... it's easy for Asa to criticise now. But think about all those years that Mozilla lumbered on with essentially zero popularity outside of the geek world. It wasn't until Firefox (which took years to develop) reached version 1 that things really took off. Linux is still in the Mozilla Seamonkey stage: cute features are being developed but that last stretch hasn't been reached yet. Arguably, it hasn't even been started.

Guys, Joe Six Pack just wants things to get done. The current rpm hell does not cut, it and even Debian's apt still has a hell of problems. Time has come for the Linux world to do something about software installation on Linux. For an average user, there is just too much information.

Consider this: If one wants to install =package-name=, this user will be presented with the same package for at least six major distros. Heck, as an average user, I thought I used Linux! Sadly, on the desktop, Linux might never fly!

First of all migration is raised as an issue: "When Regular People fire up the Linux desktop for the first time, the browser, office suite, email client, IM client, file manager, etc, each need to carry over as much as possible of the Windows application settings and all or very nearly all of the user data."

First of all that's a steep ask, but secondly I just don't think it's necessary. If that was required for people to switch no one would ever move to Apple. It's definitely a nice idea, and in the "nice to have" category, but I don't see that it's a deal-breaker.

The second point is API stability: "A user should be able to install Fedora Core 4 and go grab the latest Firefox release from Download.com and have it work without the need for finding and installing compat-libstdc++ or whatever."

This one is fixed - if developers would actually pay attention. Autopackage allows developers to package up their application into a self installing executable that can do dependency resolution. At that point not having compat-libstdc++ is the developer/packager's fault: they ought to have included an Autopackage for it in their repository so the installer can fetch it if it finds the right version of compat-libstdc++ isn't already installed. Better still, the people at Autopackage provide relaytool which allows developers to smoothly fallback to other library versions: for example, you can have your binary use the new GTK+ file chooser if it is available, but fallback to using the old one if it isn't. Which is really saying that the problem has been solved, it's up to the developers and people releasing the software to make use of the tools available.

The third point is preferences: "Gedit has about 30 user preferences spread across 5 tabs in a preferences window -- Notepad has about three."

Now that's not a great example becaue Gedit does a hell of a lot more than notepad, but I think the point is still very valid. To be fair I think GNOME has been putting in a lot of work on this front, and trying to clean a lot of these things up. That work is ongoing, and we can expect to see continuing improvment. That is, the way forward has been laid out, it's just a matter of continuing down the path.

The final point is "comfort":"The final major issue is comfort. Linux must feel comfortable to Windows users. Most people using computers today have been at it for a while now and they've been at it on Windows. Don't mess with their basic understanding of how things work."

I have to say, I think this one is a little dubious. If there is a better way of doing things why not do it? I think constraining yourself to the way Windows does things is a little pointless. There are plenty of things Windows does well, and it's fine to follow those examples, but there are plenty of things Windows does badly, and slavishly copying broken behaviour really doesn't make much sense.

I think the real point here is: be patient. I think the points are valid, but they are also largely well known, and being dealt with. Linux on the desktop is not going to "take off" anytime soon, but the rate of improvment in desktop Linux is tremendous, and it is making slow but steady inraods. Software installation (which has been the recent bugbear that people complain about) is looking quite good with Autopackage and Smart, but both of those are very new and it's going to take some time before a lot of stuff shifts over - that's life. GNOME is working hard on the preferences trim down and clean up, and, I think, is workign towards a fairly clean easy to use Desktop. KDE is headed in a different, but equally valid and interesting direction - I think the divergence is going to end up providing some real significant choice. Finally I think once all these bits properly fall into place and desktop Linux manages to make a dent in the enterprise (which seems to be where the major distros

Yes, Novell should be very concerned here. Their product though good, is heavy and YaST is as slow as hell. I hope the new distro will be apt-based. Even better would be that it becomes based on autopackage http://autopackage.org/ because the packages could the be able to install on [any] distro.

Sound - fixed in FC4. ALSA dmix takes care of this for sound cards that can't do hardware mixing. It works for every ALSA app, which most programs now support. The "aoss" program can be used for apps which still use OSS (though it should be applied automatically ... expecting users to know this is silly)

Synaptic was never designed to have a good UI, it was designed as a frontend to apt-get. Try autopackage if you want software installs with a simple and straightforward user interface. Yes, not many packages yet. That is teh suck. Ask your favourite projects maintainers to build them!

Applications - you should never have to add items to the menus manually. If you need to do that, it's a bug in the application itself (some apps just don't register menu entries). Why not send a polite email to the maintainer asking them to add a menu entry and icon for their program?

One other person said they had to wait several hours for it to show up, or that they had to restart gnome-panel to make them appear. This is always a bug; the items should appear instantly. Unfortunately the "gamin" server which is replacing FAM has had a lot of teething problems, in my experience. Make sure your system is fully up to date. It's a pretty good demonstration of Spolskis "don't rewrite software" maxim.

Firefox - not much to say here. Yes, it can be slow with lots of tabs. There are a bunch of nasty memory leaks fixed in the "Deerpark" release that should be going stable soon.

Folder Navigation - this is only a problem in Ubuntu, which unilaterally decided to change the file manager so the old window closed itself when a new window was opened. In the "real" version which Fedora uses, they stay open. The downside? If you have deeply nested folders, you get lots of windows. The upside? Easy to have multiple folders open at once. For the next GNOME version the Nautilus browser view is getting much improved: it's likely that Ubuntu will switch to browser mode by default at that time rather than continue to hack spatial mode.

Autopackages will back up any file they overwrite rather than just erasing it, like RPM would (the conflict detection only works if everything is installed via RPM, which often isn't the case).

No doubt this is true in the common case. I'm more concerned with someone distributing an autopackage file that isn't really an autopackage file.

Obviously the package scripts would not be in charge of verifying their own authenticity, that'd be a dumb design. The launcher application which is associated with .package files would do that, and only pass control to the package itself once verified. That's no different to RPMs which can contain arbitrary scriptlets.

The launcher application is the .package file itself: instructions to install an autopackage file are to set it executable and then run it. That process includes no sanity checks whatsoever.

RPM provides no security. They must always be run as root, and can run any program or software they like, at root privileges. There is no functional difference between an RPM and an executable binary: they can both do whatever they like

Rpm may be invoked with the "--noscripts" option. Most normal packages should install just fine this way. Rpm may not be perfectly secure in the sense that a bad package might install malware, but at least you can verify what it did install (if you use --noscripts), and rpm makes sure it doesn't clobber the files of an existing package. Also, rpm will check that the package is cryptographically signed by a trusted source.

Autopackage has at least four different mechanisms for dealing with dependencies, including static linking, bundle linking, weak linking and a dependency resolver, why don't you read up on it instead of bashing it? All of your issues are covered in the FAQ.

Ok, so if it isn't installed and isn't part of the current package, it'll grab another package from somewhere else. Or something. Where it gets the package from is not explained in the faq, but I'll assume it can download it from some repository like yum.

Autopackages aren't really ad-hoc installers, they're actually a hybrid of RPM style packages and wizard-style installers, combining the best elements of both. They understand dependencies, are low overhead, are built from specfiles and have a consistent and integrated user interface. Nonetheless, (when done well) they are easy to use and look professional. I fail to see how this is a step backwards given the reality that not everybody uses the same distribution.

It's a step backwards because it gives users a gun with which to shoot themselves in the foot. The main problem I see is that the .package files are executable. Regardless of how well autopackage works, sooner or later, some user is going to download a .package file and execute it and it won't be a real .package file, it'll be malware. I don't think rpm is a perfect system either, but it will at least do some reasonable sanity checks before installing anything.

The design of autopackage may be quite good, but I think that if you take away the "feature" that it doesn't require any pre-existing package management system (which I don't see as a feature at all), it doesn't do much that rpm can't do, and it doesn't do a lot of the things that rpm and yum can do, such as auto-update and package signature verification.

I realize that not everyone is going to agree with me on this, but I think autopackage sacrifices too much security in the name of convenience.

I absolutely agree. I'm fine with building stuff from source, but most of my friends aren't.

'yum' helps a lot, for those things which are available on yum. I understand that Fedora Core 4 has a graphical yum client, which would work well for the people I have in mind, if the UI is reasonable, and adding archives intuitive.

There are a few other projects trying to solve the other problems - distribution independent packageing: http://autopackage.org/ and http://zero-install.sourceforge.net/
but they're not there yet.

For projects that use it, one click installs do exist on Linux, via the autopackage installer. And they are actually one click too (well, OK, two clicks) because there's no Next->Next->Next style wizards involved. Why not watch the Flash demo to get a feel for how it works (it's a bit out of date now, things are slightly slicker these days).

One of the biggest problems autopackage has is simply that developers don't know about it. Whereas every Linux developer has heard of RPM, virtually none have heard of autopackage because it's so new (it only went stable in April).

If you like what you see there, spread the word or even better, write patches! The best kind of product is the one that sells itself, after all, and whilst autopackage is already quite nice for the end user we're still busy untangling the ball of wool that software distribution on Linux has become.

For projects that use it, one click installs do exist on Linux, via the autopackage installer. And they are actually one click too (well, OK, two clicks) because there's no Next->Next->Next style wizards involved. Why not watch the Flash demo to get a feel for how it works (it's a bit out of date now, things are slightly slicker these days).

One of the biggest problems autopackage has is simply that developers don't know about it. Whereas every Linux developer has heard of RPM, virtually none have heard of autopackage because it's so new (it only went stable in April).

If you like what you see there, spread the word or even better, write patches! The best kind of product is the one that sells itself, after all, and whilst autopackage is already quite nice for the end user we're still busy untangling the ball of wool that software distribution on Linux has become.

I've found programs packaged using Autopackage to install pretty nicely on my Gentoo box [which surely has to be one of the more diverse Linux environments].

Perhaps we, as a community, just need to be more vocal in our support for a common standard that embraces all distributions like Autopackage, or OpenPKG, or the other cross-distro install options out there.

Depending on the distribution you have, downloading/installing software isn't really difficult, it's just different. These differences are what can be confusing for an end user. Eventually there may be more applications packaged with something like Autopackage http://autopackage.org/ that would help ease the confusion somewhat for new users. Odds are it's not that the solutions aren't there, it's just finding and using them.

I will hasten to add: "And the fact that for easy software installation, one is *always* tied to a particular vendor..." This makes matters worse.

Imagine this: You are told that the best video editing software for Linux is package ABC. You google it and find thousands of entries. You go for one and find that it will not even install because you're on an rpm based distro and the software is a .deb package!

You go for an rpm package you grab and realise that it's the wrong version. To make matters worse, it's for a different distro. What we need to do for Linux is to adopt autopackage http://autopackage.org/.No one will be encouraged by flames or the so called rpm hell. To me, it looks simple but for many, the decision to adopt autopackage is a non-starter.

To make matters worse, many editors and pundits do not even see autopackage as a viable option and Debian which I use (but is not perfect though good), dismissed it all together!

1. The packaging system is user-unfriendly.

It's actually pretty good at what it is - a means to package a diverse system that can be tailored to the user. Things like Smart (a Conectiva/Mandriva project even) and Autopackage help a lot. To get the packaging systems you want you need to fix #4, and I don't think that's likely to happen (at least not successfully).

2. The locations of programs are user-unfriendly.

Really? Any program that actually supports the freedesktop.org desktop entry file is readily accessible to the user unless they use some WM or DE that doesn't bother to use them - which means they've gone out of their way to complicate their lives. As for where the programs are stored on disk ... well, that doesn't really matter does it? You want a searchable tag/label based system, so why not consider the package database as such a label view - you can see all the programs on your system with ease through the "package label" view of your filesystem, does the physical location really matter that much to you?

3. The folder layout of Linux systems is user-unfriendly.

To some extent I agree, but we're dealing with legacy here... even OS X and windows have some odd folder locations and names carried over. Besides, there's always GoboLinux, which I presume you already know about.

4. The lack of a standard base of installed libraries is application (and thus user) unfriendly.

This is the big one really. If you want a fixed mandated core set of libraries that the user is forced to install... well, grab yourself a nice mandated controlled system like OS X, because Linux probably isn't what you're looking for. In theory you could just set up a distribution that has such a guaranteed base set of libraries, and in a sense some already exist - try Linspire, or Xandros. The catch is that people write applications for "Linux" not "Debian, stable" or "Linspire 3.1" or whatever. Given a random open source application it will make whatever assumptions about libraries it cares to - it's up to the packages to make sure those dependencies are met. FOSS applications tend to be coded against "whatever system the developer cared to use" rather than specific distributions and versions. Commercial developers maybe? Well they do have requirements - Oracle requires particular versions of Redhat in standard installs. Other commercial developers can do that if they like. Alternatively they could accept that the Linux world is a diverse world and restricting yourself to the one distribution that is guaranteed to have everything you want where you want it is a little limiting. You can always use Autopackage and handle the dependency issue elegantly in a way that's effectively invisible to the user.

The fact is that different distributions are different. You seem to be asking for all (or most) of the distributions to agree on a firm fixed set of base libraries. Distributions are different competing companies often however - you may as well ask Apple and Microsoft to hammer out a combined base set of libraries that you can be guaranteed to get in both OS X and Windows. Maybe that's a good idea. Maybe CoreImage on Windows and DirectX on OS X is what you'd like to see. I'm not so sure it will happen though.

Jedidiah.

My other trouble is in trying to find a package for my distro. Many times, you find a package not built for your distro in the `rpm' format. When you do a `rpm -ivh package-name.rpm --force' you have to be lucky if it works.

Last but not least, 2 points:

1: All Linux distros I have tried feel somewhat heavy - not snappy! Even when I remove all packages that are "server" related , nothing seems to change.

2: I keep wondering why distros do not adopt the promising autopackge system http://autopackage.org/. We must remember that in order to attract users to our Linux system, installations and maintenance of systems MUST be easy and seen to be so. Otherwise, the situation we have now is a pipe dream. Windows still beats us here hands down.

Admittedly I'm a reluctant user of OSX, having to use it at work from time to time and haven't spend more than a couple of weeks working with it. From the outset, a useability deficit was immediately apparent; OSX still hasn't provided a means of finding software and delivering it to the user.

How depressing it was to find that Apple users are still stuck with the oldest problem in software installation, and that is finding the software first. Windows users considering switching will find this to be as depressing as it was on win32, and similarly we hear Mac users that have moved to Linux cheer endlessly about the ease of software installation using a system such as apt.

So boring it is to spend countless hours trawling around websites looking for software, and there's so little on the machine out-of-the-box. OSX really doesn't push much further than the windows paradigm in this regard. There's this fink but last time I tried it was all a bit hacky and suffered issues worse than those in any Linux distribution I've used.

In short, nothing I've tried comes close to software installation in Linux; Linux brings the software to me.

Where the *.dmg is concerned, while convenient (once you have actually found the bloody thing), it is certainly not unique to the Apple platform. Linux already has two perfectly good solutions to this would-be problem.

One is http://autopackage.org/, and a completely different approach (and quite impressive) is Klik http://klik.atekon.de/.

Then again last time I looked searching for a package and clicking the conspicously named "Install" button in Kpackage or Synaptic seems to suit vast numbers of lazy, or just plain busy Linux users out there.

The beauty of Autopackage is, as a developer, I can make one package for all distributions of Linux. With Klik, I only 'install' the software for that session (in fact it is run from cache).

True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.

And that's a very lovely idea and will make for very easy packag installation. It is not something you'll ever get on FOSS Linux however. The FOSS software community improves it software in an evolutionary sort of way - you get a whole lot of different versions of basic libraries and tools, and eventually you get some consensus on them. The key is that the whole system can be overturned - perhaps E17 will turn out to be truly amazing and a shift will occur, perhaps Y-Windows will get completed and turn out to be well worth pursuing... the point is that these decisions are made not by corporate management, but simply by what manages to get the most hackers interested in and coding for/with it.

What I'm really trying to say is that FOSS is utterly chaotic, but draws strength from those chaotic qualities. What you're talking about is eliminating some of that chaos - and I think there's certainly merit in that idea, I just don't think it will mix well with FOSS. If you want a organised mandated structured set of required libraries and APIs use Apple (or start your own OS). If you want the masses of software and vitality of the FOSS world, you have to accept a certain amount of chaos in return. What we need is better mays of managing that chaos: I don't think we can eliminate it.

Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.

But things are getting better. Check out Smart a new dependency resolver with far better algorithms than apt (along with more flexibility at the backend package level). As I said, I don't think you can eliminate the chaos, but you can do a lot better job of dealing with it.

Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.

And that's where things like Autopackage come in. As long as your base libraries are managed by something like Smart, then Autopackage is fine for those 3rd party extras - it will use the libraries if you have them, but it can grab whatever else it needs if you don't.

Don't fight FOSS's strengths, instead figure out how best to cope with the weaknesses that are the flipside of the strengths.

Jedidiah.

Is there any chance of Debian adopting autopackage http://autopackage.org/? I wish they did because though it (autopackage) might have its quirks, the best implementation to package manegement will not necessarily help in World domination. I undertsnd that M$ also is relevant here.

Let's see. On MacOS X you sometimes also need to install software by running installers, some using the Apple installer framework and others using, eg, Wise. If you want access to the world of free (as in beer) software you get with Linux you may also need fink.

On Linux you can use something like Synaptic in Ubuntu, or even better when it's available an autopackage. this is even more straightforward than the .dmg: just click the link in the web browser (1), click "Continue" at the "You are about to install" screen (2), click "Close" in the summary window at the end (3). The app is now in your menus and ready to use.

You could even argue this - when it exists - is easier than the Mac, because it's a very common newbie mistake for people to open up the self-mounting DMGs and run the program directly from there. If they like it they then drag it directly into the dock - which is, let's face it, what intuitively makes sense - and then can't figure out why clicking the dock icon pops up a Finder window. Nor can they figure out why the icon stops working once they clean up their desktop a bit.

Now it's true that on MacOS X it's still a lot easier to graphically install software most of the time as long as you understand the (undocumented) conventions because it has a head start on easy packaging. But hopefully as autopackage gathers momentum more and more software will be available in this form. Already programs like Gaim and Abiword are. So while there's a lot of work left one of the last bastions of UNIX geekery is slowly starting to fall.

None the less, Novell has taken some "right" steps by for example releasing YaST and other software as GPL and supporting Mono.

I suggest Novell provides hobbyist SuSE ISOs and probably starts shipping them like Ubuntu is doing. I also think adopting autopackage http://autopackage.org/ would do no harm to them.

Guys, autopackage http://autopackage.org/ or something like it, is the key in software installation in my view. I feel so bad when I see some "Linux specialists" dismiss it as a non starter, yet to Joe SixPack, it does not matter. Linux will be no where even in a generation if it requires software authors to write n packages for n distros. When one visits Nomachine http://nomachine.com/, you find a single windows binary and several Linux binaries, and that does not guarantee successful installation on all distros. Such a situation is very very frustrating. Guys, let's jump onto autopackage and let Linux fly.

Klik http://klik.atekon.de/

Or Iris from the now defunct Lycoris?

Or perhaps like the Linspire ClickNRun Warehouse http://clicknrun.com/

or perhaps you mean like Damn Small Linux's Click and Load Desktop http://distro.ibiblio.org/pub/linux/distributions/ damnsmall/mydsl/apps/

Or do you mean an Installer like Windows Installers - well they have that too http://autopackage.org/ for instance.

Not to mention Synaptic, K-Package, Yumi, and there are more graphic frontends to Yum and Apt where all you have to do is set the repositories and then just click the program for install and let it go and do its work.

DUDE WTF!!! How much easier can it get than browse to page of the app, read a description and perhaps look at a screenshot- then click it and it installs and configures itself. You don't get any more hand-holding than that.

Perhaps you haven't used a Linux in a while or perhaps you are a paid shill- Either way you seem to not know the current lay of things.

Although DRM is bad!!! What MS is trying to do here goes beyond evil... No more used computer market, no more switching oses, No more running "untrusted"(Read FOSS/Non-MS) apps, uhmm... pretty much MS wants to trun your machine into a pile of crap.

This should be obvious, really. How do you define what makes software trustworthy? How do you define "bad things"? What about software that falls into a gray area? Who gets to impose their moral and ethical values onto others? The best code signing can do is let you take the owners of the cert to court.

This stuff is discussed more in the autopackage FAQ because for some reason people tend to associate "easy to install software" with "will get spyware" even though there's no evidence of that.

Code signing can be useful, but it proves very specific things: for instance, that a mirror hasn't been cracked, or that a particular file was produced by somebody with a trackable real world identity (so they can be taken to court if they're really doing something wrong). It certainly isn't a magic cure-all to the problem of malware.

Somebody above said that you could use SELinux to sandbox programs so you can be sure they won't do bad things. This isn't really correct. While programs can certainly be sandboxed to some extent - after all, that's what root vs user does - you can't expect users to set individual permissions on a per app basis. After all, the GIMP may not look like it requires the ability to initiate network connections, but what if you use GNOME-VFS and type a URL into the open dialog box? What if you, the admin who sandboxes the app, never use that feature and don't consider it but one of your users does?

Sandboxing, like code signing, is a useful technique but it isn't a real "solution" to malware either. I'm not really sure what the solution actually is. Perhaps there isn't one, just as there's no single solution for real world disease either. I'm sure of one thing though - if there is a solution, TCPA certainly isn't it.

Sir, I think you might like a Mac. :)

I'm just playing with yah. Yeah, I feel your pain on the occasional difficulties. I'd have to say though, I don't think there are 3000 distros. I think there are 10 real ones, the rest are bizarro projects with varying degrees of popularity.

The good thing is, people have made some serious strides towards making the major ones play nice. I think we're on the cusp of a serious breakthrough where a good number of the major distros will be virtually indistinguishable from each other, at least to the novice user. Maybe I'm just optimistic.

If you haven't already seen it, take a look at autopackage, as an example.

The solutions are out there. Let's just get people start using them.

It's a way to stop programs needing to distribute a redhat rpm and a suse rpm and a mandrake rpm and a debian deb and so on, instead you just make a lsb rpm which works on any lsb distro.

I believe that Autopackage doesn't need a LSB to work properly.

Most other OSes generally don't let foreign programs run willy-nilly and do things behind users' backs.

Of course, there are many spyware programs that make their way into users' computers through holes in IE/DCOM/SMB/ActiveX/what have you, but the fact of the matter is that the majority of spyware comes with other programs, like Kazaa. That means that the user is willfully installing it. Sure, they may not know about it, but that doesn't mean they're not installing it by their own decision. There's nothing in any other OS that would prevent the user from doing that.

The reason why there's no spyware on Linux is not primarily that Linux isn't yet as popular as Windows, as many others suggest. The reason why there's no spyware on Linux (yet) is that most people run free software on their Linux systems, and free software developers... well, don't normally bundle spyware with their programs. If or when proprietary software ever gets popular with Linux, I'll assure you that you'll see an increase in spyware for Linux.

However, mind you that there's nothing inherent in Linux itself to stop it. Any such thing would just prevent the user from doing stuff, and would therefore be hindering users.

Autopackage has a lot of text on this.

What I think both Debian and Ubuntu should do is forget about their huge package repositories, on the grounds that it's an unscalable way to distribute software and focus purely on making a great OS. That means things like UTF8, graphical installers, graphical config tools, SELinux integration.

These are all being worked on. But see how Fedora was ahead of them in all of these areas, and in some still is. That's because the Red Hat team focussed purely on the base distro instead of trying to package everything in the world, which is impossible.

Now, Ubuntu basically has a chance to do this. Strip even more out of main - why is Inkscape there? How many Ubuntu users are also vector graphics artists? It's out of date already, and has been for months, yet you can get up to date packages direct from inkscape.org. Take it to the logical conclusion: make Ubuntu a base operating system that is super easy to extend, with only the basics in main (music player, web browser etc).

Now support 3rd party packaging, so users can go to inkscape.org if they want a graphical editor and install it straight from there. I think they should use autopackage to do that, but I'm biased. There could be any number of ways of doing it. The point is, stop being packagers and become OS developers.

Ubuntu could do this without too much pain. Debian, on the other hand, never could. When you think of Debian, do you think of a slick, modern desktop OS? No? Neither do I. I think of 18,000 packages. But who cares how many packages you have, if the OS sucks. If Debian were to deprecate most of the packages, it would cease to have a purpose on the desktop because it's such a poor desktop OS (as Ubuntu has made clear). It could refocus and with time, catch up, but it would take a lot of effort and dedication and belief in the new way. I don't think Debian can do that. I think it'll fade away rather than change.

Attempting to package everything the user wants is sinking Debian, and it'll sink Ubuntu too unless they change the philosophy instead of just doing minor tweaks. Ubuntu universe includes Coq, a theorem prover whos own authors estimate that it has only 100 regular users, yet does not include gaim-vv, which adds webcam support to Gaim. What is wrong here?

Use AutoPackage and all will be well.

Or maybe not.

You may be interested in relaytool. See http://autopackage.org/ for info.

See post above...

Here's the problem... The open-source/free-software movement is similar to an organic evolution/adaptation system, while the proprietary software industry is just that, like industrial/factory systems. Because of the factory like mechanics, proprietary software is easy to package and pump out. Open source goes in all different directions and it's an electronic survival of the fittest. If someone comes out with a better piece of software, people will tend to use it instead. If someone comes out with a better distro or packaging system, it's the same thing. Only thing is... since it all goes in a million different directions, there are alot of "extinct species" along the way. This is our trade-off for the freedom vs. convenience. However, if we can find a way to get the best of both worlds (LSB, FreeDesktop.org, Autopackage, and other open standards)....things could really get exciting.

who mentioned about forcing people to do anything? Most projects supply their files in several different formats so that people can make a choice as to what kind of install they want to do. I dont really care what you think, because if you are truly honest with yourself, you will admit that installing software on linux is a pain in the arse sometimes - even for seasoned users. Giving joe sixpack a foolproof click-through self-installer for linux is not just a good idea its a requirement. Especially as it continues to make headroads on the desktop.

I use Gentoo and Vidalinux by the way. The portage system is pretty good and dependancy issues are pretty much a thing of the past although annoyingly i still have problems. Im lucky enough to have a fairly beefy SMP computer so most of the time i dont have to wait too long for compiles.

Having said all that Autopackage is the best thing ive seen as an installation method yet. Have you actually tried to use it yet ?

Make sure you read the instructions first. You dont even need to go anywhere near a shell prompt!

4 steps to installing an autopackage...

http://www.autopackage.org

Those packages could just as easily be placed in a repository and could be downloaded all at once by an automated facility supplied by the distro.

The autopackaging system is working in the opposite direction of a centralized repository. See here.

You could also read the concept being put forward for upgrades and security updates.

There's nothing wrong with having a standardized package format. (With programs like "alien" we essentially already have this.) But the real meat is in how you deal with dependencies across systems, and with distribution of upgrades and security updates.

Those packages could just as easily be placed in a repository and could be downloaded all at once by an automated facility supplied by the distro.

The autopackaging system is working in the opposite direction of a centralized repository. See here.

You could also read the concept being put forward for upgrades and security updates.

There's nothing wrong with having a standardized package format. (With programs like "alien" we essentially already have this.) But the real meat is in how you deal with dependencies across systems, and with distribution of upgrades and security updates.

Those packages could just as easily be placed in a repository and could be downloaded all at once by an automated facility supplied by the distro.

The autopackaging system is working in the opposite direction of a centralized repository. See here.

You could also read the concept being put forward for upgrades and security updates.

There's nothing wrong with having a standardized package format. (With programs like "alien" we essentially already have this.) But the real meat is in how you deal with dependencies across systems, and with distribution of upgrades and security updates.

Funny , I just downloaded the package file for inkscape, set it to executable and launched the file from KDE. It really couldnt have been simpler (cept the changing the ".package" file to executable maybe a bit difficult for new users to grasp.) -you perhaps?

The package files contain everything you need to install the file. If it is the first time you use. an auto-packaged file you may find that you are asked to download a couple of support files "automatically" . I dont see why you needed to download those files in order to begin the install process. the only manual download you need to do is the package file itself. Unless of course you failed to read the bullet point guide and tried to install without setting the package as an executable. In which case there really is no hope for you.

Just in case you missed it and for the benefit of anyone else. Its a good idea to read this if you want to test them out.

4 step guide

I tested this on gentoo and im impressed so far. It just remains to be seen if this rises in popularity and how easily it breaks (im nursing gentoo out of a fix right now!). I beleive that this is a good thing and something that is needed by linux. The various packaging systems are great for specific distros. But are largely incompatible with each other. While this is great for open source projects and developers its also something i would like to see some of the proprietary providers utilise. It would be great if things like acrobat reader and flash-plugin and those other essentials were to use this system. All too many times I've found myself trying to install stuff that i couldnt build from source - or only came in an RPM or DEB. This could help change a lot of problems for new and seasoned linux users alike.

Lets face it - it doesnt matter what flavor linux you use how is joe sixpack supposed to know whether he wants an ebuild, deb or rpm. Let alone know what to do with a ".tar.gz"?

Everybody loves screenshots, and we're no exception, so here we are! Enjoy...

Flash movie demo
2.7 Mb flash demo of an install session

Commandline frontend: [Screenshot]

GTK+ frontend: [Screenshot]

QT frontend: [Screenshot]

QT Manager: [Screenshot]

GTK+ Manager: [Screenshot]

There are some older screenshots here.

Everybody loves screenshots, and we're no exception, so here we are! Enjoy...

Flash movie demo
2.7 Mb flash demo of an install session

Commandline frontend: [Screenshot]

GTK+ frontend: [Screenshot]

QT frontend: [Screenshot]

QT Manager: [Screenshot]

GTK+ Manager: [Screenshot]

There are some older screenshots here.

No doubt lots of people will have all kinds of questions about autopackage, such as:
- "What idiots!! Another packaging format is the last thing we need!"
- "What's wrong with apt-get?"
- "Everybody should use Gentoo!"

Slashdotters are highly encouraged to read the autopackage FAQ! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.

If you have more questions, feel free to come over at #autopackage at irc.freenode.net
We'll be glad to answer your questions

Really? Mine worked fine with just installing right over 1.0.1 with Windows XP. Under Linux...no go (of course).
However, Autopackage works great (if you've have FF installed from Autopackage): http://www.wildgardenseed.com/Taj/autopackage/fire fox-1.0.2.x86.package
(BTW, if you do try this Autopackage, we'd love some feedback on how it works--taj at wildgardenseed dot com).

If this happened, there would be no Ubuntu. There would be no Mepis. There would be no Knoppix. All the Debian derviatives exist solely because of the monolithic Debian package repository. Sure, Ubuntu has its own repositories but they all come from Debian unstable.

That's not true. The thing that makes Ubuntu great as a desktop and Debian lame is all the work that has gone into the core OS part, not the packages. The Ubuntu universe is riddled with uninstallable software, and main ships with out of date software too (eg, Inkscape).

Furthermore, to me, it doesn't seem like that is what the Debian project is about. Debian provides all the free software that runs on Linux and is worthwhile to package.

It quite clearly does not, at least not by my definition of "worthwhile". What about all the commercial games out there? I guess they're not worthwhile packaging because they aren't free enough. What about up to date Wine packages? I guess it's not worthwhile packaging that, so upstream has to do it instead. Even if you take a massive leap of faith and claim that Debian is able to package everything anybody might ever want, it still has big problems with freshness even in unstable.

They also ensure that it is possible to run a computer on free software. Without the central repository, that goal couldn't be accomplished.

I don't see that logic. Having software pre-filtered means you don't "accidentally" get un-free software, however not everybody shares the same definition of free. See the ridiculous discussion over the Xorg "nv" driver on debian-legal for a good example of that. You can still run a computer using only free software if you want, you just have to not install non-free software. Assuming the core OS is free, that's not hard at all. That has the advantage that for the majority of software you can make up your own mind about what is free or non-free, instead of having Debian choose for you.

These developers would move on to the develop for the third party repositories, but those would be far less useful than Debian's repository and cause massive duplication of effort.

I don't see that logic either. Third party packages (not repositories) would be provided by upstream projects like on Windows or MacOS. Those packages would work for anybody, using a technology like autopackage. Therefore their utility is hugely increased, and duplication is decreased, because the software need only be packaged once for all Linux users.

Plus, you state that Debian's main strength is its packages, but you want to take those away? Sure, there would be quick releases, but the released product it self would be much less useful than Debian is now.

No, Debian would just have to focus on writing a great OS instead of packaging as much stuff as possible. So that means things like, a graphical installer, slick integrated desktop, nice config tools etc etc.

Debian has problems, but the massive overhauls people are proposing are completely unnecessary. Right now, there is a Debian for everyone.

That clearly isn't true otherwise the candidates would not be claiming that Debian users are "leaving for greener pastures" and Ubuntu would not have appeared out of nowhere with a vibrant community almost overnight (guess where they mostly came from ...)

Then, they should work to standardize on http://www.autopackage.org/, or something very similar to it.

Actually, NetBSD's package system would be a better choice since it's portable everywhere. A colleague of mine has systems running Solaris, NetBSD, OpenBSD, FreeBSD, RedHat Linux, etc. They don't want to have to deal with building separate packages for each *NIX variant, so they're using NetBSD's system instead of the native package systems.

If Sun wanted to make themselves insanely relevant very quickly, they would fully embrace Debian and support it extremely well. Then, they should work to standardize on http://www.autopackage.org/ [autopackage.org], or something very similar to it. Then, they should work to get Java much better integrated into Firefox and vice versa. Here is a good article on it the level of integration between the JVM and the browser, which is just pathetic at the moment:


Relavent to who exactly ?

Alex

Well, JPackage is interesting, but it's still a centralized repository. Look at the faq here:

http://www.autopackage.org/faq.html#2_1

Basically, centralized repositories (apt-style) do not give each publisher/software house the ability to control *their own distribution*. That, in my estimation, is the #1 reason why more companies don't distribute software packages. Sure, there's an issue of non-standard toolkits, etc, but the first obstacle to standardizing anything is the install. Autopackage provides the possibility of a single way to install AND uninstall applications on every Linux distribution. That's why it's important.

Sun should support this on Solaris, and distribute all of the software from the projects they underwrite (OpenOffice.org) so to help get things going.

Take some time to read through the entire site. I think it's the most important thing necessary for Linux right now. If I, with over ten years of experience using Linux, absolutely loathe installing applications and find it completely unnecessarily difficult, imagine how new and inexperienced users feel!

That is all off-topic, but Sun is still in some kind of trouble. There are so many things they could do with Java, but they aren't, so this is why the calls to open source are intensifying. They should let it go and see what happens, then pull in all the popular innovations back into the "standard" java platform. They have the ability, but I think they're missing the leadership to do it.

The final thing is that their overall concept of end-user experience basically sucks hard. One example is Java Web Start. While it's a really great idea, it's so awful from the experience of a user, that I refuse to use it. Another prime example is the default look of Java (not to mention the Java desktop). It looks nothing short of pixel vomit. Sure, some people create amazing applications with it, but unfortunately, most applications aren't going to stray much from the default. The result is a perception that Java apps look like trash. If JGoodies, for example, is necessary to get a decent look out of a java app, then why doesn't Sun support that? It's free (as in BSD free), so WTF? Instead they ship this bluish look with the same ugly icons. I almost fell out of my seat when I saw the new look and feel for Java 1.5. Perhaps slightly better than the defualt, but still FUGLY.

Then, they should work to standardize on http://www.autopackage.org/ [autopackage.org], or something very similar to it.

JPackage perhaps? :-)

There is also a popular request for enhancement hereurging sun to make the Java RPM play better in Linux, i.e. respecting the filesystem standards for where to place documentation etc.

I doubt that GCJ is going to take over on Linux though. Not that they aren't doing FANTASTIC work, but there is still lots of catching up to do and Java is a moving target.

Sun is in trouble because GCJ is getting so much better. It has a strong chance of becoming the "defacto" version on Linux very soon. RedHat engineers already have Eclipse built and running on it, and tightly integrated with Gnome and Glade development. It's starting to look really nice, and SWT compiles natively into Linux binaries. Sun will likely maintain the lead on Windows pretty easily, but they stand a big chance to lose out to GCJ on Linux. No biggie, because Linux isn't a real server platform after all, right Sun? ;)

If Sun wanted to make themselves insanely relevant very quickly, they would fully embrace Debian and support it extremely well. Then, they should work to standardize on http://www.autopackage.org/, or something very similar to it. Then, they should work to get Java much better integrated into Firefox and vice versa. Here is a good article on it the level of integration between the JVM and the browser, which is just pathetic at the moment:

http://www.softwarereality.com/soapbox/swing.jsp

I wish there were a sane event model to share between Java and the Browser so that I could use the browser as a display technology and have access to all of the Java class libraries for networking and such.

Autopackage linkage. Sorry.

This is why more people need to get involved in projects like the Linux Standard Base. If more distros would quit trying to do their own thing and work together, Linux might be able to really take off. Autopackage will help people with installation hell between distros. And hopefully, freedesktop.org's new set of UI standards will help KDE and Gnome people get along a little better too....but then again, we are talking about human beings here.

i was thinking about a package format (say, zip) which contains the sources and an install script which can install said sources on any linux desktop. i am not sure what the problem is with that.

Dependencies. If you're compiling from source you're often resolving dependencies in the ./configure step as well. Don't worry CMake has the same issues. Perhaps you should just look at Autopackage instead.