Zero Install: The Future of Linux on the Desktop?

SiegeX writes "Zero Install ,which is apart of the ROX desktop environment is not just a new packaging system, it's a whole new way of thinking; a way that I believe is exactly what Linux needs to become a serious contender for Joe User's desktop. Zero Install uses an NFS to both run *and* install apps from. The apps are all self-contained in their own directory; binaries, docs, source code and all. Once the app has been downloaded its kept in a cache from that point on to minimize delay. The beauty becomes apparent when Zero Install is combined with ROX which runs the application by just clicking on the directory it was installed to. Deleting the application along with all the other misc files is as simple as removing the directory it's contained in. This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial. This is something even the greatest of technophobes could understand and use with ease."

Comments

Someone should tell Apple

[SeanTobin]

Someone should really point this out to Steve. I think using this type on installation on Macs would increase useability by leaps and bounds.

Re:Someone should tell Apple

[neutralstone]

Hear hear (though I'm sure their UI people are already aware of it---ZI has been in development for a while now). Certainly commercial app developers should like it because it gives the user a very easy way to try the "trial version". This would lead to more trials, presumably meaning more sales. It goes without saying that Free Software people should like it just from a usability standpoint.

The only way it could *suck* is if Microsoft is the first company to use it in a big way.

Re:Someone should tell Apple

[hak1du]

Yes, someone should indeed point that out to Steve Jobs. Many Mac applications these days come with installers that drop bits all over the file system, and many of those don't come with clean uninstallers, making the problem worse.

Re:Someone should tell Apple

[Daniel Dvorkin]

[snicker]

Seriously, as an Apple user, I'm glad to see a Linux desktop system copying the MacOS instead of Windows. I've felt for some time that it is a huge mistake for KDE and GNOME to try so hard to make themselves look like Windows when, in OS X, there is a much better example of a Unix-based desktop. Why waste your time copying less than the best?

Yeah, yeah, user familiarity, etc. Look, folks, I guarantee you that if all you've ever used is Windows, if you sit down at a good OS X machine, it will take you about half an hour to get used to the differences and be up to speed -- and after that you'll be discovering new and better ways to do things and saying, "That's so cool! Why didn't Microsoft ever think of that?" If a Linux desktop can have some nifty non-Windows features too (and I really don't care if the developers rip them off from Apple or come up with them on their own) it will do a lot more to enhance Linux desktop growth than just coming up with a system that's "like Windows, only not exactly."

Next response I anticipate: "Yeah, well, if Mac OS X is so much better, how come it hasn't beat Windows in the marketplace?" The answer, of course, is that there is a lot of mindless anti-Apple prejudice, and regrettably I don't expect that to change any time soon. But anti-Linux prejudice is much milder, I think. A good Linux desktop with Mac OS X's best features (and maybe some of its own) especially if it were backed by IBM, could be the best shot at breaking the Windows stranglehold on the corporate desktop.

Re:Someone should tell Apple

[Shados]

The anti-apple prejudices will go away, but it will take time... For a lot of us, Mac OS 9 was really awful...yet from the little I had the chance to play with OS X(not that much...but chances if I spent more time it would get better), I was delightfully impressed...and if I had money Id get a Mac right here right now. its the kind of same thing that happened with Windows, from Win9x to WinNT5+...it doesnt crash that much anymore, but its still suffering from the bad experiences of the old days... Mac's reputation will recover, probably faster...

Re:Someone should tell Apple

[bryhhh]

Risc OS has used this approach since the mid/late 1980's when the OS was launched on the Acorn Archimedes.

The only shared libraries are the ones built into the OS. (The OS was on ROM, so version incompatibilties didn't really exist like they would with the disk based OS's we use today).

Their where special files placed in each directory (!boot and !run)

!boot was executed when the filemanager loaded the directory and was responsible for replacing the applications default 'dir' icon with one that represented the application function.

!run was executed when the user launched the program by double clicking on the folder.

It was possible to open the directory rather than execute the application, IIRC a shift key was used in conjunction with a mouse click.

Disclaimer: It's about 15 years since I used the above system, so details may be inaccurate.

Re:Someone should tell Apple

[Cthefuture]

Look, folks, I guarantee you that if all you've ever used is Windows, if you sit down at a good OS X machine, it will take you about half an hour to get used to the differences and be up to speed

True.

and after that you'll be discovering new and better ways to do things and saying, "That's so cool! Why didn't Microsoft ever think of that?"

Uh, I had the opposite response. "Why in the f*&k did they do it that way?!" Keyboard control is practically nonexistant. And Finder blows... Damn I hate the way it works. It doesn't allow to see where you are in the filesystem very well. It's just awkward and slow to use.

The killer feature Apple has is that they have a GUI for everything in the system and it hides a lot of complex stuff so the end-user doesn't have to worry about every little detail (of course sometimes that backfires when I simply can't do something because it's hiding the details).

Back on topic...

I've found ROX is very similar to Finder. I hate it also.

The ROX "all in one directory" is the exact same concept as Apple bundles. I can't believe how many people don't even know what they are. I guess that's what happens when you hide all the details. Anyway, the bundle concept is pretty cool. Just copy/move a directory to install your application.

Re:Someone should tell Apple

[Daniel Dvorkin]

I really hope you're right, and I'm glad to hear that you're so impressed with OS X. The reason I'm gloomy about the anti-Apple prejudice going away is that honestly, I can't remember a time when the Mac OS wasn't better than the comparable Windows version available at the time. Yeah, OS 9 sucked, but Windows ME sucked ever so much harder, and with teeth. OS 8 was mediocre, but it was competing against Windows 98, for God's sake! System 7 was quite good, albeit rather bare-bones by modern standards -- but compared to Windows 3.1 and 95, it was a thing of beauty and a joy forever. (I think I have the timelines right; apologies if I'm forgetting something.) Etc.

And yet at every point in this history, the Mac was struggling against the dual prejudice of "M4XZ 5UX0RZ" from the script-kiddie brigade (and don't underestimate these people; even now, I suspect that Aunt Tillie is likely to go to her 17-year-old nephew for computer buying advice) and "Apple makes toys" from the suits. And even now, that the Mac OS has an industrial-strength Unix base and the hardware actually offers better price/performance than any comparable brand-name PC at all but the lowest of the low end, you still hear variants of these tired old prejudices trotted out every day.

My advice for the Linux desktop developers is: please, please, rip off everything you can from the OS X desktop. But don't never admit to anyone where you got the idea. We Apple geeks will know regardless, and sit back in our half-bitter, half-proud glory. We've got plenty of practice. [1/2 g]

Re:Someone should tell Apple

[edalytical]

Or if you're like me and suffered through Windows 98 for years, you don't what to use anything remotely similar Windows.

I think Linux would win a lot more converts if KDE and GNOME where less like Windows. Especially in regards to Lindows, I think it will eventually end up making Linux a generic Window in the eyes of potential users. Just go into any $1 or less store and you'll see what I mean, a great deal of the packaging resembles name brand packaging found in grocery stores. Sure you might get some loyal users just looking for a cheap replacement. But most users when given the choice are going to go with the name brand stuff.

Re:Someone should tell Apple

[mdwh2]

Since everyone seems to be giving examples of earlier systems which install in this way, I should add that this is usual on the Amiga too.

Application specific files and user preferences all live in the program's directory. However, 3rd party libraries and so on tend to be stored in the system folders, which IMO gives the best of both worlds - applications can share common code, but application specific code and data are easily removed, and not strewn about all over the place (libraries tend to be small on the Amiga, so the fact that you might acquire libraries over time that aren't being used by any installed applications isn't that great a problem, and anyway there is probably more bloat in having multiple copies of a library).

Re:Someone should tell Apple

[w3weasel]

Apple has already implemented this archetecture... albeit without the nfs... but since ftp servers mount as any remote disk would (in 10.3) the nfs is pretty much there too.
all the various bits and pieces of a well formed Mac app go into a 'package' (not RPM). See it here. a double-click on that folder launches the app, deleting the folder removes the app, and updates need only to replace affected files within the app.

When developers take the time to use this structure, it works really really well. Unfortunately, Apple is not in a position to tell developers "if you want to write software for Mac, you must do it like this". So they gave developers the option of being messy.

Re:Someone should tell Apple

[TwistedSquare]

I always thought that Mac OS suffered in the marketplace because it ran on propietary hardware that only came from one manufacturer, whereas x86 PC hardware was produced by loads of companies and hence the competition drove the price down. If Mac OS X was available for x86 I'd buy it. But it's not, and I don't have the money to shell out to buy a Mac, as well as my x86 PC that I've effectively had (via loads of upgrades) since a while before Windows 95 came out...

Re:Someone should tell Apple

[Azureash]

You know, there ARE other desktops out there besides Windows and Mac OSX. I don't think its quite fair to say the KDE and Gnome developers are trying to copy Windows. I see a lot of (good) ideas taken from other window managers and desktops, such as multiple desktops, window listing, etc.

What people like in a desktop is subjective. I, for one, tend to use the mouse as little as possible and find most Mac desktops to be a bit mouse-intensive. Other people may work differently and never notice.

I do agree with you on your overall point however; OSS should be pursuing the best of the closed-source technologies. And I believe the serious projects are doing just that. Both Gnome and KDE are already prettier and more useable than Windows, and I would love to see them catch OSX in the eye-candy department.

Oh, and while we're at it, can I get fast user switching (OSX) and key-chain-binding (Waimea)?

Re:Someone should tell Apple

[Monx]

Why doesn't the finder give you the full path to the item you have selected so you can copy it and paste it elsewhere.?

Have you tried dragging the icon to where you want the pathname pasted? This works for the terminal and many html editors. It probably won't help with a word processor though, since it might try to embed the file.

Personally, I think the new Finder blows compared to even the old System 6 version. I want a real Finder replacement that brings back all of the keyboard navigability (and key bindings) of the old one. I don't think it would be for everyone, but it would be great for people like me who keep hitting cmd-n only to close the window and hit shift-cmd-n. I want my old Finder Secrets back.

Re:Someone should tell Apple

[eric76]

There was more to it than that, but you are partly correct.

The big reason was that enough of the details of the Windows operating system were available that people could actually do something. Apple wanted to be the single source for most of the software as well.

From Apple's point of view, users were basically consumers of both hardware and software products.

With the PC and many other competing systems, the barriers to entry were much lower -- you could also be a producer of software as well.

Everyone I know who was into the Macintosh were strictly users with little idea of knowing how the software worked and no inclination to learn how to write their own software. Everyone with an interest in writing software were using other computers and operating systems.

With OSX, I think there is finally room for the technically savvy users to do something more with their Macintosh systems than to just run programs from Apple and other software vendors.

Re:Someone should tell Apple

[jonadab]

> a number of !boot viruses, that could infect your machine even if you
> just opened a filer view onto a floppy. Not even Windows can do that :-)

Actually, Windows _can_ do that with CDs, unless you use TweakUI or regedit
to turn off the AutoPlay "feature". This was less of a problem when CD
burners were cost-prohibitive for most users, because people who caught
anything this way couldn't spread it around, since they didn't have a
burner. It worries me now, with burners being common these days. I always
turn AutoPlay off on Windows systems that I administer.

Re:Someone should tell Apple

[jonadab]

> can't remember a time when the Mac OS wasn't better than the comparable
> Windows version available at the time.

In all respects except maybe security, this is a pretty bogus claim. MacOS
was *different*, but it was not objectively *better* and in many ways was
a good deal *worse*. For example, Windows 95 OSR2 had real multitaking --
actual, factual, preemptive multitasking -- in 1996. MacOS didn't get it
until OS X came out. We're talking here about an important key feature
that *good* systems have had since the seventies: the ability for any
random application to be running at the same time as any other random
application, and the system doesn't freeze up for seconds-on-end while you
wait for something to finish; each application is responsive as if it were
running all the time (because, it is). So you can click on a link in Mozilla
and *immediately* switch to another window and do stuff while you wait for
the page to load. In MacOS 9.1, you can't do this; the browser monopolizes
the system, as if the whole OS were frozen up (in a sense, it is), waiting
for the page to load. This is a really big deal. It is, of course, fixed
in OS X. But Windows had this in late 1995 (sooner, if you count NT).

Then there's the dock. The Mac dock today (and since 10.0) is better than
anything Windows will have at least until Longhorn comes out[1], but prior
to that there was... there was... well, there was that little thing in the
upper-right-hand corner, a holdover from the System 6 Multifinder, that shows
which app is running, and you can pull it down and switch to a different one.
And the menubar at the top did have a clock. But there was nothing that
really could pass for an actual dock, bar, or panel.

Windows also has had, since 1995 or before, better memory management than
MacOS 9. This really shows up if you have more apps open than will fit in
RAM all at once. The classic Mac does not perform well under these
conditions; Windows 95 handles it much better; you only really notice the
swapping delays when you switch between applications. Additionally, Windows
95 does not require the user to configure VM manually, as MacOS 9 does.
(Windows 3.1 did require this; going to automatic handling of virtual
memory was a major leap forward in 1995.)

The Apple HIG is arguably better and certainly more closely followed by
most ISVs, but there are other niggly things about the Mac interface that
suck in ways that almost make up for that. With the Classic Mac you
basically *have* to have a third-party macro application, for example,
because way too few things have keyboard shortcuts. (The mouse is great
for discovering stuff you didn't know how to do, but it sucks for quickly
doing something that you do very frequently.) Keyboard shortcuts are much
more common in the Windows world (and almost totally universal in the *nix
world). OS X is starting to fix this (though there is still more to be done).

There are other things. To say that the MacOS is better than Windows *now*
is a fairly credible claim; to say that it has *always* been better than the
Windows available at the time is... bogus.

Although, in the Windows 3.1 days, I'd agree that the Mac system was better.
(I didn't use Windows much back then, though; I used DOS :-)

[1] Gnome, however, is in some ways better. Notably, the applets are better,
and the Mac dock doesn't support drawers, which are IMO a killer feature.
The icon zooming on the Mac dock is better, however, and unifying the
running process list with the launchers, only listing a given app once
and indicating that it's running with the little arrow underneath, is a
nice touch. But the Windows taskbar is clearly inferior. But it was
better in 1995 than anything equivalent that the Mac had to offer until
OS X came out. It took Apple four or five years to catch on to this.

Re:Someone should tell Apple

[TheCrazyFinn]

Except for the fact that the eMac has a real GPU in it instead of the Equivalent PC's Intel Extreme Graphics with Shared Memory. Even the eMac's lowly Radeon 7500 is 2-3x faster than Intel's crap graphics. And it has 32MB of dedicated VRAM, instead of stealing from system memory.

Just that will do wonders to equalize the eMac's slower CPU. And if you're comparing the eMac to a Celeron, the CPU ain't even slower.

Another thing to consider is the fact that Apple uses high-quality tubes in their CRT's. This isn't the $75 special you get at the low end. Price out an equivalent box from a major maker (include a decent GPU and a Good monitor) and you'll see Apple fairs decently against them price-wise.

Re:Someone should tell Apple

[Angry Pixie]

Everyone I know who was into the Macintosh were strictly users with little idea of knowing how the software worked and no inclination to learn how to write their own software. Everyone with an interest in writing software were using other computers and operating systems.
I can second that as well as the parent. I've only met a few people who had any interest in developing software on the Mac, several people who were interested in developing multimedia on the Mac, and countless many people who just want a computer that worked like an appliance.

I think another factor worth mentioning is gaming. I seem to recall Apple discouraging people from developing game software for a while since Apple wanted the Mac to be respected in the work environment, hence a lot of more science and educational apps. So, DOS ended up being the game platform, which worked out quite well since DOS developers had many more potential customers.

I still want an Apple. I've wanted one for years, but I'm locked in, and I still see Apple as "benevolent dictator" that go back to the way it was when Steve really got overbearing.

waste?

[pholower]

I like the idea, but I worry that about speed regardless of what they say will occur. To me, it would be better to have to package load onto the HDD, and if there are any missing libraries, have that go and fetch them as well. This just seems like a waste of internet traffic to me.

Isn't this already being done with apt_get? I just think Linux needs a more user friendly updating service. I hate to say it, but windows is much better at taking completely computer stupid people and having them screw up their own pc's, instead of having to call a family member to do it for them.

Re:waste?

[JaredOfEuropa]

To me, it would be better to have to package load onto the HDD, and if there are any missing libraries, have that go and fetch them as well.

That's exactly what is happening: the software is cached. From their website: "I've only got dial-up; can I still use Zero Install? Yes! Run each program you want while on-line and it will be cached. When you're off-line, the cached copy is used automatically."

Re:waste?

[caseydk]

I do something similar to this already.

I keep all of my Java apps on a Samba share on my fileserver. Then, I set up aliases pointing at my standard version that I'm using.

Then, from whatever system I use or plug into my network, I map the drives and I have all of my apps with no hassle.

I've done this connecting Slackware, Redhat, win2k, and win98 systems to my network. It removes all the nastiness of having to maintance multiple copies.

Re:waste?

[LittleBigLui]

That's exactly what is happening: the software is cached. From their website: "I've only got dial-up; can I still use Zero Install? Yes! Run each program you want while on-line and it will be cached. When you're off-line, the cached copy is used automatically."

Sounds a lot like Java Net Start to me.

Re:waste?

[RdsArts]

To me, it would be better to have to package load onto the HDD, and if there are any missing libraries, have that go and fetch them as well.

That's what it does. That is what they mean when they say 'cache'.

What happens is the software is cached first. Then, all dependancies are listed as 0install directories, so if you have it already it'll use the cached version, but if not it'll pull a copy and cache that. This is nice because if, say, you don't use the help files, it won't pull them until you ask for them, so you don't have them clutering up your HDD or being downloaded. You just point the ROX-Filer at the 0install AppDir, click on it, and without you even needing to think about it everything is installed and the program runs.

It also has a way to quickly update all apps, or if you just want one upgraded, open it in the Filer and hit 'reload.' Simple, easy, and intuitive. In general, I'd say this is even easier then the Windows Update and installers combo.

Re:waste?

[Lumpy]

or simply run a STATICALLY compiled binary and not worry about dependancies...

All my binaries are statically compiled for the downloaders... and I NEVER get a complaint how my apps dont work, in fact I get more comments on how my linux apps binaries work every time no matter what and is a stark difference to most of the other linux stuff out there.

the typical response is "your binaires work every time... why can't other OSS developers do that?"

I was afraid slashdot wasn't being slashdot

[HappyCitizen]

We haven't had a "Linux is going to take over the world" story in such a long time....

Potential for unpublishing apps?

[tepples]

Slashdot has previously covered Rox here.

But one thing I wonder about Zero Install: what if you launch an application, it needs a piece that you don't have cached, and the server hosting it is down? Is it possible for a maintainer to unpublish an application?

Re:Potential for unpublishing apps?

[tal197]

But one thing I wonder about Zero Install: what if you launch an application, it needs a piece that you don't have cached, and the server hosting it is down? Is it possible for a maintainer to unpublish an application?

Zero Install can download from mirrors, peer-to-peer, etc, provided it gets the master index with the GPG signature from the main server.

If you want to get the master index from a backup server, you need manual intervention (root needs to indicate that the backup server can be trusted).

However, since the signature part is small (about 1K), a single trusted backup site (debian.org?) could easily host every index in the world. The rest of the data can come through peer-to-peer, etc.

This sounds perfect...

[gleffler]

For anybody. It emulates the best aspects of the mac's "packaging" system (bundles) while also making it easy to get new stuff.

Hopefully, this takes off in more of the 'newbie oriented' distros so that we can say "Just type cp /software/openoffice /usr/software to install" instead of ./configure && make && make install. :)

I still would like to know how they plan on fixing library dependencies, but ... assuming they get over that, I'll be very happy once this is released.

Re:This sounds perfect...

[AntiOrganic]

Maybe just have a shell script called "Install" on the distribution media and give it a nice icon? ;)

