Slashdot Mirror
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."
Someone should really point this out to Steve. I think using this type on installation on Macs would increase useability by leaps and bounds.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
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.
-- johntracy.com, because everybody else is wrong.
We haven't had a "Linux is going to take over the world" story in such a long time....
http://www.beyourowneviloverlord.tk
http://www.frozenchickenthrowing.tk
http://www.killercamel.tk
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?
For anybody. It emulates the best aspects of the mac's "packaging" system (bundles) while also making it easy to get new stuff.
/software/openoffice /usr/software to install" instead of ./configure && make && make install. :)
... assuming they get over that, I'll be very happy once this is released.
Hopefully, this takes off in more of the 'newbie oriented' distros so that we can say "Just type cp
I still would like to know how they plan on fixing library dependencies, but
Disc space.
Actually, as cheap as it is these days, I guess, why not ?
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
Now I can make my X-box even more useful
... reminds me a lot of Mac OS X where apps come in a "folder package".
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.
Sounds like the kind of thing that'll encourage similar behaviour to Windows whereby things get installed without the user "knowing" or "noticing". How long before Gator had something out via this? Although, that said, it does look very nice and I will be trying it out with a view to adding it to my "Convert to Linux" arsenal on the friends and family front :)
You can create a directory and put your app there, because Linux is modular. What a useless story.
Anyone have waybackmachine links to DOS or Mac installation routine instructions? It might help this project a lot!
This is the true power of Unix + X.. Running applications remote from the workstation..
.. most everything that a data center does, this improves it..
This aids in system management, resource control, data security, platform independence,
It *is* the future.. ( and ironically the past.. remember VT100's and 3270's ? ) as is its the right way to do computing..
---- Booth was a patriot ----
Yes it's a good move/idea. Combine it with the new storage system in gnome, and you could really have something cool. This would also make Click N Run type functionality from websites a lot easier to do.
People don't exist to serve systems, systems exist to serve people.
Sounds good to me. I love how even .Net gets into this game with Microsoft touting simple 'xcopy deploys.'
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.
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
epkg is a related utility that I found very useful...
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?!?
It's called Ghost. It's called unattended installs. It's called Zero Touch BDD using SMS 2003, PXE and Windows PE combined with RIS, disk imaging and group policy to deploy applications. Glad Linux is thinking the same way.
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.
People don't exist to serve systems, systems exist to serve people.
"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.
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? Hopefully they are not putting code into virus-writable directories, as often happens on Apple.
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).
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.
People don't exist to serve systems, systems exist to serve people.
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.
.Net still have to catch on into the desktop, it is very much real on the server side. Gotta love it!
Delete the directoty and the app is gone.
This is here now, and altough
No one has to be the main server, let groups of people host to each other. Use mirrors, or use P2P on the school or work network. Client server need not be used in a LAN, or on college campus where I'm sure theres a lot of other linux users. For people at work I'm sure they have their own private servers. For people at home you pay a fee, big deal.
People don't exist to serve systems, systems exist to serve people.
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?
With the exception of agent, I don't think anything in my program files stands on its own. You have the registry, documents and settings, program files\common. Even \windows and \windows\system32 has dependencies. In short, application partitioning on windows is a complete mess. I just migrated an XP box to 2003 and you will spend most of your time recreating settings that have no consistency as to where you will find them.
I wouldn't want to try that over the Internet.
Maybe I'm missing something?
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?
Bitch to whoever decided that that app should have an installer.
If MS Office can be a drag and drop install, almost anything can.
--
the strongest word is still the word "free"
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?
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.
Installing different packages in their own directories... this is nothing new. /opt tree is for.
/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.
Indeed, this has been specified in the FHS (Filesystem Hierarchy Standary) long long time ago. This is what the
Indeed, I've always been wondering why major Linux distributors haven't been using the
"This is something even the greatest of technophobes could understand and use with ease."
Overstating a bit much? There are people out there, a surprising amount no doubt, that would have trouble using a system that consisted of one giant button on the screen if you didn't walk them through it. Most 'technophobes', and a great deal many of your average users probably as well, don't install software at all. Their computer comes with office, and a web browser, and an email program, and that's all they use. Or, if they do get around to installing something, it sits on their computer until the end of time. Once again this is an overstimation of how similar your typical technically knowledgeable linux user is to the average user, and in this case your average technophobe.
The application is Cached and is not downloaded on the second attempt. The moderator that marked you post insightful is a idiot.
Got Code?
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.
I agree, /usr, /opt, etc. is a helluva way to run a railroad. The OS should roll in, set up its big top and get out of the way of the actual circus - composed of primadonnas who won't be happy without their own vans and three feet of grass to tan on. Mac OS X does a fair job of this, but the underlying BSD Unix stuff is not safe to wander through without a guide. The fact that we're still using Unix twenty years after the Apple Lisa came out should tell us something about what sysops want. The fact that Bill Gates made billions with a cheesy product like Windows should tell us something about what users who pay for this stuff want. The rest is just friction.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
and you say linux isn't copying OS X.
I'm surprised OS X isn't mentioned at the top.
You only get the performance hit when you try to run an app that lacks local components for the first time.
It goes over the net, and runs it ( Yeah, slow loading, yadda yadda ). But as it's doing this, downloading the app, getting libs, etc, it's building a local cache. The second time you run the app, it uses the local copy.
So executing a app you don't have 'installed' installs the app. After that, it's just like running the app off your local hd.
"The apps are all self-contained in their own directory; binaries, docs, source code and all."
Does this violate the FHS?
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).
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Unless users in Linux start using IE, how exactly will gator do this? Is gator even open source? If it were open source and were a hiijacking program who would actually host it? Ease of use does not mean less security. OSX is doing pretty good with security and they are easy to use.
People don't exist to serve systems, systems exist to serve people.
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.
- Download the latest sourcecode and compile it? (~30 minutes)
- Download the pre-compiled binary? (~5 minutes)
- Just use the version you downloaded yesterday? (~1 second)
>3You've chosen to run the version you downloaded yesterday. Are you SURE you want to do that? There could be a newer version available. You can't call yourself a hacker if you don't have the latest version.
- Yes I'm sure. Just run the program.
- I might have mistyped. Show me the options again.
- Reboot.
>1Ok, but only because you insist.
Starting "/usr/bin/bash"...
This is the way MacOS works since day one.
This is the way Atari (TOS) computers are working since day one.
In fact this is the way almost any non-Windows non-Unix operating system works.
{{.sig}}
Yes, Mac OS X does this. Actually the idea is even more like the method I first encountered in NeXT. Yep, another development of Steve.
: /u sr/bin:/usr/lib
This is not to say it is a bad idea, in fact I happen to like the idea a lot. It would pracically eliminate concerns over what version of clib you needed. The installer would effectively do a "locate" for the presumed filename for the library, poll each copy found to determine what version is installed, if it finds a usable version it does a hardlink of that file into it's own directory. If no useable versions are installed, it downloads a usable version into it's own directory, and moves along.
The "path" for the program would look something like:
${APPLICATION}/bin:${APPLICATION}/lib:/bin:/lib
and so forth.
Hardlinking to the file should mean that if the original is upgraded, the install application would "delete" it from it's original location, which means that only that folder would loose a link to the file, all the other applications would remain hardlinked to the file.
Then again, I could be wrong.
-Rusty
You never know...
And how hard is it for the installer to set a cron job to run 'apt-get update;apt-get upgrade' at every logon or 24 hour increments thereafter? This requires _no_ user interraction - less so than Windows Update or whatever magical solution they were using on their last box. And if they really want a graphical solution then Synaptic is great for that purpose.
Also, what's the point of letting people use what they know? If F/OSS inherits familiar characteristics from proprietary software then it's going to bring some bad ones with it too - why have to wean them off it later when you can start immediately?
I guess you are talking about Africa and India? Because actually Korea and a lot of Asia have more broadband than anywhere else in the world and guess where the Linux market is making money? Canada has plenty of broadband, the USA even has plenty of broadband. I don't see where you come up with this. Diskspace isnt a problem and neither is internet access, but for people who have poor internet connections let them use an old version of Linux and old software to go along with their old internet connection. Why hold the rest of the world back because a few people in rural America still have 56k?
People don't exist to serve systems, systems exist to serve people.
If I understand it right, if I statically compile against a GPL library, that makes my app GPL'd. But I can compile against a shared object and it will not affect which licenses I can release under because I am only referencing GPL'd code rather than incorporating that code into my application. But with this 0install system I could use shared libraries and include those GPL'd libraries in the same directory along with their source and basically get the same convenience that I would by compiling statically? No more library version, dependency heck for my users? And the library authors who released under GPL still get what they want by allowing Free access for everyone to their code? And the only drawback seems to be additional disk space and bandwidth usage which continue to get cheaper and cheaper. That sounds pretty sweet!
Liberals call everyone Nazis yet they are the closest thing to it.
Security is an issue here. One reason that packages are spread across the file system is so that some of the file systems that are used can be mounted readonly or non-executable. I think that some common sense changes could be made to improve (newbie) usability of The Files System Standard, but being able to treat different areas of the file system, or program directories, with different attributes is central to usability and security. Also, NFS, again - for security reasons, is hardly the technology I would use to implement this solution.
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.
BLASPHEMY! Oops I mean "GNU/BLASPHEMY."
:-D
What you suggest is heresy against The Unix Way. Your punishment is say 5 "Hail Stallmans" and promise never to speak such evil of The Ultimate Filesystem again.
Seriously, I don't think the Linux kernel supports anything other than the standard Unix filesystem layout. Other than that, what you say makes excellent sense.
Microsoft's VP of Customer Service is Helen Waite. If you are having problems with their products go to Helen Waite.
Here here.
As one other commenter pointed out, this is the way things have been done on the glorrious Disk Operating System since DOS 2.0 some 22 years ago!
The headline for this story should be "Linux developer gets a clue".
Never underestimate the dark side of the Source
Why should anyone trust a given Zero Install site?
It may as well be called a Virus Install site.
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.
PigPog.
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.
People don't exist to serve systems, systems exist to serve people.
regarding installation which has come up in decades, besides the fact that Rox is one of the best desktops out there and highly overlooked,
I think this should become the standard way of non apt installation on Linux.
Just dump everything onto the hd and let the system configure itself, deinstallation is done by moving the installation to the garbage bin.
Since when is going back to monolithic applications a good thing? I thought the whole point of having a /usr/lib directory was to share common functionality. Or will everyone have to install all the libraries for everything they might ever need, since the app can't do it? I predict library version hell!
Where do you install kde, or gnome? X is going to have to change drastically to accommodate this, and I think we all know how quickly the Xfree86 guys move on something if it wasn't their idea. This is a nice idea for technophobes, but I don't think it is really practical for big applications, or an application using a shared library.
I like the idea of this, having used the same system on RISC OS - and I really miss being able to install something simply by copying it. It is also neat to have a cache from which things can be deleted at any time and refetched; the only problem is that every app needs to run a quick zero-install-check before it starts to make sure the libs are there.
Package systems like apt and rpm take a stricter approach: if you have the app, then you must need the libraries it depends on. If you remove the libraries then the app would be broken so you ought to remove it too. But you do have to use a special 'remove' operation to uninstall, rather than just deleting.
I would like to see Zero Install get integration with conventional rpm or deb packages, so that the package is fetched off the net and installed into its own directory, and then can be used (as a library or whatever) by Zero Install apps. In other words, a way to automatically wrap legacy packaging formats (and I do not mean the word legacy unkindly). Inventing another package format is doomed; a new easier way of managing the packages that hundreds of people are already building could take off.
-- Ed Avis ed@membled.com
Maybe they can work together with the ROX people since they have been doing something similar for a number of years now.
We've seen this all before, back in 1992 when Next first started using "bundles" for appication resources and treating them as executable files. It's good to see that the world is finally catching up, if 10 years later.
Macs have been doing this for years. And Windows programs can do so if they want to
Distributing and updating applications accross a 10,000 machine corporate environment is painful at best. My company has good tools, and smart people working with this. Still, apps with less than 50-100 users don't get a lot of attention - and the tools that manage app policy manage to periodically break them when they push other apps' updates. The basic problems mostly stem from 1) Dependency hell in windose. 2) Needing to push apps out - this pulls apps and dependencies, which is much easier to make work.
.NET apps. Most MS shops have a large number of legacy COM based apps giving them headaches.
If I wasn't stuck in a Windoze shop, I'd think about hacking this to support the type of application policies my company needs: Mary has access to applications A,B,C, etc, Allow zero-install to install only from servers a.mycompany, b etc. A major problem here is that the current security model appears to allow an end user to install anything. Sure, it can't run as root, but they can waste time playing freeciv! This could easily make redundant a team or two of poor schmucks who currently work with the tools that push out software.
Note that MS already has a variety of products in the works similiar to this. ClickOnce is the solve-all-your-distribution-problems widget in VS Widbey. Run-from-web and other tools already exist that are similar to this. Unfortunately, these only work with
My motto: "A cat is no trade for integrity."
You know, I saw this and said "fucking cool, man!" Package management has always been one of my least favorite things, and it sucks when you build something new only to realize that you've totally broken it. This is 10x worse when the package that breaks is, oh, say, RPM. (Fucking RedHat--Goddamn 8 and 9 were such crap.)
/usr/bin, or add each app directory indivually to the path? Neither seems particularly cool.
But I digress. Point is, I thought about using this on my laptop, which runs Crux/Slackware in a dual boot setup. But HTF am I supposed to use this intelligently when I've already got a package management system?
And wouldn't this mean that you have to either symlink all the binaries in each directory into
WHy is the desktop trying to manage apps, again?
Finally we have found the holy grail that for so many years all Linux users and developers have sought after:
.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.
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
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
maybe it's just me, but this seems to be following in dotnet's footprints.
whoops, forgot I was reading slashdot, forget I said anything.
Just why does running one of these servers make me start thinking of the alt.suicide.holiday suicide-method list?a q/index .html)
(http://www.depressed.net/suicide/suicidef
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
This is something even the greatest of technophobes could understand and use with ease.
You are giving people too much credit.
Do you love freedom??? Do you love freedom!!! DO YOU LOVE FREEDOM!!!!!!!!
Wondered when ROX would get around to getting this done - it's exactly like the system utilised in RISC OS (From Acorn) in the UK. You could install multiple versions of applications (and often did) - and then take your pick. It also makes it a million times easier to remove stuff (and install stuff as well).
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!
Insightfull my ass. ./configure --prefix=~/whatever
--- d'oh
To install to an alternate directory all you have to do is add prefix=/home/foo as a switch configure: ./configre --prefix=/home/foo
make
make install
What is amusing to me is that whenever the "Linux is too hard to install" argument comes up, I ask the person if they have ever installed windows. Invariably the answer is no. Frankly, I find a Linux install much easier.
That said, I hope that this argument goes on for a long long time. The longer it goes on, the easier it becomes to install Linux.
I think a face off today between a windows and a Linux install would end the argument once and for all in favor of Linux.
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.
---
Go look at:
http://www.csis.gvsu.edu/~abreschm/uafhs/
If people start adopting that, some of your worries may be over. Plus, it doesn't destroy any old systems or make shared libraries messy.
I think they are almost opposites.
Their where special files placed in each directory (!boot and !run)
There were special files placed in each directory (!boot and !run)
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.
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.
A deep unwavering belief is a sure sign you're missing something...
You would put the app in /opt/<package-name>, and then when you wanted to get rid of it, you could just rm -rf /opt/<package-name> (or /opt/<vendor-name> if you wanted to do it that way).
I don't know why Linux people insist on reinventing the wheel every few months.
Talk about encouraging waste.... The article states:
What happened to the idea that we wanted programmers and users to share libraries and code? To solve rather than avoid dependancy problems?
Doesn't this encourage a move back to the DOS days where applications didn't share code or libraries, and were completely independent of each other?
Then again, given how cheap disk space is, and how frustrating dependency problems are, maybe this isn't such a bad idea.
Only Women Bleed (Sex, Sharia remix)
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.
Please help metamoderate.
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.
.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!
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
> !boot was executed when the filemanager loaded the directory
Viruses heaven??
Not quite. You're thinking of the all-package-files-under-one-package-directory model. That's cool, and that's in OS X, but that's only *part* of ZI. But an example is worth a thousand flames. See here:
http://zero-install.sourceforge.net
Granted, the way you experience the download-open-run business on OS X is close, but the beauty is that because of the use of NFS, a remote directory (perhaps mounted under a directory like
Aditionally, they could make it so web browsing isn't necessary in many cases. An NFS directory entry provided by Adobe could be mounted under
AFAIK, OS X does not have that....*yet*.
The main one is that there are actually two installation systems being discussed in the article:
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.
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
You could've hired me.
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?
This comment does not represent the views or opinions of the user.
If you think that more people program applications than use the GUI, you REALLY need to meet some new people. They're called users.
And if you want to use Mac OS X on a new Mac, buy an eMac for $799. Or buy a used one on eBay. Either way, there are plenty of ways to use a Mac without spending $2,000.
"Linux" isn't copying OS X. Linux isn't a single entity. Linux developers aren't a hive mind. What's so very hard to understand about that?
What comes to ROX folks, they're quite openly stating they're copying RISC OS. Oh yeah, by the way, the ROX-desktop project has existed before OS X.
About 4 years to be exact, I guess you at least had the sense to get subject right, even if it was by accident.
It's not reasonable to require nontechnical users to compile their own software from source. They just don't know what they are doing, so as soon as something unexpected happens they have no idea how to deal with it. Considering how many open source projects totally or partially ignore --prefix (how would a newbie who's never compiled his own software discover that flag, by the way?) that's actually a pretty likely outcome.
I don't know... It sounds a lot like the way things were when most "Joe Users" used MS-DOS and knew only about 5 DOS commands. There was no such thing as "installing" software. If you had a hard drive (in the latter years of DOS, I suppose), you'd stick the program disk in your floppy drive and copy the files into a directory on your hard drive. Getting rid of the application was as simple as a few delete commands.
So why do we have DLL hell and all the other problems with installation and removal of applications? Code reuse might be the primary reason. The idea was that making lots of copies of the same code is wasteful on the hard drive, and I think that even now, when the cheapest drives are zillions of gigs in capacity, there is still the issue of RAM: The OS knows, when you load the same shared code from different programs, that it should employ a copy-on-write page for that code. But when you load exact copies of the same code stored in different locations on your enormous hard drive, the OS has no idea, and therefore, the RAM is being wasted. Multiply 20k here, 200k there by the number of programs you have running simultaneously (I usually have about 80 processes running at any one time on my desktop box, many more on my various servers), and you increase your memory requirements. "So buy more RAM" might seem like the solution, and it works, but it costs money.
What do I think about this Zero Install idea? If they do what I think they do with NFS, it's very innovative. Great idea for n00bies. I'll have to look into it a lot more to see if it's right for more "active" users as well.
This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial. You mean, like we used to do on MS-DOS systems?
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
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
I think, therefore I am...I think.
The idea seems like such a simple and obvious way to simplify computers. Why didn't I think of that!!
You know, the idea of a personal computer is to avoid having the ask someone for permission to use it.
-- Slashdot: When Public Access TV Says "No"
Yeah I know what you mean. We all know that at the moment when you download a new multi megabyte application for the first time it's an instant process which takes no longer than a fraction of a second. The idea of having to download an application for the first time just sounds slow to me!
Oh hang on a minute, those two are exactly the same thing!
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...
we speak the way we breathe --Fugazi
As long as all these 'followers' are determined to ape everything the Beast does, down to the Teletubbie look of Windows XP, how can Linux fail?
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?
---------
There is inferior bacteria on the interior of your posterior.
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.
Zero Install: The Future of Linux on the Desktop?
No, Zero Installs is the future of Windows. Give it 10 years -- there will be zero installs done worldwide. RMS will end up buying the newly-defunct Microsoft for $3000 just for the nostalgia value (the same way collectors buy Nazi paraphernalia)...
I'm not normally an irrational zealous dickhead, but I figure "When in Rome..."
...is not important, then why not just have everything statically linked and erase the biggest problem with Linux applications today, the dependency issues.
This is doing the same thing except to extremes.
Loading...
For alternatives, checkout:
Bitrock: kind of "Installshield" for linux
Installshield multiplatform: The actual Installshield for Linux (written in Java and a bit ugly)
Autopackage: Kind of universal installer
Ummm firefighters offensively fight fires all the time, they are called controlled burns to eliminate fuel accumulation, renew the Earth, etc. So the quote actually still works fairly well, sometimes the best defense is a good offense.
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.
If I had a nickel for every time my granma asked me to install a pattern scanning and text processing language (awk), or a program to concatenate and print files in reverse (tac), I'd have (lessee, nothing times nothing ... carry the nothing): NOTHING!
There's just nothing on linux that Joe Sixpack wants, that isn't done elsewhere.
Are there any provisions to make the programs i 'install' with ROX accessible from the path... so after I installed gimp, i could start it from the command line, or the run application window (alt-f2 in gnome), etc... or do i have to keep launching it from the folder i DnDed
Need a Catering Connection
This sounds an awful lot like Java Web Start, except JWS uses http to fetch archives.
:-)
And, of course, it's mainly used for distributing Java apps
sigs are hazardous to your health
LOL!!!
You're also assuming that the app is built with autoconf and automake, which is no the case for every application in Linux. This isn't necessarily a bad thing, since auto(conf|make) are horrible, disgusting hacks, perfectly at home with the rest of the GNU project.
Or what if the site is temporarily down?
Personally, I'd prefer a good old packaging format (rpm, deb, etc)...
In JWS you click a link and it is automatically and SECURLY cached locally where updates are automatically received and uninstalling is a single click away. This is also an open standard called JNLP.
Great analysis!!!
First of all, there is a closer relationship between OS 9 apps and OS X apps. Well behaved OS 9 apps came in a folder (typically named something like "MyApplication F" where the final F was an italic "f") with the application and support files. Badly behaved applications that used Windows-style installers put junk everywhere, but that was *those* applications that did it. There's nothing in Mac OS that required that kind of nonsense. Apple used installers for doing OS updates, yes, but that's outside the scope of an application package system. Where applications use installers, on Mac OS or Mac OS X, I always make a point of mailing them and asking them to just use an Appdir. Occasionally they respond positively and quit using installers.
Second, you have to store personal preferences somewhere. Storing them in XML files in the user's directory or in dotfiles or in directories, any of them have the advantage that they're in a human-editable format. Corruption, if it occurs, is easily dealt with. Automatically "fixing" corruption after it occurs without the user's explicit request? No thanks, I'd rather have a try at fixing it myself, and figuring out how it happened so I can keep it from happening again.
Finally, the complexity of the Mac OS X boot sequence is completely outside the scope of a packaging system. How does ROX make it easier to configure Lilo?
OMG u r so mean!
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?
I'll have to try the ROX desktop again, I guess. The last time I brought it in it was extremely difficult to configure, and quite complex to use.
>> 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!
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.
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?
Defenestrate Windows...
You don't have to copy anything, you just have to run the binary - and any required components are downloaded transparently unless they are anready cached.
One of the great things about 0Install is that you don't need to be root to run software through it (with 0Install you don't really "install" software, you just run it - it is transparently installed if necessary).
The best thing about 0Install is that it essentially eliminates the whole process of installation - you just run the software, if it isn't cached locally - it will be transparently downloaded on-demand. AFAIK Microsoft doesn't do anything like this.
only because you don't understand a technology, that doesn't mean that is is not good.
Because it makes it harder to copy a Windows system from one hard drive to another.
Wow, a lucrative publishing contract! I don't have to be evil anymore. --Meteor
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.
“Wait for Hurd if you want something real” –Linus
I have never used the option, but dpkg has a --instdir option that appears to do this too.
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.
Government of the people, by corporate executives, for corporate profits.
- window sizes and positions should be remembered
- style for each window (background image/color)
Heck with just those two things, I think rox has finally achieved being most of what my beloved WPS was on OS/2. The concept of AppDirs kicks ass. This made it very easy for me to extend rox using nothing but shell scripts. Some things I did:- Mail notification. I scan my maildir, and if I have new mail, just switch the rox app icon for my mail program
- Network mount status. I have a folder for each of my remote hosts. By default, the Appdir launches an ssh session. A shift click allows me to mount dirs on that server. If a directory is mounted, the main AppIcon indicates it.
- Image directories. Again, I have a ROX app that allows me to manipulate the icon on the desktop (random image selection). Other options on the fly-out menu include slideshows, view current image, view similar images, etc.
- I wrote a quick filter object to be used with ROX. Using symlinks, I was able to have a filtered folder that only showed what I was interested in.
What makes rox so great is that it is such a simple and consistent concept, which makes it easy to build on it to create some very nice custom UI enhancements.From a Linux perspective it's useful to have apps in their own directory to allow for easy removal, the disadvantage is when you want to backup all your settings. You then have to traverse all the app directories to find settings files and back those up and not the application files.
Why do we have shared libraries at all? Is there some real benefit to the operating system or to applications to have them?
Wasn't it not that long ago that most apps were compiled to be statically linked (a.out) and didn't need any shared libraries at all?
Personally I'd rather waste memory and disk with all statically linked applications, but maybe I'm just misinformed. I know I have been nailed by library problems under Linux and Windows.
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.
Linux has no future on the desktop. No Average Joe will want an OS he has to recompile every week. Cant execute files without changing their parameters. Cant get a GUI that doesnt look like the bastard son of 95. Cant play the majority of games. Cant use the majority of programs made for the OS without recompiling. Cant find drivers, etc etc. Must I go on?
According to Microsoft's specifications, user settings and data are not supposed to be stored in Program Files.
This is for security reasons. The Program Files hierarchy is supposed to contain executables, and it is not supposed to be writeable by a regular user. (Power Users and Administrators can write to it.) When it comes to trojans, viruses, and assorted malware, you do the math.
On the other hand, Documents and Settings hierarchy is specifically organized so that each user's space in the tree is readable/writeable by that user and the System and by nobody else. That's your home directory for you. (You wouldn't store your data in a world-readable/writeable directory on a *nix system, would you?)
Unfortunately, some developers are stupid and ignore the Microsoft design guidelines. One side effect of this is that many applications break when you try to run them as a user (rather than as Administrator). Wow, run everything with admin powers that's a great idea! (Not.)
Fortunately, Microsoft is beginning to crack down. Future versions of Windows will be taking the attitude of, well, if your app is so poorly designed and breaks so many of the rules we have for security reasons that it won't run as a user, tough luck, your application will break badly and nobody will buy it.
+1 for Microsoft in this regard. They have been taking the blame for a lot of problems that are really caused by app developers. Microsoft should be forcing application developers to put executables where executables belong and data where data belongs. No sane *nix admin would allow the wrong stuff to be put in the wrong parts of the filesystem, so why should a Windows admin allow the same?
Microsoft Windows is, fittingly, the official Desktop OS of Olig
Forgive me if I'm wrong, but Zero Install would only work if it was used for a handful of packages.
Think about it this way. Say I write a program that uses zlib, libc6, x libs, etc, etc. From how I understand it, Zero Install says that all of the depends are in the program directory as well, right?
So now say every other program that is written using those same libs is in their own directory, or say I write another program that has to use those same libs. I have to include them in that directory again. Think how redundant that is. Its not worth it.
You can't use the Rox app system to do libraries.
But if thats true, how can the program directory tell if the required libraries are there? You will still fall into dependency battles. It will never be drag, drop, and run for everyone.
I guess it just seems to me that shared files are short changed by this system. If you're unhappy with the spread out files, or how they don't get cleanly uninstalled, write a better uninstaller.
I like Rox's system, I've played with it, and maybe I dont understand how shared libraries would work, but I just can't imagine it working on a large scale of programs.
Here! Here!
Hi!
I re-install windows a lot because I test lots of drivers (bad driver system from Microsoft).
Therefore I love programs I dont need to re-install after a system reformat/reinstall. Programs that keep settings and "libraries" in their own directory.
Keep them in d:\programs and you can reformat/reinstall C: where Windows is any time you wanto.
Opera:
create a shortcut to opera.exe and done. History, settings, button layout, skin, log-in sessions, wand passwords, cache, visited link history, browser tabs EVERYTHING.
Windows XPeee however i have to spend at least two hours setting up everything back to normal. Files and folders transfer wizard sometimes bring with it registry bloat and bugs from my last install.
System restore and driver rollback I can only imagine is a workaround for a sad system.
more here
http://jooh.no/prog_winxp.html
Teasing the nobles, and rightfully so!
GoboLinux has an interesting approach that reminds this one adopted by ROX and Zero Install. The advantage is that this classification is done by the OS itself, rather than only on the desktop. I'd suggest everyone interested on Zero Install's directory tree to give a look at http://www.gobolinux.org .
>effort. The
>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
Don't know if you're familiar with doing non-distro installs of Linux, but from what I've been learning from Linux from Scratch, using configure --prefix means you can install a program into whatever directory you want. It's also possible to have as many different versions of the compiler and tools as you want on the same system, in different dirs...you just change --prefix and lib target settings accordingly. I downloaded a text file from tldp.org a bit back as well, about a Linux file system standard...Seems a lot of distro makers are playing it fast and loose with the standard directory structure these days, and it's wreaking havoc with universal compatibility. It is entirely possible to ignore the directory structure completely if you want, though...you can have all sorts of weird and wonderful things.
Linux has always been geared towards creating a system that is very much like Unix. It's done a very good job as well. However, as we all know, Unix works a certain way--there are lots of design philosphies that dictate how Unix is supposed to work, and linux so far has been following these fairly well, even if it is a little bit different.
Here lies the contradiction, though; the point of linux is to be like Unix, but in order to make linux "good for desktop users" as the article claims, you essentially have to make it "not Unix." But wait--isn't the point of linux to be like Unix? This is where you run into a problem; you have a split in design philosphy.
While there are definitely ways to form a marriage between the two, as this piece of software suggests, there will still be problems. Linux as a whole hasn't been very good about following a largely structured design philosphy, or, at least, it hasn't to the same degrees as, say, MacOS. This is not just in reference to the system itself, but also the software that runs on top of it.
So, it'll just be one more thing to throw into the mix--another alternative way of doing the same thing, a fracture whose nature linux contains in thousands of. It's good to have choice and freedom, but it's just too much for the desktop user--they need less choice and more unity, something that will allow what little knowledge they can gain from using their system to be applied everywhere else.
Linux can work on the desktop, sure! But can it work with the average desktop user? To those with enough skill and knowledge, linux on the desktop is very manageable. In fact, it works great in that environment, but not everyone can make it do that. Because of the nature of how linux works, it will take an exceedingly large amount of time and effort to make it 100% manageable by Joe, whereas other, more focused operating systems, have acheived this goal in just a few short years of development.
Linux will suffer from having to work against itself in order to become "user friendly", and since this is a bit awkward and unnatural for a system of its kind and method of development, it will just have a natural tendency to not want to be that way. People are going to continue to be very frustrated in trying to make it.
Applications that are contained in one directory was quite popular once - DOS used it quite a lot, back to basics i guess.
easy to understand, now I get it. thank you.
Back in the early 1990s when Microsoft started pouring more money into Windows than DOS,
rule #1 put sales and complexity above easy installs, easy backups, and easy uninstalls.
It was unAmerican if you could unarchive FOO.SEA or FOO.ARC or FOO.ZIP into directory
[FOO] containing FOO.SRC, FOO.INI, FOO.EXE and FOO.DOC
But Windows could drop little icons on the desktop so users could find FOOBLOAT.EXE !
Isnt this exactly the philosophy behind DOS (except the GUI part).
Essentially you just copied and ran in DOS.
I think this is a good idea, but it may be at teh expense of efficiency. That is, parts of a program which could be abstracted out into other packages to be used by other programs may be less likely to occur.
Efficiency or Ease? I choose efficiency! but if you can do that and slap a nice interface on it then im cool with it.
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.
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.
/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.
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
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.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Right. And Joe User will find this frustrating and difficult to understand, let alone accomplish. Don't assume that because you can do it, that my Grandmother can do it as well.
Granted, Apple's stance on security is not as strong as Linux's can be (not is, but can be), but the issues of backup and of 'system bloat', or the buildup of tiny file droppings left over by uninstalled applications, are in every modern OS. The old "copy and burn" backup system just doesn't work well with the size of modern HDs, and implies a certain degree of security laxity (I.E. if you can copy and paste it freely with no permissions issues, so can a hacker). Proprietary, Take-2-Esque formats become obsolete and unusable, and straight file-copies often get corrupted when dealing with half a million files (the current amount on my 22 GB of space used under OSX), which can kill a disc or, worse, not work when you try to use it. All of the OSes I've used recently (Mandrake 10, Windows XP, and OSX Panther) share this issue, so I've found the best solution these days is to get an external 80GB HD and clone to that, which is quicker, more reliable, bootable, and works across platforms.
The bloat issue is, to my mind, more severe, and demands some serious attention. Possibly this ROX system would solve some of these issues, but spyware, installware, caches, orphaned prefs, and all of the other crap that clogs up modern OSes would probably still pervade. Some more literate way to browse the system folder (other than opening it up and throwing stuff out) would be a good first step.
-B
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.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Would you be kind to explain me how to do a "./configure; make rpm"?
"I think this line is mostly filler"
I experimented with this a bit and was pleased with the results.. I was also thinking exactly what the article states, but, it can be a bitch via 56k and various apps, for games and misc stuff, it can work great, for system apps and developer and server stuff, this doesnt work that well
but for a desktop, it could work, and you can even download source packages and click the icon, they compile, voila, running program (at least in ROX)
I still dont like th feel of the Rox desktop though, it's still kinda iffy
Zero install: Somebody set up us the Linux!
You can't see stuff like this happen and NOT acknowledge that innovation occurs in the open-source world.
To claim OSS is just a process of copying and idea theft (like that guy who wrote against ESR the other day) is stupid and arrogant.
I hope this method gets more popular. Its pure simplicity reminds me of DOS.
Not only is M$ copying Apple again, EVERYBODY is! When will .dmg images mount on the desktop?
The Internet is by definition a bi-directional system, and most of its promise comes from that: there are no "client" and "server" distinctions at the topology level.
Cable and DSL ISPs find themselves in the business of selling Web access because it's cheaper than selling Internet access.
Universities that provide residents with access that can't accept incoming connections are doing their residents a disservice.
Is lower latency on WWW for 99 percent a disservice? Uploaders on resnet consume upstream bandwidth that the directors claim would be better used by, say, the university's web site. If 1 percent of the users consume 50 percent of the upstream bandwidth that the university gets, is it in the university's interest to make it hard for the 1 percent to consume so much bandwidth?
Maybe if more applications require them, the uni's will change their tune?
The universities will change their tune only when the last mile from the ISP to the uni becomes much cheaper.
As someone else points out, ROX is Risc OS on X. So it's deliberate that they have the same approach as Risc ;)
Tried it, it's not that clean. It wanted to install DLcompat, ESP Ghostscript, and fondu as well, all locally. This got messy, since I wanted to provide fondu from fink (that worked) but wanted to install DLcompat and ESP on the new disk image I made for OO. DLcompat was happy with it, and the OO installer was happy too once I made symlinks from /usr/local to /Volume/OpenOffice.../usr/local. ESP GS didn't want to install on the image, so that ended up being under /usr/local.
I'm curious to see how much of it the uninstaller will catch when I finally want to uninstall. Really, all of this is so that I can view rtf files with tables...
GET YOUR WEAPONS READY! --DR.LIGHT
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.
/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.
/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. 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
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
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.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
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...
"Don't sweat the technique."
"Deleting the application along with all the other misc files is as simple as removing the directory it's contained in"
like DOS?
The Kruger Dunning explains most post on
I think Linux would win a lot more converts if KDE and GNOME where less like Windows.
It's obvious that KDE is gearing for Windows and GNOME is gearing for Mac. GNOME will probably end up getting more converts that way, but the Slashdot weenies will come out in full force, like they did in the last 2.6 article in which they bitched about the spatial finder--even though the absolutely, 100% ridiculous "browser" metaphor for perusing folders is confusing and unnatural to anyone but...you guessed it...Slashdot weenies. It's like we're just supposed to accept that Internet browsers are the same as filesystem browsers simply because Windows 98 said so. Sorry, I'll never buy it.
So could you have, say for example, an OpenGL folder and all OpenGL apps look for that folder to run. It would not matter what version (i.e. standard, hacked or otherwise) of OpenGL you had the app would just try to run with what is there.
If so, then any shared libs could also be stored like this - as long as libs were always backwards comnpatible or hacked to work then what's stopping this?
You could even versionise the subfolders to make having, say, 5 different OpenGL implimentations available (apps would just look for the version they are witten for by folder name).
Taking this approach you could build code with shared libs really easily. If this is the point then I'm sorry for re-iterating it. If this was possible then it would remove any backwards compatibility issues etc for software.
Anyone have any reply to this? Or am I talking out of my butt? (I don't code software at all).
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.
Wow! Rox sounds great. Lemme try...
# apt-get install rox
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package rox
#
Mmm...not available for Debian yet. Oh well, let me know when it's ready.
Ruby on Rails Screencast
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?
Tech Public Policy stuff
Right On!
My biggest headache is how Windoze (and other OS') 'splatter' data all over the place.
The OS and Apps should all be able to run from a read only CD.
All data to the hard drive.
Why is it game stations seem so much more advanced than 'professional computers'?
Pop in disk - play the game.
Pop in disk - Run OS + Apps.
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.)
Java webstart has done this for years.
But won't this system take up a lot of space? Especially for multiple application that might want to use each other's data? Or multiple application that uses a common libraries, like the .dll?
In US, you can easily buy enough major firearms to wipe out your neighbourhood but a few little fireworks are banned.
It was about time for something like this to happen. I never understood why applications need to spread myriads of files in other directories except than their own.
Microsoft engineers, are you listening ? Windows apps could go in their own directories, and the DLLs and other stuff should be hard-linked within the directory 'system32' from the app's original directory.
But no, this is MS, they had to make it difficult (and we must not forget that MS filesystems don't have hard links!!! (only NTFS, in a non-portable way)).
What does the word "install" mean?
/usr/local/bin?
Do I run it from the net, or do I run it from my computer. If I don't need to run my app over the internet, after the first time, then it IS installed. Or no, it's not installed, it's cached. But that's the same thing, or is it?
I support freedom, I support freedom for people to do what they want. I was reading the Gentoo webpages, and the author was saying that the goal of Gentoo is to enable the user of the Linux box to do what they want. Not what the designer of the distro wants, what the user wants. That means that the distro may need to be able to do 10,000 things - that's the whole idea.
So, from that perspective, I support people doing what they will with the technology, whatever they want to do, they should be able to do it. More power to the people!
Personally, however, this sounds to me like something that I would have absolutely no interest in whatsoever. I'm not installing, but I'm installing? What's up with that? Automatically goes out and finds missing dependencies? Who's dependencies?
I don't like it. But that's just me. That's just my opinion. It's an interesting concept, but to say that you're not installing, that's just not what is going on, and I just smell licensing issues big time. Sort of like DRM or something.
This type of thing could be abused by spammers, malware, and greedy organizations. If it's an application, and it runs on my machine, it's installed. To create a seperate directory, I mean... what's wrong with
I support diversity, and it sounds like this is a popular idea - but I see a potential for abuse, because it's saying "you don't have to install, it runs over the internet", but it actually IS on your hard drive. Cached...installed...
But just because I don't like it doesn't mean that others have to also not like it. It sounds interesting, and certainly could prove useful for certain things.
So I wish the project well, but in expressing my opinion about it, I don't like it one bit. That's just my opinion, though, it doesn't mean it's a bad idea. You could probably get very rich doing this.
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?
I've NEVER been enthusiastic about systems based on a high degree of Internet dependancy for app running like the system being mentioned here. It could lead a recentralization of computing into the hands of a few corporate "backbone" server owners that could wind up being a worse monopoly than even Microsoft even if a FOSS system like linux is its basis.
I'm all for ease of use under Linux and am working on my own linux installation solution under the GNU-GPL that is NOT based on dangerous computing re centralization schemes like this one.
The main problem I have with it is that it's fixing the wrong end of the issue. This problem came about because of Linux's continuous development, and the lack of developers consistently following the rules that do exist. Why not fix that end, and the rest will fall in place? I also don't see anyone asking, what happens with this system if the developers don't follow the rules (lazy is lazy, and no system can fix that)? Will we be back here, complaining about something else?
Sounds like a great way to revoke access to software unless the poor vict... er, user pays more dough.
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
well, I asked the question originally, although I had a guess, that's what it was, a guess. I'm not a coder, but I have been a long time computer user and enthusiast, there are by casual glance around the room here 5 desktops, two laptops,and 6 radios-3 of them transceivers- in easy view. 4 of the desktops I built from junker parts, so I can give them away to local (poor blue collar farm) kids on their birthdays. I don't work in IT, I'm a blue collar guy with different skills, but I dig electronic stuff, and I like to know how things work. Slashdot appeals to me BECAUSE it's interactive, there's a boat load of people here who ARE skilled in different venues, and you can get some decent information and decent reference URLs here by asking politely. And the occassional nasty troll or whatever doesn't bother me, I've been using boards and moderating them myself since around 95, heavy since 97. I knew the *term* dynamically linked libraries, I have heard my windows friends over the years use that term, but I wanted to be sure that what static meant was what I thought, and since I didn't know, I just asked, simple as that. I mostly always used mac classic before tip toeing into linux a couple of years ago, but frankly, I'm still a point and click guy. That's reality, and I'm not ashamed of it, it just "is" is all.
And the price is right to be here, and this slashcode, combined with the input of all the readers and the editors, gives me a customised news magazine on demand. And a lof of times it's dang funny!
If I- or anyone-knew all there was about all the subjects covered here, there wouldn't be any need for that person to come here, would there be?
With all that booshwah out of the way, here's how my mind works: OK, now I got the skinny on the differences, so now I am thinking "why them guys do it one way or the other, why not both at the same time?" You see when you are a blue collar guy, and work=sweat and pain, not just exasperation and inconvenience, but real sweat and real pain, you take ineffieciency as more than just a PITA, it's insulting, and with self defense of your bod in mind, you try to figure out the easier/better/more efficient way to do something.
And you don't need any boss with any number of degrees to tell you those cosmic truths, either.....
I know zip squat about coding, but seems to me that a "master library" could be used as a sub program, or substitute of some form, to go get the libraries you need for different apps. Then instead of the apps needing direct-static or dynamically linked or symlinks, all they would need is a pointer to the master library with some sort of tag like "use this version", and THAT goes fetch whatever is needed. Then you only need to update the ONE master library, not one buhzillion other libraries all the time, whether they were included in the app or not.
But, like I said, I know less than zip,maybe it does this already, I have NO idea if what I just said made any sense, probably not.... so I'll let the smart guys who write code do their things...
I mean... does anyone remember DOS? it worked the same way... that was one of the things i hated when win95 came out, you couldnt just copy a directory and have a fully working program anymore... really didnt like that, anyways, glad to see people are looking into it again... its a much easier way to work, stop worrying about dependancies, and get back to whatever it is that you're really trying to get done.
I haven't used this zero-install stuff much but the roxfiler simply rocks because it's lightning fast, useful and good looking.
Common libraries go in /uri/0install, see 'Q. What about libraries?' in my previous post.
Applications would need to know the application directory of the application whose data they want to use, or they can use a file open dialog box to select shared or user data somewhere else in the filesystem.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
seems like I was thinking along the correct lines, there's hope for me yet!
At the command line I am dismal, but slowly getting better as I make **&^%%$ stuff work that ain't.
Of course, you ASSUME that because movies are listed that they are illegal copies.
This system of installation was already available on Mac OS 9x. Still works for some apps in OSX.
> The apps are all self-contained in their own directory; binaries, docs, source code and all.
Didn't we just do this back in the 1980s with MS DOS?
This is a really good idea to solve many problems we now have with inter-directory / inter-registry / etc conflicts.
I can't afford a Lexus but I can afford a Honda.
It's a fucking computer, get over it.
This is as old as RISC OS is..
Which is about 20 years or so.
The ROX is derived from RISC OS, hence I'm not surprised to see this.
Btw, MacOSX has the applications, libs, etc in one directory.. (Filename.app is actually a directory)
just like os x copied linux flame me if you want but it is still true
I know this message won't be popular around here - but to go beyond the simple installers which basically uncompress files from the source tar ball /rpm over to a directory on disk, Linux will need to evolve the concept of a registry of some sort.
Not to say that it should be like the one that is currently used in Windows; in Windows the registry is one large file (and a backup) which is prone to corruption - but I guess Linux could use a configuration storage system which utilizes a database of some sort which stores the configuration system across multiple files which are all managed using a single application. The individual configuration files should be text and not binary so that it can be edited using a simple text editor if needed.
For those who think that a registry is error prone and therefore useless - Have you tried to setup a complex application which needs a database engine, multiple transactioned COM components, set roles and rights for various users etc on Windows?
Doing these things is quite easy on Windows because of all the "objects" that are accessible on windows - for instance, to connect all the said tasks - setting up the users and their access rights, setting up the database engine (or detecting an existing one and using it) can all be done by accessing the various objects such as the IIS Administration objects, the MSDE Management objects, the Active Directory objects etc..
Windows also allows for the OS to be upgraded easily via an executable.
All this is possible because of the registry which stores the object references (COM registry).
Ok, you might argue that this makes Windows insecure and buggy.
That is true, but with some effort, I believe it is still possible to develop a secure, powerful OS with administration objects (perhaps utilizing a registry mechanism without the registry corruption problems of Windows) which will still be secure.
Linux does not currently lend itself to being easily configured programmatically - the administrator will still need to fiddle around with a lot of configuration files to get something complex setup. If this is addressed, it could go a long way towards easy automated complex installs which goes beyond just copying files from the source destination to a directory on disk.
In reply to everyone griping about OS-X and OS-X bundles and permissions becuase they are in "fear" of viruses... please show me a OS-X virus. Seriously. Feel FREE to e-mail me, or reply with links to one. Because I am in serious doubt that any exist.
I've done freelance tech support around the area, and in all the macs of my own and that I support that use OS-X, not 1 virus yet. Some PICNIC/PEBKAC problems 95 percent of the time, and the other 5 percent is some weird "issue" of os-x that required a workaround or fix. =P
The drag-and-drop installs on OS-X are a godsend when compared to Windows, or even Linux. When I want to remove an app on OS-X, I just delete it, and it's gone! No registry to hack through, no dll's to find and delete, and pray that no other app required them. No 50 directories to search through and delete files/apps one by one. Simply put... no bullshit. (yes, on OS-X there is that Preferences folder, but usually that's about it)
This ROX environment does remind me of OS-X, and they aren't the first to really implement this whole thing, but it's a good idea, and I'm always optimistic to see how far someone can develop a good idea.
Your questions have been solved in another project called CUE. It haven't made much noise about itself.
/app and /env. For some server applications the configuration are placed below /etc/app. Logs and such below /var/log/app. Over the years of building and installing and using these application in CUE it haven't been many that have had this problems. In some cases a minor patch have been needed. The CUE concept have internaly also been building CUE RPMs for commercial applications with great success, license are handled by configuration in /env where each site can specify their own license server.
Q. Do I have to add a bunch of crap to my $PATH?
A. All environment is handled by an user application called HickUP. With this application you can even create multiple environments for one user which you can switch between as needed. It also has a project manager which allowes for good controlled development environments.
Q. Will it let me recompile critical applications, either to patch them or optimize them?
A. All source are build from a single RPM for all build environments. The RPM environment is heavily controlled and demands more then usal RPM does. As an example it clears the environment and setups the environment based on dependency set in the RPMs spec file. Making the build environment the same everytime you recompile. Ofcause don't you have to install the RPMs on each computer on a large network, those times the sysadmin installs it on a NFS server and shares it to all the others. For all different OSes there is only a single RPM.
Q. What about apps with hardcoded pathnames?
A. That haven't been much of a problem for most of those compiled. All configuration and application structure have been specified to be placed in
Q. What about libraries?
A. The build environment when building the RPM controlls that we only use libraries from the CUE buildes or if it's a system library we allow that. Using the possibility to compile in the searchpath in each application/library for the libaray makes the application to find them without having to set the LD_LIBRARY_PATH.
Q. What about versioning?
A. Libraries are keep in the same order as applications, one version in each directory.
Q. DND Saving? What's that?
A. CUE haven't been made for end users yet on the installing part. The normal user in CUE uses the HickUP for choosing application. It was made for corporate environment for development environments from small project to distributed environments. That meaning a sysadmin are the one in controll of installing the application.
When having multiple application it's requires a strict building environment and disiplined builders to keep the quality high. Especialy when dealing with libraries.
The nice thing is that it was released by the main contributor with the GPL license. Other complaines have by that way been able to pich in and that saves alot on yor IT costs. By using signed RPMs it's also possible to know who contributed the RPM and that the build server was a valid one.
By using its own rpm it dosen't have any problems with systems already having rpm installed (normaly you don't use rpm but a wrapper script which fetches all depending rpms for the applications you want).
-qick
You may give Winswitch a try:
http://winswitch.wincent.com/
How did this a "5 - Insightful"? The post was totally OT and a obvious troll.
To answer this troll's highly rated post though, I would rather buy a $1000 Mac than get a $1000 PC for free, because I don't need the headaches that the PC clone architecture and Windows and Linux OSes bring to the equation. Although plenty of people and companies do it, I would never spend my own hard-earned cash to buy into that world. Besides, the TCO costs on the back end eat up all your "savings" on the initial purchase. And your beige box has no style (same to you Fast and Furious Alu-mini-um, windowed, water-cooled, glowtube boys too, like school on Sunday, no class).
Now, to get OT. ZeroInstall sounds like Mac OS X's (and NeXT's) application bundles, which are basically special folders that contain all the pieces of the app, but act like an application and launch when clicked. Bring up a contextual menu on most Mac OS X apps however and you can select Show Contents which opens the bundle as a directory rather than launching the app. Throw said app away and you just uninstalled it completely.
Mod the OT troll down.
(Now that I think about, I guess I'd take the free PC and sell it to get money to pay for the Mac).
Any sufficiently advanced technology is indistinguishable from Macintosh...
The registry is actually quite a good idea, with a horrible implementation. Basically, it shouldn't be a single file database-style solution. This adds confusion that isn't needed. The other reason it was poorly implemented was because they continued to use INF files, instead of depreciating the entire subsystem, for removal in windows 98 (95 was the first instance of the "system registry" as we've came to know it).
That's probably the whole reason Windows is in as bad of shape as it is; lack of standards, or downright bastardization, reinvention, or some combination of the two.
In theory, they could fix the registry, and I'm working on a similar Linux project right now. The idea of having directories redefineable (think: XML file; sorta what microsoft did with Desktop.ini) based on content, and virtual directories that have any content that fits a certain layout (think: Virtual MP3 Directory, Virtual Movie Directory, Virtual Config file Directory). Defining a virtual conf dir would allow you a one stop location to fix whatever system problem you wanted, and you could even make a purdy little gtk2 or qt3 app made specifically for editing these files (although, it would end up becoming something like G-Edit with a Sidebar).
Of course, this can be implemented by microsoft too, since their new WinFS will be an SQL-based file system. Using a Redefineable directory like "C:\Windows\Configuration Files\" could eventually replace the "registry", and help Windows become a whole lot more secure (by setting appropriate permissions on this directory).
Usually, ideas are very sound and awesome pieces of work. It's the implementations that are the bitch...
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
The problem with plugins is that they require the functions they call to be in a shared library (actually not a problem on Linux if you link with -shared, but we had to support Windows too, so we had to solve this).
/proc/self/exe). It modifies the LD_LIBRARY_PATH to add this directory, and then execs the real program from the directory. This step is not needed on Windows, where the program's directory is always added to the library search path.
.init file.
In our software *everything* in in a single directory. What is there is:
1. A tiny "exec" program named after our app. This program figures out what directory it is in (from
2. The real program
3. A shared library containing everything our plugins need.
4. A subdirectory containing all the plugins we provide with the program.
5. An "init" file that is text-editable. But by default it looks in ~/.app/ for the plugins as well as the plugins subdirectory. It will also source identical files in the ~/.app directory. So if you have your own plugins, you can add them by putting them in your home directory, by modifying the init in your home to point where they are installed, or (with permission) by editing the original
Hard as it is to believe, it is even what techophiles believe to be the correct procedure. Only long exposure to Windows or Unix brainwashes people into thinking anything else.
And if any moderators are still around, please mod parent up.
“Wait for Hurd if you want something real” –Linus
Perhaps I am missing something here, but if I am, I think it's because the first couple pages of the discussion listing seems to be all messages about OSX security?
While security may indeed be an issue with the system as described, I'd like to see a couple other, rather basic points addressed. Like:
Isn't this "all app pieces in one directory" approach a throwback to the way apps were designed e.g. under MS-DOS?
And: What happens to commonality of binary code? I mean, isn't that why we started using dynmical load libraries to start with? So we could write certain common code once, and use it over and over?
I mean, if One App, One Directory is a good idea, why not carry it out: give each app it's own virtual processor and it's own virtual fill system?
Forgive me, please, but this whole idea appears to be a fundamental shift away from the basic idea of resource conservation by code re-use and leveraging commonality. The trade off for all this beauteous simplicity has got to be code bloat and hardware cost. Does each application get its own registry? What about network device drivers. What if I create a plugin that runs in more than one app? What if I want to extend an app? Is my now part of the existing app, or is the existing app part of mine? Does the existing app have to live in my directory?
Maybe I should read the articles....
"The Internet is made of cats."