Slashdot Mirror
Could Apple's Intel Desktop Threaten Linux?
esavard writes "
If Linux enthusiasts don't want
Mac OSX on Intel to become a threat
for the future of Linux Desktop, they must rethink the concept of Desktop as we know it today.
Symphony OS did exactly that and propose some fresh concepts about how a desktop should and should not be.
If you want to know more about Symphony OS, a good starting point is a Wikipedia article
describing the innovations proposed by this new desktop OS. The Linux Desktop Community must encourage such initatives
massively to compete against Mac OSX and Windows."
Well, you can get a similar experience by using static binaries. They have the libraries compiled into the binary and have no other dependencies. The downside is increased disk and memory footprint. Also if there is a vulnerability in the library it uses the entire binary must be recompiled. Personally I like the way the .APP structure works and it's easy to backup programs that use that structure. I remember having some program though that didn't and insisted on installing thousands of files from a sit archive or something. I think it was Windows Media Player.. the version before the current one for MacOS X. Seems much more efficient to distribute a single .dmg file with your APP binary directory structure in that.
You must be old here.
Apple is completely debt-free as of last year; Steve Jobs had successful surgery; Mac sales are increasing 40% year-over-year last quater; FreeBSD? please.
Take it easy on the main server, here's the Coral cache...
http://www.symphonyos.com.nyud.net:8090/
"[i]In a complex system, packages are just as bad (actually worse) for users than DLL Hell.[/i]"
I think you have missed something.
Packages are a GREAT way to handle things.
The simple & dumb way as OS X handles packages is just that: it can not handle dependencies, or anything, it just puts some files on your computer.
It works moderately well, if you only use it for applications and those are statically linked, but nothing else.
Now, take Debian's package system: it handles dependencies, version conflicts, alternative packages that serve the same purpose, etc, etc, ec. And it is absolutely easy: an apt-get install xyz installs/updates package xyz and all the necessary shared libs, updates file associations, whatever (and it does not takes exactly rocket science to create some GUI for that single command line).
Real life is overrated.
The main problem with package management is managing dependencies upon other packages. The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem. Most naive-user packaging systems fix the problem by including the kitchen sink (all applicable DLLs) in their own package to reduce dependencies. Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination. Once you add repositories, they go out of phase and the problems pop up.
Bruce Perens.
Your rosy eyed view of Mac OS X packaging is quite amusing. From someone who actually knows something about the issue, Mike Hearn of the autopackage project, in his own words:
/apps/packagename) and one day there may well be a VFS plugin that lets you view installed packages as folders/directories. I think it is highly unlikely that you'll ever be able to just drag app directories off a CD onto the system however.
Does the Mac fare any better? Unfortunately not. MacOS X has (in theory) totally eschewed installers in favour of App Folders, which are specially marked directories, the idea being that you simply drag and drop the app into the Applications directory. To uninstall, just drag it to the wastebasket. This is good UI, but bad everything else. By eliminating (un)install logic, it becomes extremely hard to check for dependancies, to provide system components, to clean up configuration changes, other application metadata and so on. Although technically apps can have dependancies via bundles, the lack of OS side install logic means that in practice it's not possible to install these bundles into the OS if required - the user must do it for the app. As such, apps can only rely on funtionality that was known to ship with the operating system. That suits Apples goal of selling more copies of OS X, but is rather limiting for the user. By trying to hide the problems dependancies pose all together, it creates bigger problems further down the line. As such, some Mac apps ship with install apps anyway which rather defeats the point. Note that my beef with appfolders are more to do with the way they have been implemented in NeXTStep - you can use autopackage to install apps into an appfolders style arrangement (for instance i test with
And you will note that even Apple do not universally use the app folder method of installation.
### And it is absolutely easy: an apt-get install xyz installs/updates package xyz
/var/lib/dpkg/lock - open (13 Permission denied)
$ apt-get install xyz
E: Could not open lock file
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
Ok, next try:
$ sudo apt-get install xyz
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package xyz
Both of the aboves gives you a pretty good summary of why Debians way of handling packages isn't really any good in the long run.
First of you can't install a application as a user, now how stupid is that? If *I* want to install a bleeding edge version of Gimp, I neither want to bother the admin with it nor do I want to force it an all the others users, yet Debian requires me todo exactly that.
Secondly Debian packages work great, but only for stuff that is in Debian, which might be a lot, but is *far* from everything and its also often *way* outdated, remember those three year release cycles... Software packaging should be done by those that provide the software in the first place, the distro might run a quality check on it, but thats it. What good is it to release a software today and having to wait three or more years till it finds it way into Debian?
There are of courses dozens of other problems, but those above are probally the main ones. You can of course work around them by compiling yourself, but didn't we invented packaging system to avoid exactly that.
Hi Bruce!
The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem.
True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.
It is of interest to note that the same is true of Windows. While the ability to install system wide DLLs exists, the reality is that only Microsoft tends to distribute anything that's useful for multiple programs. Modern Linux distros have started down the same path with a set of default APIs, but they tend to fall flat due to a lack of standardization and incompatible library versions.
For the APP concept to work on a Linux system, the system must promise a very precise set of APIs with precise minimum versions. Programs should be aligned along the use of this standard, with programs upgrading when the OS upgrades the standard. (Analogous to OS X 10.3 -> 10.4 and Windows 95 -> Windows 2000.) If a developer wants to use a newer version of an API or a non-bundled API, then he should bundle it with his program. It's possible that he's use up slightly more memory than necessary, but it shouldn't matter in the grand scheme as long as he doesn't try to replace the entire OS. (In which case, something is wrong with either the programmer or the OS.)
Now traditional packaging systems are sufficient for core OS components like these. You *want* a consistent OS at that level. But at the application level, these dependencies (or more often, dependencies of dependencies) tend to get messed up and deny the installation of a program that will function correctly. There's no reason for this. A prelink can be done, and the program can gracefully error out if there's a problem. There's no reason to place the user through the teeth gnashing pain of solving those dependency issues.
An excellent example of a system that manages to use this scheme is the Java Virtual Machine. Love it or hate it, programmers always have access to a specific set of APIs, then are able to add more as they're program requires. The only duplication of libraries tends to occur in places where the JVM had not yet added an API. (e.g. XML parsers, Logging, etc.) Once an API is added, then the number of duplicate libraries drops. Rinse and repeat.
Is that a little clearer? (Not sure if I'm coming across too well.)
Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination.
There's a couple of problems with this:
1) Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.
2) Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.
3) There are still constant arguments over where to put things on a Unix system. The APP solution solves everything, as everything always goes in the APP folder. This is actually *closer* to the Unix philosophy of having a standard set of subfolders (e.g. bin, lib, man, src, etc.) inside every major folder. So if someone invents a new sort of meta-data (e.g. desktop icons, info pages, etc.) there would no longer be a question about where to standardize on their location.
Javascript + Nintendo DSi = DSiCade
I personally don't even notice it any more (probably because the only GTK app I use is gaim, and very occasioanlly, GIMP :)), but I guess it's confusing for most new users. Has anyone tried out gtk-qt? Does it work at all well? Obviously it can't handle entirely different UI conventions, but I guess it could possibly make things at least look the same.
Ah, but you miss the point of OS X's simplicity. The standard OS X development environment provides the vast majority of functionality that programmers require to make all but the most complex applications. There's no mucking about with 'this application requires libpng 0.4.20b and libpcap 2.1.2' as on Linux, or 'this application requires msvbvr70.dll'. An application requires Mac OS X Panther or Tiger or 10.2 or somesuch.
If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle. Since it's usually very application-specific code, it's not going to be something that other apps are going to need/want, so there's no issues with wasted space due to non-dynamic libraries.
Thus is the beauty of OS X's design - provide a set of tools that provide what the majority of developers need, and you won't have to worry about the user having this dependancy or that, or installing this dependancy or that, and for those unixey ports, there's always fink, which is very handy indeed.
Mac OS X has a package system (.pkg) with a gui installer. However, Apple encourages developers to build an app that can just be copied to /Applications, rather than building a package. It's easier for the end user, and easier to keep the related files together - avoiding the "what app installed /foo/bar?" question.
I use Macs to up my productivity, so up yours Microsoft!
Beagle is the Linux equivalent, written using Mono. It's early in development, but appears to be making good progress. It uses inotify in the kernel to monitor files for changes.
1) 97% of all applications fall into the "very simple applications" category, if needing libraries not already installed with OS X is your metric. The point the parent was trying to make is that Apple errs on the side of providing everything by default- they've given up on trying to keep the OS footprint small. Unless it's code specific to your app, it's likely already provided. Please provide an example if you want to refute that point- maybe there's something they should be including that they don't.
2) It doesn't actually have to be a single statically linked binary- that's just what most programmers do, because it's simple, and easier for the user to manage if you have everything self-contained in the application package. If you want, you can create your own application frameworks, and place them in standard locations ( not /usr/local, but rather /System/Library/Frameworks or ~/Library/Frameworks ). Frameworks have certain advantages ( versioning support being just one ) over standard dynamic libraries, and they're quite easy to use. Most OS X programmers don't do that because, well, they don't want to have to write an uninstaller.
Just because OS X is 'like Unix' doesn't mean that's all it is. I don't even want to know what you're doing to your mini that you've felt the need to reformat and reinstall twice. That's just crazy. May I recommend Fink for your Unix-ported program needs? The /sw directory is an excellent idea...
I've seen prepackaged binaries ( generally of ported Unix apps ) which write into /usr/local, and I have to say I personally dislike that practice. That said, if you choose to go that route and use /usr/local, managing it is no different than under any other OS- you have to do it yourself.
why NOT use OS X's approach on Linux?
Because on a Mac, you can be guaranteed of the existence of preinstalled libraries, and on Linux you can't. I agree the Mac way is much better, but until there's a ubiquitous Linux standard it's not going to be feasible there.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
As one user mentioned, VersionTracker is kind of the Freshmeat of Mac OS X. So is Macupdate.
Also, while Fink is pain at times (partly because of its Linux roots, and OS X is more BSDish), Mac OS X has DarwinPorts, which actually works pretty well.