You're over-thinking the solution; dragging and dropping it somewhere is a lot more intuitive for newbie users than using some cryptic global installation utility.

Re:This sounds perfect...

[Jah-Wren Ryel]

--
Member of the Stop Fucking Saying 'M$' army

Hhhm. I think your sig needs to be abbreviated.

You should go with: M$F$M$A

Re:This sounds perfect...

[juhaz]

Dragging and dropping WHAT from WHERE to WHERE?

Are you all guys seriously claiming that first
a) finding right foo for your system,
b) downloading foo,
c) knowing where it went,
d) knowing where to drag it,
e) actually dragging it

is simpler than cryptic
a) "install foo"?

Even if you automate all those steps and make a piece of software that has just a list of available applications and a place to drag it, you still need to know how start that, and it's not radically different or easier from how it's already done in most of cases (eg. checkbox in front of name and install button somewhere).

Re:This sounds perfect...

[tal197]

Are you all guys seriously claiming that first
a) finding right foo for your system,
b) downloading foo,
c) knowing where it went,
d) knowing where to drag it,
e) actually dragging it

is simpler than cryptic
a) "install foo"?
[ b) enter root password and hope it doesn't mess up your system ]

a) You don't have to find the right version for your system, just run the application. It will try to access the appropriate binary and that will get cached.
b) Downloading happens automatically, just like viewing a web page through a web cache.
c) It goes in the cache directory, whose structure mirrors the URI scheme (eg /var/cache/zero-inst/gimp.org/bin/gimp). You shouldn't care though, any more that you care about the structure of squid's web cache.
d) Drag it where you want it. On your desktop, panel, start menu, etc.
e) You could just run it where it is, without creating a short-cut at all.

Re:This sounds perfect...

[tal197]

Everybody here is oohing and aahing but let me go on the record as saying that this is actually a BadIdea (TM). Why?

Sorry to spoil your arguments, but each of your starting assumptions is wrong ;-)

• It does use shared libraries, so just upgrading libxml will do, same as usual.
• User data isn't kept inside the applications. The whole /uri/0install filesystem is read-only anyway.
• Configuration isn't inside either.

Just a bad idea taken to it's expreme.

If you could point me to the places on the site where you got your information, I'll try to fix them / make it clearer. Thanks.

This is why...

[ghettoboy22]

I *love* my PowerBook G4. Seriously, Apple has had this for years going back to the old System 9, 8, 7, etc.... it's nice to see someone major is finally trying to copy 'ole Steve Jobs's team. If you ever wondered what life would be like without the Windows Registry, this is it.

Re:This is why...

[Endive4Ever]

Apple has had this for years going back to the old System 9, 8, 7, etc...

How come the system folder on my MacOS machines is full of all sorts of 'preferences' and assorted debris and croft? Yours isn't??

I was hoping maybe people here were talking exclusively about MacOS 10, because I *know* for a fact that apps spatter stuff all over in the system folder on older MacOS versions. Now I find more handwaving and mistruths and wonder if 10 does the same messy things. . .

Re:This is why...

[Anonymous Coward]

How the hell is this "insightful"?

"hehe, I love my mom! +5 insightful, please!"

Re:This is why...

[erikharrison]

Uh . . . . no.

Classic Mac OS used the resource fork for storing associated files, but still had an OS wide location for preference files (MacHD:System:Preference). Sure, no registry, but frankly, LOTS of OS's don't have a registry.

Mac OS X has bundles which resemble AppDir's (That Rox uses) a great deal, but OS X got them from NeXT not OS 9, and NeXT got it from RISC, which is the OS that Rox is trying to emulate in the first place. Mac OS emulation is the farthest thing from Thomas's mind, I assure you.

The real interesting technology isn't the AppDir's anyway, it's ZeroInstall, which allows you to view the internet as a file system from which you can directly run applications.

Re:This is why...

[gobbo]

Now I find more handwaving and mistruths and wonder if 10 does the same messy things. . .

System 7 on up to 9.2 wound up with all kinds of scat dribbled throughout the various subdirectories in the system folder, as well as associated files in the application folder -- but only some applications were to blame -- many classic apps are self enclosed and install with a drag'n'drop. OS X improves the ratio somewhat with its bundles, an even greater proportion of apps are install-friendly. Some developers still love to pollute files everywhere (are you listening Adobe?) -- though since we're generally talking about /Library, it isn't as big an issue as the conflicts arising out of the Extensions folder in Classic.

It's all relative, though. Give me the 100,000+ file complexity of OS X with it's well-designed directory structure over a simpler but kludgy Mac OS 9 or Win9x anyday.

No, The future is thin clients

[nurb432]

This is the true power of Unix + X.. Running applications remote from the workstation..

This aids in system management, resource control, data security, platform independence, .. most everything that a data center does, this improves it..

It *is* the future.. ( and ironically the past.. remember VT100's and 3270's ? ) as is its the right way to do computing..

Re:No, The future is thin clients

[Inspector Lopez]

As long as CPUs are so fast, RAM is so cheap, and disks are big ... and the net is relatively slow, thin clients will have only thin application.

I *do* remember the good old days of VT100s, and they worked great; the thing that displaced VT100s in our research group was *Macintosh* --- those wascally little SEs and the occasional MacII had such nice software onboard, they were a delight to use. The Macs were in turn partially displaced by DEC RISC machines, which cost more but brought a lot of horsepower to the desktop.

We used to use a Beowulf in our current project, but the blasted Pentia got so fast there was no point. Our real-time processor now relaxes on a single machine.

It's not so hard to imagine the pendulum swinging back to thin clients (perhaps in the guise of wireless PDAs, or in a more sinister form via .NET), but there is no need for a thin client to run a word processor or mail client or www browser. Religious wars aside, our desktop software is quite capable, and getting more so.

Re:No, The future is thin clients

[starseeker]

I note the rather skeptical responses, and while I agree with you in broad I think the picture is going to vary slightly.

As has been pointed out, the primary weakness of a network based thin client system is there exists a single point of failure. So I would propose the following for a corporate computer network:

Two mainframe systems, in physically remote locations, each completely capable of handling the corporate network. The mainframe's will serve as the core of the network, but the thin clients will be slightly more than just monitors.

A powerful thin client (I suppose thin client might not be the proper term) is what is needed to handle the reality of an iffy network. The thin client needs to be able to function independantly in the short term. It needs to be able to hold all of it's currently-in-use software and data in memory, and be engineered to make an emergency dump to some local nonvolital memory in case of a power failure. The key benefits to this "thick client" setup are a) because it is not an independant PC with the ability to boot and load software on its own, it is not a candidate for theft b) All data is preserved automatically at a central location except in the case of an emergency, and even then it is recoverable c) software updates only have to be performed one place to be deployed company wide d) maintainance is simpler since the thin clients can in theory be made without moving parts (i.e. hard drive) if they use solid state memory for the Gig or two of non-volital emergency storage they will need. They will be more expensive than a true thin client, but I rather suspect in bulk the economics would work and certainly maintainance costs would provide more than enough incentive.

Re:No, The future is thin clients

[starseeker]

It depends on the requirements of your company. Initially, it wouldn't be cheap. But then, neither is deploying 10,000 PCs. The question is what is least expensive over the long term, and my hunch is it WOULD be cheaper to maintain. I don't know, I haven't studied the problem in detail. But considering the manpower/lost productivity involved with maintaining individual Windows PC machines in my experience, a robust thick client with no moving parts talking to a reliable server would solve a lot of headaches. Taking system control out of the hands of the user and reducing moving parts in the client machines seem to me to be the big wins in such a setup. The expense of hardware up front would be high of course, but considering the hardware that goes into proper networks today would it really be that different? The proposed savings in this scheme are more in less downtime, less required upkeep, and less potential for stolen hardware than in upfront cost of hardware itself. There again though - I don't know what bulk production of thick clients would cost.

Going back in time?

[TyrelHaveman]

This layout of program storage reminds me of The Olden Days on DOS, when the whole program was in one directory. It's still very much like this in Windows, in fact, with the "Program Files" directory often containing everything (although "Documents and Settings" is becoming more used for user settings storage).
Personally I like the idea. I've always been confused trying to locate various files which belong to a single application in *nix.

Re:Going back in time?

[Kick the Donkey]

Yeah.. Everything is stored in Program Files. Except when things are put into C:\Windows\System32. Or the Registery.

Re:Going back in time?

[base_chakra]

Or in %sysroot% itself. Or in the maze of subdirectories (other than System32) under %sysroot%. Or in hidden files/directories in the root directory. But yeah, other than that, it's Program Files, the registry, or System32. :)

Well duh...

[Enonu]

Sorry folks, we have the technology right now to support multiple version of libraries at the same time, disk space is no longer an issue, and it just makes logical sense to keep everything related to an application together in a logical unit that can be administrated with minimal effort. The /bin, /lib, /usr structure has to go. Applications locking in to configuration files across the file-system has to go. It's simply painful to use, and something like Rox here is the first step in the right direction.

Not like this step hasn't been taken in the past by multiple other software solutions ...

Re:Well duh...

[0x0d0a]

Sorry folks, we have the technology right now to support multiple version of libraries at the same time

Why would you want to do that?

On my Fedora box, if I upgrade glibc to fix a bug, I want *all* my applications to benefit.

Oh, and disk space is not the reason for having shared libraries -- memory usage is.

Re:Well duh...

[rusty0101]

One reason you might want to support multiple versions of a library is that when a major upgrade to a library occurs, say going from libc2.3 to libc3, backwards compatibility is not assured. If one of the applications you are using can not use libc3, you as the user get to have the joy of re-compiling it to see if it will work with the new libc. If it doesn't, having a copy of the old libc2.3 lying around to run that application against would be handy. No?

Granted as the last application requiring the old library is upgraded to being able to use the new library, the old library should be eliminated, but when a major upgrade breaking backwards compatibility happens, most people do not want to wait days or months for the application they have been using to be upgraded. They usually want to be able to continue to do the work that they need to do.

Then again, I could be wrong. Perhaps most other people are happy to sit around on their thumbs.

-Rusty

Re:Well duh...

[lpontiac]

and it just makes logical sense to keep everything related to an application together in a logical unit

I propose we set aside a location on the system to hold subdirectories each dedicated to a single software package. Let's call it /opt.

Re:Well duh...

[ciggieposeur]

But modern distributions like debian and gentoo have dependency checking, so if your attempt to upgrade libraryX is going to break appFOO, the upgrade tool itself will complain. So we've already got that functionality, IF you use applications that adhere to the local packaging system. And if you don't, well then you're obviously smart enough to fix the problem, right? Just compile the application and statically link to its older libc.

Short form is, this argument about /bin /usr /lib etc. seems to come up all the time from people who refuse to do ANY of the following:

1) Use apt-get/dpkg/etc to install things
2) ./configure && make install

Funny they hate 'make install' but have no trouble double-clicking an InstallShield that will do God-knows-what to their Windows system.

Re:Well duh...

[Jeremi]

If the users don't have enough memory to run the program, they won't buy it and the developer won't get their money. If the users do have enough memory to run the program, then there isn't any problem with it using more memory. I don't see anything unethical about writing a program that uses lots of memory, as long as you are honest about its memory usage on the box. Whether the users want to buy a memory hogging program is up to them to decide.

Re:Well duh...

[deblau]

The /bin, /lib, /usr structure has to go.

This kind of proposal about scrapping the current directory structure has been discussed ad nauseum on the Filesystem Hierarchy Standard mailing lists. Here is the Standard Rebuttal against scrapping /bin and /usr/bin:

With each app in its own directory, your $PATH becomes a mile long, and too difficult to maintain.

You can't have your cake and eat it too. Some have suggested the use of symbolic links in /bin and /usr/bin, but then you run into this Standard Counterargument:

Different application packages can have identically-named binaries. Upgraded packages always have the same binary names.

The best combination seems to be symbolic links to the most recently-installed apps, but overriding your $PATH in ~/.bash_profile for legacy versions.

The Standard Rebuttal against scrapping /lib:

Apps which depend on other apps for libraries won't know where to look. This is especially true if each installed version of a required app is stored in its own numbered directory.

Another argument involves the use of 32-bit vs 64-bit libraries. Best practice seems to be making copies of the most recently installed libs in /lib and /usr/lib, and using environment variables ($LD_LIBRARY_PATH, e.g.) to run older apps.

Rebuttals for getting rid of /usr (i.e., having a One (Partition) Size Fits All approach):

#1: Some boxes have read-only disks for security (CD-ROM firewalls come to mind). Now you can't install new applications.
#2: You have one 100GB partition and you get a power spike. Now you have to wait for the fsck to finish before you can troubleshoot the damage.
#3: You're in a diskless environment with centralized, NFS-mounted applications. With no /usr, you have no suitable mount point.

#3 is especially common in large enterprise and government environments. If you've ever talked to someone who admins 1,000 desktops for their department, you'll know what I mean.

On the mailing lists, the use of /package (or /pkg) also has been discussed ad nauseum. Keep in mind that the filesystem hierarchy is designed so that non-local (commercial) packages don't step all over each other when installing. Local (enterprise) software installation can happen wherever the hell you want it to, as long as it doesn't have to play nice with COTS software.

Executive summary: you can run whatever directory structure you want -- I won't stop you. Just expect to hear lots of complaints from your developers and sysadmins. The reason things are the way they are is partially due to industry inertia, but mostly due to the fact that they just work better that way. If you don't like it, go contribute.

Re:apps contained in their own directories....

[Moth7]

And it doesn't remind you of Windows's "Program Files" too?

A good idea, here's why...

[heyitsme]

It has been implemented in OS X. This is what happens when you drag a .app file (really, a folder. try to cd into one sometime) and copy it to any point on your hard disk (typically /Applications).

Reminds me of an old joke...

Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
BSD (in this case, OS X): Are you guys coming or what?!?

You only have to download once

[Adolph_Hitler]

After you download it, its cached. Basically you have to download the app anyway to run it. If you download say the new version of say GAIM it would be fantastic. I'd just drag it from the browser onto my desktop and then click it. Apt-Get is for nerds like you. Regular people want to accomplish a task in the least amount of steps. If you can bring the task to two steps, click n run, or drag n drop, this is what people want.

Arrrggg....Joe dont care !

[MajorDick]

"a way that I believe is exactly what Linux needs to become a serious contender for Joe User's desktop"

While I appreciate the posters enthusiasm this is not a panacea for oe User putting Linux on the desktop. What is in my opinion is a scale of compatibilty with both hardware and software. I mean Joe User (or Joe Six Pack) Only cares if he can do what he need to with apps he wants to. NOT what someone else tells him is a better application. He wants to play his games, surf the web, doodle with his digital checks and balance his checkbook, Tell me of any GOOD applications the average computer illeterate could use to do his checkbook, edit his pictures etc that is as brainless as developers make them for Windows/Mac ? ZIP , There are GREAT apps for doing all those things but in general they are for much more sophisticated users. When Jp can go to CompUsa and buy anything he wants , games, tools, etc, that will run on Linux and has some support number he can call when he breaks shit THEN Joe will use Linux on the desktop.

Re:Arrrggg....Joe dont care !

[killjoe]

According to your criterea liux is coming along.

Linux already has great compatibility with 90% of the hardware on market (more then windows probably), you can already call somebody when things go wrong. Moneydance is an excellent and easy to use program for balancing your check book, zip files are handled automatically by all the file managers, mozilla is better then IE in every respect including speed and ease of use. I don't edit pictures much but I imagine there are a few applications for that well.

It sounds to me like all we have to do is to get a handful games to attract the 16 year olds and we are there!.

BTW. There is not a comp-usa in my neigborhood but there is a best buy. I went in there to ask about some mac games and software and they told me that they don't carry anything for the mac but that I could check out their web site and maybe they would have some there. Apparently in this regard both the Mac and Linux platforms are suffering.

Maybe we can start some sort of a boycott of stores that don't carry Linux distributions. I mean if the republicans can call for a boycott ot heinz ketchup because the wife of the democratic candidate owns a part of the company we can call for a boycott of best but don't you think?

If you can make more money, do harm.

[Futurepower(R)]

The full name is "Windows Registry Copy Protection and OS Degradation Scheme". It's part of the "Treat all customers like criminals because some are criminals" Initiative.

Could there be a difference here?

[expro]

Could there be a difference here? Hopefully they are not putting code into virus-writable directories, as often happens on Apple.

Re:Could there be a difference here?

[expro]

I install Mozilla on OSX. It says, rather than using an install program, I should just drag the icon into a directory, such as the applications directory, making it writable by any unprivileged program the user may execute.

This is not unlike I have seen for other programs for Mac as well.

When I try to take the initiative and protect these directories, the programs often stop working, because the program writes these directories when run by the user.

I am told by admins that program directories on OS X should generally be made user-writable.

When I do a default install Eclipse on OS X, it places the user workspace underneath the Eclipse program directory, not naturally leading to program directories that are not virus writable. I run it on Linux, and the workspace is separated from the program directory off of my home directory, and the eclipse stuff installs nicely into a protected area.

Re:Could there be a difference here?

[koali]

When I do a default install Eclipse on OS X, it places the user workspace underneath the Eclipse program directory, not naturally leading to program directories that are not virus writable. I run it on Linux, and the workspace is separated from the program directory off of my home directory, and the eclipse stuff installs nicely into a protected area.

Eclipse 3.0M8 is what you're looking for. It lets you choose the workspace location without fuss.

Re:apps contained in their own directories....

[Ummagumma]

No, actually, not at all. Most programs on your windows pc that are 'installed' into Program Files still have obscure registry entries, and may require dlls and such in the \winnt and \winnt\system32 directories. You cant just remove a progam from the 'Program Files' folder, and have it gone.

Yes

[mrsev]

This sounds great. Im no linux guru and the hardest thing I find is to install a programme that requires other files but one version is required for one app and the other for another. In this age disk space is trivial and stability and ease of use much more important. Granted many people like tinkering with their systems but for me I just want to get my work done..(and then play games).

Consider most people do have broadband now

[Adolph_Hitler]

Also consider this, for the average person not only is this a more secure form of distribution, its more efficient, its easier, and for 99% of files people will download it just works. Unless you are going to compile your kernel or do serious changing to your machine you wont need apt get. Just to download GAIM, or KWORD or whatever, you only really need to drag drop and run, or even just click and run. I see nothing wrong with this, and you could give the browser enhanced UI features to embed some of the apps into it in the future.

This is also what Microsoft is trying

[Koyaanisqatsi]

Flame as you want, but .Net assemblies not published to the GAC (Global Assembly Cache) are exactely like that: all of the application files are kept under a single directory and all you need to setup the app is a "xcopy" of its files.

Delete the directoty and the app is gone.

This is here now, and altough .Net still have to catch on into the desktop, it is very much real on the server side. Gotta love it!

Re:This is also what Microsoft is trying

[egarland]

I'll believe Microsoft's hype about .NET (and managed C++, and all the other blahblahblah) as the second coming when I see:

1) MS Exchange Server, MS SQL Server, MS IIS rewritten in managed code

2) MS Office writen in C#/.NET assemblies.

Microsoft touts how much cheaper migrations are when you stay within Windows, so clearly these tasks can't be too difficult. And they have the gigantic advantage of being in-house.

Exactly. .NET's management system only works for things running in the .NET environment. That's a small subset of the programs that run under Windows. Zero Install is targetted to everything that runs on the platform. It sounds like a good idea but it's still not enough. A we need a robust package management system with lots of add-on packages that works on ALL VERSIONS of Linux.

Companies can easily make a setup.exe that will install and work properly on Windows 95, Windows Server 2003 and everything inbetween. When we get a system that will do that for all versions of Linux (with the same cpu architecture), we'll have something. Then, add the ability to install that same package to only be available by a single user without root privs, and you have a winner.

User settings storage in win32

[tepples]

It's still very much like this in Windows, in fact, with the "Program Files" directory often containing everything (although "Documents and Settings" is becoming more used for user settings storage). Personally I like the idea. I've always been confused trying to locate various files which belong to a single application in *nix.

Most *n?x apps seem to store all the per-user settings in a dot-file or dot-folder in the user's home directory. In Windows, they're often strewn about in at least three places: C:/Documents and Settings/Me/Application Data/, C:/Documents and Settings/Me/Local Settings/Application Data/, and HKEY_CURRENT_USER in the registry. In addition, a lot of the apps I have installed on my Windows 2000 machine came bundled with peripherals, where the app and a device driver came as part of the same install, the app in C:/Program Files/ and pieces of the driver in various folders in C:/Windows/.

How does Rox handle it?

Re:User settings storage in win32

[tal197]

How does Rox handle it? [ configuration files]

Usually, ~/Choices/ROX-Filer/Options.xml, etc. Choices cascade (/usr/local/share/Choices, /usr/share/Choices, ~/Choices). You can change the location with CHOICESPATH.

In future, we'll probably move over to the (very similar) freedesktop.org base dir system, which defaults to ~/.config instead but is otherwise pretty-much the same.

Re:User settings storage in win32

[Jugalator]

One thing I don't really find logical in Windows ( heh, only one?? :-) ) is the invention of the registry.

Why did Microsoft make this move? Not only is it "all eggs in one basket" so it becomes unsafe in case it would crash, but it's also hard to clean it when the installer don't do the job to 100%, which it almost never do. Often I simply don't dare to, since it could be spread out in more places than HKCU\Software\Company\blah.

I'm not really interested in Microsoft bashing -- just an answer to why the app settings aren't stored in their respective folders. The OS settings could be stored in a win.ini just like before, or any other file structure that might be faster to navigate (like a hash table).

I think the registry *is* pretty fast and that's one reason, but it still isn't reason enough since the apps could just store in their directories with a similar structure via the standard registry API's. Why in a single multi-Megabyte mess?

Re:User settings storage in win32

[Pentagram]

Most *n?x apps seem to store all the per-user settings in a dot-file or dot-folder in the user's home directory.

And, dammit, this is as messy as hell. I don't like having hundreds of .files in ~. I like to keep it tidy. Why can't we have a standard that says all config files are kept in ~/settings/ with default files in /settings/? Or at least make it user configurable. I also don't like the . prefix to make files hidden; feels like a nasty hack. If you keep the files tidied away I don't think it's even needed.

</rant>

Isn't this one already on the list?

[Liquidrage]

You know, the list of single items that is what is needed to get Linux to JoeUser's desktop? I'm sure the concept was there already is not the exact tools to do it with.

My list contains 1 item. One word actually. Unification
The average computer user is not an IT person. They have problems when you upgrade their machine from 2000 to XP. Even if you give them XP with the old GUI.
They would not be OK having to know 3 or 4 different desktops just to stay marketable.

Likewise, 3 or 4 mail clients, 3 or 4 office suites, this is bad for them.
This might change in 10 or 15 years when the business world is dominated by people that grew up using personal computers. But right now that isn't the case.
And I fully realize my list is mine and yours may differ. But isn't that the problem?

Don't bitch to Steve

[SweetAndSourJesus]

Bitch to whoever decided that that app should have an installer.

If MS Office can be a drag and drop install, almost anything can.

Re:Don't bitch to Steve

[Anonymous Coward]

"Bitch to whoever decided that that app should have an installer."

Installers are just a "solution" to make it more difficult to copy an application to a friend ("casual piracy").

Soon they will be asking you to insert an original CD-ROM in order to play a game, and, eventually, they will come with a way to require you to "activate" the software. Oh, wait...

Re:Don't bitch to Steve

[hak1du]

Bitch to whoever decided that that app should have an installer.

You think people write installers for fun? They usually write them because they don't have a choice, because the OS lacks some piece of functionality or other that lets the system adapt dynamically.

Besides, Mac-style drag-and-drop installs have their own problems: they don't get updated properly and they don't verify or deal with dependencies on install; they just dump the mess into the user's lap.

If MS Office can be a drag and drop install, almost anything can.

You got it backwards: the bigger and less integrated a package is, the less it needs an installer. After all, a 500M package can just carry all its own libraries with it and not worry about the fact that it will be out of sync with the rest of the world.

Why I dislike about installing softwareunder Linux

[mst76]

Most of the time you're assumed to have root access, especially with rpm and deb. This is supposed to be a multi-user system, right? What if I want to give users the ability to install end-user apps in their own /home to try out? Should I tell them to download the source and tweak the makefiles so make install will behave correctly? Is there no better way to do this?

Store display problem

[nilspace]

I remember reading an article by Dvorak where he was looking at computers in a consumer electronics retail chain. As he was standing there, a young man walked into the store, jacked his iPod into a mac on display with firewire, drag and dropped the Office.X folder from the mac to his iPod, unjacked and walked out.

Unfortunately, ease of use can obviously be abused, but in such ingenious ways. ;)

I thought I've done it in my LFS two years ago?

[francium de neobie]

Installing different packages in their own directories... this is nothing new.
Indeed, this has been specified in the FHS (Filesystem Hierarchy Standary) long long time ago. This is what the /opt tree is for.


Indeed, I've always been wondering why major Linux distributors haven't been using the /opt tree for simplicity, but kept on keeping all the files together in /usr and /usr/local. That's a hell to clean up when your rpm or apt doesn't work.

duplicate detection, copy on write

[hak1du]

Yes, it's nice to include all the dependencies in a single directory. However, there is a reason why not every Gnome desktop accessory includes 500M of Gnome libraries--disk space is cheap, but it isn't that cheap.

Something like Zero Install should be combined with some form of duplicate file detection or duplicate block detection and sharing. Furthermore, to avoid a lot of tricky bookkeeping, there should be copy-on-write. And that kind of functionality really is best implemented in the file system itself. So, something to think about for the next major release of "ext". (Note that Microsoft is implementing something like this, but they certainly weren't the first to come up with it.)

Note that the same thing should also happen on downloads: you only download application components you don't already have locally. NFS isn't a good protocol for that, but WebDAV could handle it.

The future? not anymore

[Cuthalion]

Just running an X server as a thin client used to be the future, but the present way UIs are presented to the user from a server is 95% of the time in a web browser, and if that changes, it's not going to be back to what used to be future (X).

Piggyback on which P2P network?

[tepples]

Why can't we list repositories on a P2P network, let a user connect to this network to constantly update their respositories, in the same way that emule works?

I've tried eMule. I don't want to have to sit in a queue and wait for 1,759 other people to get something just because I told the file manager to start an app. What improvements would you make to the architecture of the network? No, BitTorrent doesn't scale well for small (<10 MB) files.

Besides, P2P doesn't work well for residential or university dorm users who can't take incoming connections.

Like the DOS days

[superpulpsicle]

Everything was just a matter of folder installs during the DOS days. You copy a binary and run a binary and delete a binary.

Believe it or not part of the reason why M$ went with the setup.exe installation was because software was harder to distribute around requiring the setup binaries.

Funny how things come around full circle.

If you have Knoppix try klik

[bfree]

In the last few months klik came into being. klik is a point and click software store for Knoppix which uses AppDir (quoting from the architecture description):

Mainly a philosophy about making each app package "self contained" (at least relative to some defined base system, Knoppix in our case).

If you have a recent (say from last November or so) version of Knoppix fire it up and give it a go! You can even install software while running from the liveCD and retain it in a persistent home.

Similarities to Archimedes

[pigpogm]

This sounds to me as though it has some similarities to the way the old Acorn Archimedes used to work (What? Oh, it was quite big over here in the UK ;)

An 'application' looked like a single file that started with a '!'. It ran as though it was one file, copied and moved as though it was one file. If you used a modifier to open it (Ctrl-click, or something similar), though, it actually opened up as a folder. The app was really made of a number of files - the icon that the application/folder would have, the actual programs, any config files, a script that was run when the program was launched, and another script that would be run as soon as the OS 'saw' the app.

Part of the config would tell the OS what file types the app could handle, so as long as the app had been 'seen' (ie, it's parent folder had been opened), the filetypes would be recognised until the next reboot.

Re:Similarities to Archimedes

[pigpogm]

I, er... didn't RTFA.

I mustn't be new around here.

Solitaire and the Sims both work in Linux

[Adolph_Hitler]

And those are the worlds most popular games. Games is not the major issue. The major issue is being able to download your porn, being able to surf the web, being able to burn pirated software, movies and DVDs, being able to get on AIM or some IM client, and occassionally use a word processor.

This is what 99% of internet users do. They don't run some esoteric application by Microsoft, 99% of people don't use all the features of word or office. Most of them wouldnt know the difference between Word Perfect, Star Office and Microsoft Office. Most people just think "I need to use the word processor." or "I need to get on AIM" or "I need to browse the web."

Simply name the App Web Browser, Word Processor, Instant Messager and 99% of users will know exactly what it is and what its for. They don't give a damn who makes it as long as it works and its easy to use. Functionality is what Linux needs, ease of use is what Linux needs, Eye candy is what Linux needs.

Linux does not need more apps, right now Linux has just the right amount of apps to work as a typical desktop machine for 99% of the population. Instead of building more Apps, its time to refine the apps already in development and make them more intuitive.

Yeaaah (all excited jumping up and down)

[Britz]

Finally we have found the holy grail that for so many years all Linux users and developers have sought after:

It is exactly what Linux needs to become a serious contender for Joe User's desktop.

I wonder how many times have we read that on Slashdot. I wonder how this one slipped past the editors again. And it is boring, not important and proven wrong. There has never been, is not and will never be exactly what Linux needs to become a serious contender for Joe User's desktop. Let alone a single little thing being exactly what Linux needs to become a serious contender for Joe User's desktop.

Apart from that I dread this technology where glibc will have to be included in every app. The beauty of free software is the fragmentation. Everyone makes a little app that is perfect at what it does and small enough that one person can write and maintain it. And bigger apps just bundle them together like libs (think of all the GUI cd burning apps that are frontends to at least cdrecord, mkisofs and cdparanoia, if not to many more small apps). Also the ability to upgrade and keep the custom settings and data for one the new one in .foo is something Windows is trying to copy in XP now, but many programs still have their own idea about where to store custom data.

And that is only half of what is wrong with this post (I am sorry, but I did't even RTFA). Please don't get me started on NFS.

'nuff said

Oh Yeah, Great Idea...

[Jameth]

With fully self-contained apps, we could do away with those silly shared libraries, and we could also just pitch reusing simple programs. Maybe, maybe if we ditched the fifo, we would have finally removed all the flaws in UNIX!

Re:Why I dislike about installing softwareunder Li

[ananke]

Insightfull my ass. ./configure --prefix=~/whatever

Re:YAWN. That is SO 4 years ago

[Endive4Ever]

Everything is copying OS X. Everything has always been copying OS X. When Napoleon rolled across Europe, it was because he'd seen the Apple Development Team approaching the NeXT compound and about to break down the door with a battering ram.

When Moses came down from the mountain, he wasn't carrying a stone tablet, he had a PowerBook.

Michaelangelo didn't do a single original thing in his life. He just travelled forward in a time machine (invented at Apple) and cribbed ideas off a blackboard in the Apple R&D facility.

----------

The 'everything was invented here' frenzy of Applebots rivals the chauvanism of Soviet-era Communist-Party/Russian-nationalists.

standardized installs

[cyko500]

The day that linux gets standardized installers that are just "click and install" with some options (like a windows installers) and a standardized install directory (a "program files" directory) is the day that thousands apon thousands flock to linux.

People give up on linux because they don't know how to install apps and games. They download stuff then say, "WTF is this shit? How do I use this?" Then, after realizing 90% of linux apps are like this just give up on linux.

Even when people can learn to install stuff they often don't know where the hell to install it to (people are used to not having to organize programs themselves, just throw em wherever it wants to go). We don't need fancy caching of downloaded apps and shit. We just need some standardization of the installers (shortcuts on the desktop or popup menu couldn't hurt either). That's what your average computer user wants.

Screw drag & drop

[be-fan]

This is an example of Linux *regressing* to better fit the model of Mac/Windows. We've already got a much superior installation method: APT. What we need is a simple GUI for APT (or Yum or whatever) not a complex "app folder" system. APT is about as simple as installation can get. You double-click a program, and its installed and right in your programs menu. No manually searching for an installer, opening up the "applications folder", dragging & dropping, etc. Think about it: that requires so many more extra concepts for the user to learn! They have to first understand the filesystem (many users do not). Then they have to understand the concept of installer images. Then they have to understand how to drag & drop (many users do not). Then they have to understand the concept of a special "applications folder." Contrast this to the a GUI front-end for APT. Users would just have to understand how to start a program (which they already do), how to select the program they want, and how to double-click. It reuses existing concepts so much better.

Re:Screw drag & drop

[HolyCoitus]

The thing that makes zero install interesting is that you don't have to install the programs as root and how easily it does slots. As a user who knows what I am doing and is in full control of his computer, I have no need for this. Someone like my mom or brother though, I do not want to be installing every program as root that fits their fancy. That's too much like Windows. It's better if they can install the programs they want that are easily deleted and can't effect anything but the user environment. That's what zero install is striving for, not the group of users that should have root access. At least, that's what I see the purpose being.

I'd also like to add, when I first saw this a while ago, I just glanced over it and said I have ports/apt-get/portage so I don't need this. However, even with a GUI, those programs would require a rewrite to do what zero-install does. I see it filling a purpose for a group of users. Choice is good.

Re:Screw drag & drop

[RdsArts]

Anyone who calls 'apt' a more apt installation structure has forgotten how most users use software.

Most people don't want to learn a new packaging system. Most don't want to wait for someone else to package a program into the repos, assuming they even want to package it. The problem with Apt is it relies on someone else saying 'oh, that's great, I'll make some debs.' And it only works for someone with Debian or a Debian-compatable system like Lindows, Xandros, Knoppix, et al. A AppDir works on any distro that has ROX installed, so there's no more bullshit with having to package programs for 20 distros, or 20 versions of a distro. No 'Well, your using RedHat 8.2, which had this RPM, so here's a recompiled copy that works with that version, but if you have 9.1 it uses THIS RPM, which needs this recompile, or if-.' You just drop the AppDir in, and it works. No muss, no fuss.

Additionally, to install a deb you need to be root. Most people don't want or need to use root. 0install fixes that, and AppDirs make it easy even without 0install.

With AppDirs and 0install, you no longer have any of the problems software on GNU/Linux does. (Packaging for a number of distros and pushing it to the user with dependancies seamlessly) Apt only fixes one of those problems.

Re:Screw drag & drop

[zpok]

That's the first time I heard a Linux user imply it's better to hide things from users.

BTW, I don't doubt APT is good (have no idea) but the OS X install process is as simple as it gets, anybody could do it, since you don't have to learn new concepts, all concepts are borrowed from the real world.

I don't know many Windows users (or non technical Linux users) who can manage an OS or even application install - without running in weird problems, I know no mac user who can't and doesn't do those things on his own.

Re:Screw drag & drop

[be-fan]

Most people don't want to learn a new packaging system.
With APT, they don't have to. They just have to be able to double-click on the program they want. I've seen lots of Windows users who love the concept and wish Windows had it.

The problem with Apt is it relies on someone else saying 'oh, that's great, I'll make some debs.'
Isn't that true for installers as well? Somebody has to make those too.

And it only works for someone with Debian or a Debian-compatable system like Lindows, Xandros, Knoppix, et al.
Ximian has a nifty tool called Build Buddy that automates the process of generating packages compatible with not just RPM and DEB systems, but Solaris and HP-UX package managers too.

Additionally, to install a deb you need to be root.
This needs improvement, yes.

Re:Screw drag & drop

[be-fan]

That's precisely what APT + a GUI does! How could it possibly get any simpler than just double-clicking on the application you want? The Mac installer mechanism requires so many extra concepts. They need to understand the concept of an installer package, app directories, drag & drop (the majority of computer users do not understand that, because Windows doesn't use it very much), and the filesystem. Selecting an app in an APT GUI just requires knowing what app you want, and how to double-click.

Re:Screw drag & drop

[RdsArts]

With APT, they don't have to. They just have to be able to double-click on the program they want. I've seen lots of Windows users who love the concept and wish Windows had it.

Your assuming that a deb was even made. This requires the programmer A) has debian, and B) wants to make a deb. Or that someone else will make one. Which brings us back to the original problem.

Isn't that true for installers as well? Somebody has to make those too.

But you only make one. With debs you have to make them for Debian, then a RPM for RedHat, another for Fedora, another for Mandrake, another for SuSE, another fo-

Regardles, AppDirs aren't installers. They are self-contained, and you just click on the AppDir to run it, regardless of where it is. Uninstalling is just a right-click, and delete. Most just check that it's compiled if it's C/C++/etc, and runs if it's compiled or just run if it is in Python/Ruby/etc.

Re:Screw drag & drop

[Xoro]

Be-fan -- your deep unwavering belief is a sure sign you are missing something. There's no "drag and drop" involved -- zero install means zero install.

It's based on a sort of virtualized internet filesystem. Here is their example:

$ cd /uri/0install/www.gimp.org
$ ls
gimp1.2
gimp1.3
$ 0refresh
$ ls
gimp1.2
gimp1.3
gimp2.0

You never install, you just run, either by command line or some form of gui contraption. Of course, this system places a lot of faith in the upstream developers, but their website paints a far more interesting picture than the summary given here. Here, for instance, is a decent comparison with apt. Check it out.

It's not quite that simple

[SuperBanana]

Apple has had this for years going back to the old System 9, 8, 7, etc

Actually, it hasn't. Ask any Mac pro; applications started making "library" files that went into the System folder(or worse, programs like Norton Utilities insisted on putting libraries into the Extensions folder, which was not what Apple told developers it was for). Apple caved in and 9.x started sprouting "Application Support" folders, a "Libraries" folder, etc. Developers just couldn't wrap their brains around the single-file, applications-don't-mess-with-the-system-folder model. Often times, commercial programs would blatantly disregard Apple's filesystem guidelines. Often times extensions has such weird names, Cassidy&Greene developed an extension manager with a database of all the known files so you could figure out what the hell stuff was.

While you tout OS X as better than Linux or Windows, as an experienced long-time Mac user I saw OS X as a step down from the old MacOS with regards to filesystem simplicity. Applications now install stuff into zillions of different places. Virtually none of their installers ask if you want to install just for your user(ie using your Library, Application etc folders), or install system-wide(a few- VERY few- do). Application installers that have no business needing my password ask for it; why does Acrobat reader need sudo to install itself into Applications? Answer- it doesn't, but it's probably saving some prefs file somewhere it shouldn't.

Even worse...you can install packages using a "package system", but Apple will be damned if they'll give you a way to UNINSTALL a package, system or otherwise. Want to remove all the localization crap you forgot to turn off during system install? You have to download a third-party app to remove almost a gigabyte of files from your system, instead of just going into a "Software" panel and clicking remove. Windows has had it for years, with its only flaw being that it calls the developer's uninstall program, which often times doesn't work, especially if you've deleted the app folder but nothing else.

Another side effect of the multiple-files problem is added complexity; the # of files in the filesystem has ballooned enormously, because instead of an application being one big file with a resource fork, it's now at least 3 folders, and often times hundreds(or even thousands) of files. Moving an application used to be easy- you moved one big file, the Finder just did a straight copy very efficiently. Now it has to copy hundreds of small files, so it takes forever(and amusingly, copying just a bunch of raw non-app files takes about 5 times longer in the Finder than it does via cp or ditto).

Don't get too uppity about not having a registry. OS X uses a number of preference files, and even though they've changed to XML and the like, users are seeing the same problems with OS 9- corrupt preference files causing odd behavior. Remove the naughty pref file, things start working again. There are now third party utils that specialize in checking these prefs; if they can do it, why can't it be part of the bootup process?

Oh, and lastly- Apple has made it even more difficult to make a boot disk for your mac to do disk maintenance. It used to be you just copied over your system folder, removed all the extensions, control panels, prefs, etc you knew you didn't need. Now? You need some stupid shareware program to do it, and half of 'em still haven't been updated for 10.3.

Re:It's not quite that simple

[jc42]

Application installers that have no business needing my password ask for it; why does Acrobat reader need sudo to install itself into Applications? Answer- it doesn't, but it's probably saving some prefs file somewhere it shouldn't.

Exactly. And you have no way of knowing what it's doing with that password. If you're hooked up to the Net, chances are it's (then or later) being cached somewhere inside apple.com, too. Do you know of a way to convince me otherwise? If not, a sensible person would just assume that the password is now known to Apple.

Similarly, when I first got my Powerbook, it had to be sent in for repairs after about a week. (The screen wouldn't come to life.) They wanted my password, of course, and I gave it to them. No problem, I thought; when I got it back, I'd just change my password.

Lotta good that did me. Yeah, I can use my new password when I log in. But nearly everything in the system that asks me for my password will only accept the original one. I've found a few places that packages cache the password, and changed those. It lasts for a while, then one day it wants my original password again. I've found it necessary to keep a record of all the passwords I've used, because I generally have to try them one at a time until I find which one works with a given app.

Your password is cached all over the place by OSX packages, so the only sensible approach is to assume that it's public knowledge, at least to Apple insiders.

This is one reason that I'd never use OSX for any sensitive applications. I have to assume, from the way it handles passwords, that OSX systems are open to anyone at Apple, and to anyone able to bribe the right people at Apple, and to any intruder who knows where they are cached on my machine.

I'd like to be proved wrong. But a mere assertion that I shouldn't worry my little head about it won't convince me. I want proof.

So far, I've never seen linux software playing fast and loose with passwords like this. I mean, mozilla will cache passwords for you, but it asks,you can say "No", and it apparently honors that. And it doesn't ask for local passwords, only those demanded by web sites.

Also, there are some linux apps that ask you for the root password because they need to run something as root. But you never have to give the root password. You can always kill the app and start it again under sudo. Then it won't know the password, and won't ask for it because it already has the right permissions, so you know the password couldn't be cached.

Re:It's not quite that simple

[zhenlin]

Applications do not cache passwords. If you see the nice prompt asking you for an administrative password, it should be coming from the system. (There are ways of verifying this... Set your account to use the Blue colour scheme, set your (real) root account to use the Graphite colour scheme. Any dialogue boxes or windows with Graphite widgets are running as root)

As for asking for the original password, that is because of Keychain. That one is encrypted with your original password.

As for apple.com caching the password... Well, it is quite simple to prove/disprove that: put the OS X machine behind a firewall, and log any attempts to connect to a machine in apple.com network.

Microsoft had it and lost it.

[FreeLinux]

Microsoft had this in the very beginning. It was called DOS and DOS applications were completely self contained. When an application was installed all of its files remained in the applications own directory. To move an application, even to another PC, you simply copied the directory. To delete the application you simply deleted the directory.

Then Microsoft got smart (too smart for their own good) and decided it was more "efficient" to use shared libraries and that all such libraries should be kept in the %SYSTEMROOT% folder. This meant that applications stored files in one directory, libraries in the system directory and configuration files who knows where. That's better, isn't it?

After that Microsoft decided that it was too "troublesome" to have all of these separate configuration text files. They got smart here too (again too smart for their own good) and decided that it would be so much "better" to have all the settings in a single monolithic and monumentally fragile registry. (Watch out Gnome)

After all that, installing and removing applications became a nightmare. So they decided that it would be best to have a package management system that managed all installations and removals. They established standards that required the proper use of this package management system for the application to be "Windows certified". Unfortunately for them the package management system isn't so great, especially when it comes to the registry and while many vendors do obey the "Microsoft standard", many do not. In fact, the worst offender for not properly using the package management system, and there by polluting PCs with monumental amounts of cruft, is Microsoft themselves.

So, now Microsoft is trying to implement an "even better" system with their .NET strategy. One that installs applications into their own directory for easy management and removal. A new system that they conveniently choose to forget, is just like the system they used in 1982! Ooh, ahh. Consider me un-impressed!

Re:Microsoft had it and lost it.

[nathanh]

Yes indeed! Gnome seems to have a strange desire to mimic the bad sides of Windows while claiming to be an alternative. I'm not saying Gnome is worse than Windows, but seeing things like a registry-like configuration system (that, although it's more "open" due to XML, actually has a per-user daemon associated with it) and an extra virtual file system layer, makes me worry very much about its future course.

Except gconf is nothing like the Windows registry.

The Windows registry is a single file (the infamous REG.DAT) which is a single point of failure. The keys are undocumented thus leading to large 1000+ tomes describing the well-known keys but many keys are unfathomable.

The gconf "registry" is an illusion. Gconf files are all separate. Go look in ~/.gconf and see every application has its own file. If any file is corrupted, it only affects that app. All the other files are not corrupted and other apps are not affected. Also the gconf schema permits human-discovery of the keys and values; the developers can attach a textual description to every key.

The gconf "registry" is nothing more than a formalisation of rc-files (more commonly called dotfiles). Instead of each rc-file having a unique format, all gconf files are XML with a known schema. Instead of scattering rc-files randomly through ~/ with strange names, gconf files have a consistent naming scheme. Gconf is hierarchial, self-discoverable, and has event triggers so applications can receive feedback if values change.

But gconf does not throw away the benefits of rc-files! Gconf files are still human readable, they are still separate files, you can pick them up and copy them around to other machines, etc. Gconf files are entirely unlike the Windows registry. It's a testament to the quality of the illusion that you saw gconf-editor and thought "it's a registry" but it's just an illusion. You are really seeing a tree view of separate gconf files.

Factual clarification, the gconf backend can be swapped, so in theory you could have a single monolithic windows-registry-alike backend. But in practise the separate files are more convenient.

Clearing up a few things...

[tal197]

I'm the author of Zero Install (and much of ROX) so I'd better clear up a few points here.

The main one is that there are actually two installation systems being discussed in the article:

1. ROX uses application directories (bundles). That means that instead of downloading gimp.tgz and then copying the files inside it all over the place (/usr/bin, /usr/share, etc), they stay in a single directory and you access them from there. That allows drag-and-drop installing, and uninstalling by deleting the directory.
2. Zero Install is a caching network filesystem, where all software is available at a fixed, globally unique, location (like web pages).

ROX application directories can be made available via Zero Install. In that case, running the application is a lot like running a program from a network share (but more aggressively cached). Or, you can DnD them onto your local disk manually (without Zero Install).

You can also use Zero Install for non-ROX type applications.

Secondly, when we say that application directories are self-contained, we mean that a single .tgz download corresponds to a single installed directory. Application directories can (and do) still depend on shared libraries (possibly other application directories).

Without Zero Install, after installing an application by drag-and-drop, running it may tell you that you need to install some other library before it will work.

With Zero Install, the application just tries to access it from its fixed location (URI) and it gets fetched.

Plugins break this model

[renehollan]

Like so many package management models, this one has benefits (simplicity, package isolation, multiple package version coresidence) and drawbacks, the biggest one being package isolation, also an obvious benefit.

The trouble stems if you have some kind of base package, which is extensible via some kind of plug-in architecture, traditionally implemented with DLLs under Windows, or shared object library repositories under Unix and varients. Do the plugins form their own "application" or are they part of the application which they extend? What if I want to manage groups of plugins from a common source, independent of the applications extended? Do all applications have to be so isolated that they can only rely on a common base operating system that can't be extended by third parties (which would then be locked into their own application spaces)? What about multiple users sharing the same applications: will their saved files be intermingled?

Blech. Sounds like the cure is worse than the disease.

But, nevertheless, the idea of organizing independent applications in a convenient hierarchy is a desirable one. The trouble is that the traditional filesystem only offers a single hierarchy in which to organize them and so we struggle to determine the best hierarchy to use. We really need to organize sets of files that compromise a related unit ("file set", if you will, and "application file set", for the specific case of end-user applications) in multiple hierarchies: a new one created for the file set being added, and existing ones that the file set affects.

"Symlinks!"

What's that?

"Symlinks!"

Well, O.K. symlinks kind of solve this problem: pick a cannonical location in the file system for your file set and symlink secondary links to the appropriate files. This is a good idea, and has been used for ages to separate the reference to a file in the filesystem from where it is actually stored, but there are drawbacks:

1. Symlinks are one-way. Typically you'll have an application directory full of files and subdirectories, and a bunch of links into that directory tree. What happens if you move or delete entries? Oh, woe to the who has broken symlinks.

2. The context in which the symlink is interpreted may restrict where the target may be. Consider startup scripts added under /etc/rc.d/... They' don't do much good if they link to files in filesystems that haven't yet been mounted. Some restriction to where things have to be canonically installed depending on how and when they will be used is apparent. Fortunately, we generally don't have complicated hierarchies of what parts of the filesystem are mounted, but rather just a few: boot, locally mounted, remotely mounted. So, this problem is managable: we can inagine /opt and /usr/opt: the former available on the root filesystem.

3. Application interaction. The trouble with having one application extend the capabilities of another (and the base O/S can be considered as "one application" from the perspective of third party software providers, other than the O/S provider) is that adding, moving, or removing files can or should affect running applications. Ideally, an action which would leave a symlink dangling should be picked up by any running applications that might care and either delayed until the application can cope, or vetoed. (And, I suppose, --force and --async are your friends here). Current practice in most package managers is to have pre-install, post-install, pre-deinstall, and post-deinstall scripts that try to deal with this inter-application issue. The problem is two fold: (1) the things necessary to be communicated to other applications are varied, and (2) the manner in which they are communicated differ between applications (never mind different versions of the same application). Ideally, the inter-application interface that deals with new, removed, or relocated external files should be (a) thin, and (b) supported by t

Re:Plugins break this model

[renehollan]

The FHS (File System Standard) is an attempt to provide a standard way of organizing the various parts of components, and limits the number of directories that need to be managed for each third party application.

It's a good start -- I've used it as the "official" organizational standard when building an internal custom GNU/Linux distribution.

But, it still enforces a particular hierarchy, generally to keep the traditional operating system components playing nice as new applications are added. There is no guarantee that it will be the most appropriate hierarchical organization in all cases: what about multiple versions of different applications that one wants to install simultaneously and their interdependencies? What about forked applications with different version number namespaces?

While the FHS is good, and useful, it is but one hierarchy. To impose it is not good geek style, though neither is it wise to reinvent a perfectly good wheel. What we really need is a way to organize the files that make up applications in multiple hierarchies, as appropriate, letting each application also define an application-specific hierarchy as appropriate for it's novel organizational needs. This does not, of course, mean that application must define their own hierarchies -- emphasis should be on using existing, perfectly functional ones (not the least of which is the OS core, generally represented by something like the FHS) where possible. Leverage and reuse is the name of the game here.

The issue really becomes one of managing all the different file hierarchies, and the effect that a file change or removal has on all the hierarchies in which it participates. Package management addresses these issues in the package management space, or hierarchy, as it were, but I find that it does so as a layer above the filesystem, requiring an all or nothing approach to reap the benefits. Furthermore, as application packages all installed "above" a core operating system, it strikes me that the core operating system should provide some facilities to simplify applicaiton interaction.

I'm not sure that this means moving package management into the O/S and adding a layer of insulation above the filesystem. Instead, files in the filesystem should have attributes reflecting the various hierarchies or views as the parent responder suggests, in which the file participates: the file and directory hierarchy is but one such view, after all, and this view remains a useful one.

I keep thinking that "callbacks" to application managers that can be registered on individual file changes within the filesystem remain the appropriate architectural model on which to build. Note that I would not necessarily think that individual applications be permitted to directly manage common "hot" files, like configuration files under /etc: the formats differ (though an XML-ized /etc can help here, bootstrapping it is a hassle). Instead, the O/S provides a set of interfaces to manage the configurable aspects it offers: /etc/services, for example, does is not generally edited by packages installers and deinstallers, but rather, an O/S facility is provided to manage changes to it, and other such configuration files: applications, after all, should know the configuraion changes they wish to make to other applications or the operating system.

This reduces the filesystem callback requirements to ones of create, move, or remove alone, and not change. That should simplify things.

Food for thought...

Explinations?

[t_allardyce]

Can someone actually explain why we use the unix file structure still? (ignoring backwards compatability and any stupid hardcoding) sure its nice having libraries and docs in various organised places, but surely theres a better structure that makes more sense for everyone and could still be technically superior? or maybe im wrong and unix filestructure is just so good i dont fully understand its hidden clockwork beauty yet?

Re:I thought we wanted people to reuse code?

[tal197]

Talk about encouraging waste.... The article states:

The apps are all self-contained in their own directory; binaries, docs, source code and all. * * * This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial.

What happened to the idea that we wanted programmers and users to share libraries and code? To solve rather than avoid dependancy problems?

Applications are self-contained in that everything from a single package is in a single directory, rather than being spread over /usr/bin, /usr/share, etc. They can still depend on other packages.

Without Zero Install, this means that although installing an individual package is quite easy, you may then have to install dependant packages in a similar fashion. With Zero Install, you get automatic dependancy resolution and freedom from install scripts.

Managing configurations ...

[vinod]

After install issues, the next pain in managing application is in its configuration.

Sample configurations for specific type of deployment (such as home use, enterprise, high performance etc.) are extremely valuable.

A similar mechanism is very much appreciated - though this also requires active involvements from user community.

-vinod

OS X package?

[zpok]

So if I'm right, part of this article is about something akin to OS X packages? You install an application by dragging-dropping it somewhere (preferably the Applications directory) and un-install by unceremoniously dropping it in the waste basket.

And if I get it, just like in OS X, this doesn't mean your application can't use or install other resources in the Library.

Pretty cool, that's 90% of my Linux gripes gone in one big swipe. I hope this can become mainstream. It also means I can stop posting on the importance of simple installers ;-)

Re:Why I dislike about installing softwareunder Li

[jptxs]

I think the idea is that the type of user we're talking about is not likely to be compiling from source. If deb or rpm gave the same sort of freedom as your average configure script, then we'd be on to something...

What about shared libraries and memory?

[rollingcalf]

I like the concept of keeping all the files for each app fully contained in its own directory, even if it means some libraries will be redundantly duplicated across the disk. Disks nowadays have huge gobs of space and are cheap.

However, memory isn't so abundant. When loading up an app, is the system intelligent enough to recognize that a given library was already loaded into memory from a different directory, and therefore it won't load another copy of the same library?

Re:What about shared libraries and memory?

[Sax Maniac]

Probably not, but I recall reading that modern virtual memory systems are so good, they reduce the actual benefits of dynamic libraries down almost nil.

I think future versions of Windows know how to scan the disk periodically, find redundant files, and essentially link them together automatically. That's pretty cool - you deliver your app with FOO.DLL version whatever and drop it in your app's directory. If someone else installs a FOO.DLL in their app's directory that matches the exact same bits, the system coalesces them together. Then you upgrade application #1, which installs a modified version of FOO.DLL, and the OS unshares them.

Yeah, it's copy-on-write for files, but the new bit is the auto-coalescing.

To me that sounds like all the benefit of shared libraries with none of the DLL hell. It will be interesting to see if it actually works.

Re:What about shared libraries and memory?

[swb]

I'd like to see all apps ship with whatever library they came with, located in the apps directory. When an app launches, have the OS check to see if the libraries required are loaded. If they are, don't load the local libraries, just the unique ones. Make it a run-time option for all apps of something like "Always load local libraries" in the off case that there should be a problem.

This way you could still have systemwide shared libraries that are updatable, but it wouldn't be manditory to use them if it was a problem.

I think that's largely what you're advocating.

Wrong

[RdsArts]

You make the assumtion someone knows how to compile software. The massive, overwelming majority do not.

Most just want to grab a binary, or a AppDir that will compile itself without you even needing to know how, and run it.

Let's stop pretending it's the user's fault for not knowing how to compile software, and move to something that works across the board already.

Moderator trolls.

[expro]

It is easier for moderators to mark things as a troll than to accept an OBVIOUS fact, since it flies in the face of the religion surrounding infallability of Apple.

But for a critical thinker who uses a personal OS X machine, (especially who has installed a fair amount of software):

Go to to your Applications directory and ls -la to see just how many are owned by the primary user instead of root. And then see if the primary user happens to also be a member of the Admin group, which has write access to all the files there owned by root/admin. This also applies to the Applications directory itself.

On my powerbook, taking installation defaults, over 95% of the apps installed in the Applications directory are writable by the primary user.

This seems inexcusable from a virus security perspective.

On Linux, 0% of my apps are writable by the primary user.

Re:Moderator trolls.

[.com b4 .storm]

On my powerbook, taking installation defaults, over 95% of the apps installed in the Applications directory are writable by the primary user.

This seems inexcusable from a virus security perspective.

That sounds reasonable, until you remember that such places are writable only after the user authenticates. This means entering the administrator password, allowing installer X or operation Y in the Finder to go ahead and write to that directory. I don't see how that's any less secure than what most moderately experienced Linux users do - ./configure ; make ; sudo make install

Re:You should get out more

[UserGoogol]

A program, not to program. The noun, not the verb. By this, he meant that people are far more likely to be using Internet Explorer or Quake than the stuff like the Dock and Finder, which are only used for short periods of time while they make their way to the programs.

Which is basically true. I suppose most people could probably even manage to use Bash to launch programs if they could still run their other programs just as well.

Technophobes Showed The Way ! (as usual?!)

[spamhog]

>> Deleting the application along with all the other misc files
>> is as simple as removing the directory it's contained in.
[...]
>> This is something even the greatest of technophobes could understand and use with ease

This is an understatement.
This is what the greatest of technophobes ALWAYS BELIEVED TO BE THE CORRECT PROCEDURE FOR UNINSTALLING APPLICATIONS.

Kudos to developers for aligning reality to perception!

static or what?

[zogger]

could you please explain the difference (static or whatever) for those of us who might not know? thanks in advance! Whichever, I'm all in favor of apps that just work and not needing dependencies.

Re:static or what?

[Afrosheen]

Here's the difference in a nutshell.

Statically linked binaries include all the libs and dependencies along with the binaries used to actually 'run' the program in one fat package. Depending on what it is you're packaging, it can add a shitload of weight to the package.

Dynamically linked binaries expect your system to contain dependencies already. They have the benefit of giving you a small, tight package but don't always work right away. IE you, the user, have to hunt down packages it needs or apt or rpm has to handle that for you.

It's a trade-off either route you choose. Statically linked binaries add bloat but usually work great without user or system intervention. Dynamically linked binaries are smaller and bloat-free but depend on you, your package manager or something else to make sure it works.

The typical stance of developers has been to build good packages that are small and dynamically linked. After all, what's the point of having 20 copies of a common system library that you may have had since your OS install? That's just bloat. Ultimately, the best developers, in my opinion, give you the choice when you go to download. Click here for static, here for dynamic.

Just *how* many libraries are we goinig to include

[psi42]

Let's say you have downloaded and installed some 20 programs packaged as Appdirs. If each package is supposed to be virtually self-contained across all distros, you're going to have to include _all_ dependencies. And therefore you lose all advantages of having shared libraries. You've got 20 copies of libc, 10 copies of gtk, 15 copies of X runtimes, and so on?

How big is each appdir?

Re:What about security?

[tal197]

If just running an application can send it stalking over the Internet downloading and installing libraries, what happens to security? Or is this automatic install only for objects on the LAN repository?

System security? Nothing. All code runs as you. As for your own security, it doesn't allow any attack that couldn't have been done without Zero Install too.

Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was an important goal for Zero Install.

See The Zero Install system

Partial solution

[plj]

Remove your account from admin group, but keep it in wheel group. That way Finder* will ask you for admin/root passwd when you drag a new app bundle to Applications folder, so you can no longer put just anything there. This is what I'm doing.

However, it still seems that the folders created there are owned by you, so this is rather imperfect solution.

Fast user switching is theoretically a better one, but not on my 12" PBook with 1024x768 resolution due to an almost Dock-class UI design failure.

*) A Panther feature. In Jaguar you're forced to use a terminal in this case.

This is just a silly statement

[Moderation abuser]

If every application has it's own directory, your PATH will be huge and the system will have to search each one of the PATH entries until it finds your application when you try to run it. How many searches before it finds it? 10,20,200?

Oh, sorry, you *only* use a GUI and so click on the application. Well not everyone solely uses a GUI or wants to go searching through dozens of application directories for the specific binary which runs an application.

Re:This is just a silly statement

[kundor]

ln -s /opt/*/bin/* /usr/bin/

Re:This is just a silly statement

[wheelgun]

I don't think it is a silly statement. I stopped using Linux because of all the library dependancies. It was absurd- every application I wanted to install requried a library I couldn't find or figure out how to use. And then there were the applications built to work with specific distributions (and hence not others). Don't get me started on those!

Directories ? Why not files !

[John.P.Jones]

Here we are talking about confining an application to a directory, but the user, or other apps on the system don't care about what's 'in' that directory. Only the executable knows and/or cares about the structure of this 'directory'. So why not make it a single file, a kind of unmounted file system that only the executable mounts and reads and writes to, as part of the loading process. A persistent store for both code and data, very general very powerful.

Now as for shared libraries, this should be handled by a COM broker, with Apps registering uses of component API's. If no app wants an API then all implementations of that API are unnecessary and can be removed.

Re:Why do we have shared libraries at all?

[kundor]

You can upgrade to new versions with bugfixes and security fixes without recompiling every single program on your system.

Knoppix

[devnul73]

Linux already has something like this (minus the cache on demand) in the form of Knoppix + Klik
All the files are stored in a single directory under your home directory which can be on a USB drive or anything. It also works with a hard-drive install of Knoppix.

Random Thoughts on Libraries

[spun]

For production servers running many applications, dynamic libraries can be much faster. With static libraries, the OS must load a seperate copy of each library every time a program is run. With dynamic libraries, I believe, most operating systems load the library the first time a program requests it. From then on, programs use the copy in memory.

In older versions of Windows, this led to some really hard to track down flakey behavior. Suppose one application used a non standard version of some system library, which it keeps in it's folder. Load that application first, and other applications, using the non standard library, might crash. Load something else first, and the one application might crash.

This is one reason Linux libraries have version numbers. Ever look in your /lib or /usr/lib folders and see two or three versions of each library like: libfoo.so, libfoo.so.1, libfoo.1.2.87? Notice how the first two are links to the third? Ideally, programs should link against the library name with the major version number, and libraries should change the major version number if and only if they change the interface.

Because no one does this consistently, we have to have things like libfoo2.so.2.2.17 so that libfoo version 2 doesn't bork stupid programs that linked to libfoo.so instead of libfoo.so.2. This, in my opinion, defeats the whole purpose of having those symlinks in the first place.

Wherever you go, there you are. Wherever you are, libraries are borked. This is why the grandparent poster links his libraries statically. Might be a touch slower and use a bit more memory, but you know it is going to work, wherever you go.

Grammer Trolling my own post

[spun]

I hate it when people don't use apostrophes correctly. It's one of my pet peeves. "It's" gets an apostrophe when it's a contraction of "it is," and loses its apostrophe when it is possesive.

I even previewed, but it's an easy one to miss.

Re:You should get out more

[AstroDrabb]

Look what you get with that $700 from Apple. The eMac is dog slow and has little room to upgrade. While the G5 may be a snappy processor, the G4 cannot hold a candle to Intel and AMD.

My wife's great grandfather (81 yrs. old) just "got a dell dude" for under $700. For that price he got a 2.2GHz P4 with 256MB memory, 40GB 7,200 RPM HDD, 10/100 nic, winmodem, an OK Intel "extreme" graphics controller, 17" monitor, keyboard, scroll mouse and a scanner. Apple does not offer anything in the _average_ price range of todays computers.

I just built my own computer for a little under $500 by just buying parts I needed. AMD 2500+ w/fan, 512 MB PC2700, 120GB 7,200 8MB cache HDD, 64 MB Gefore 3 Ti 500, DVD +- R-RW drive, new case and new KT600 based mobo all for under $500. I was able to shop around to get the best price, a feature not available from Apple.

What does Apple offer for under $700 that can perform just as well? Nothing. IMO, a good performing Mac does not cost less then $1,200 or so.

Apple put themselves into a niche market based on price and they seem happy there.

And if you want to use Mac OS X on a new Mac, buy an eMac for $799

I thought about getting an eMac before I purchased parts to build a new computer. However, in the end, it came down to getting the best value for my money. I would have had to spend $300 more for the eMac and had a computer that was considerably slower then what I could get in a PeeCee for $500.

Libraries, Preferences Other Issues. (my mini FAQ)

[spun]

Seriously, this rocks. Yeah, yeah, sure. Other projects have done things like this before. But I love this idea even more than Gentoo's system, which also rocks. So I read some of the site to try to answer some of my own first asked questions.

Q. Do I have to add a bunch of crap to my $PATH?
A. No, you just use a shell that is application directory aware, and it will find the binary just fine if the application directory is in a directory in $PATH.

Q. Will it let me recompile critical applications, either to patch them or optimize them?
A Sure. Keep three different verions of Apache around, one with mod_perl, one with mod_rewrite, another with mod_php. Optimize for your new Sexium X CPU. Turn on full foo support, even though it's not recommended!

Q. What about apps with hardcoded pathnames?
A. Edit and recompile. HAND.

Q. What about libraries?
A. (From this page on the ROX Application directory system.) Applications link to libraries in /uri/0install. If the required version isn't there, then instead of reporting an error (as traditional applications do), they run 0refresh. Software can be uncached when it hasn't been accessed for a long time (eg, months or years). If it's needed again, it gets refetched.

Q. What about versioning?
A. You can keep different versions of an application around in different directories. I couldn't find any information regarding library versioning. Hopefully libraries in /uri/0install have directories by major version number, and ROX applications are linked correctly. Prepare to have much fun with compiler and linker flags finding all your include files and libraries when you convert your application to ROX.

Q. DND Saving? What's that?
A. Rox aware apps support dragging files from a save box to a directory in a file browser to save. Finally, someone does this right.

Re:Why I dislike about installing softwareunder Li

[Davoid]

RPM does have this ability:

rpm -ivh --prefix ~/whatever packagename.rpm

That only works IF the package is "relocateable". Some packages, quite naturally, are not but most apps will (or should) be.

-DU-...etc...

NeXT .app directories

[madonnell]

NeXTstep utilized a very similar sounding packaged application directory approach. There, if you "ran" a directory named "XXX.app", it ran the executable within that directory named "XXX". I was just discoving xnix, so I don't remember all of the details, but I believe it used static libs, and depending on how you manipulated a .app it worked like a directory or as a unit. Putting the parent directory of XXX.app in the path allowed execution of the program. It did work quite well, and I found the idea very effective compared to Windoze, Dos, and SunOS approaches. You could just drag a package around, and the file compartmentalization was quite a step forward. I eventually hacked a similar capability under Dos using 4dos and executable extensions.

Why not solve BOTH of Linux's major problems?

[alizard]

Combine this with a way to read Windows peripheral drivers and this could solve Linux's worst usability problems. Why not?

The big problems are to make it possible for an average user to install and deinstall first applications, then, peripherals.

In general, any OS is going to need the same kind of information from any class of peripherals. Why can't someone write software to decode the Windows driver information formats and turn the information into something that can be used to configure Linux to use these peripherals?

If someone plugs a USB scanner or digital camera or printer in, why shouldn't Linux ask for, first a native Linux driver, and if this isn't available, a Windows driver disk?

Wouldn't it be nice to be able to buy peripherals based on price and performance and not have to worry if it's usable with Linux or not?

Wouldn't it be easier to write a translation application or several than for the Open Source community to write thousands of drivers individually and for the rest of us to attempt to find them and then try to figure out if that driver will actually work with the distro one is running?

encaps

[menscher]

Whoever thought this was new has obviously never heard of encaps. Basically the same idea, but it's been around for about 5 years longer. Look at www.encap.org for starters. (I'm not going to write a lot since nobody will read this anyway.)

Re:Sounds great, let me try

[dr.badass]

It's ready!

This isn't so 4 years ago, it's 12 years ago

[ceez]

it might even be 15 years ago.

At CMU they had this thing called AFS, depot, and emt. It did all of this, and more.

openAFS, Coda, or even NFSv4, depot (or stow) could all be used to really build something interesting. (emt could be improved, but it wouldn't be hard).

Cool idea, but why just stop at the desktop?

Re:You should get out more

[nathanh]

Anyway, it doesn't really matter since I still haven't met anyone who paid for MS Office, I only know of big institutions licensing it.

I'm sure most people you've met haven't paid for Microsoft Office, which merely strengthens my point. Most people pirate their software. That's why $500 PCs seem like such a bargain; people aren't paying for the software they install on it.

What's funnier is all the people, including yourself, trying to tell me about OpenOffice (as if I didn't already know). Face facts, people. The average person installs a pirated copy of Microsoft Office. Stop fooling yourself because you aren't fooling anybody else. You and I both know that 99% of those $500 PCs are going to be running $2000+ worth of pirated software within the week.

The point, as always, is that with a Mac you are fully legit from the start. With the $500 PC, unless you run Linux and OpenOffice (which by all reliable sources is less than 1% of the desktop market) then you're up for at least another $500 to get the basic necessities of software. Anybody who mentions "OpenOffice" and "Linux" is ignoring the reality of the situation.