Dragging.app directories into the trash is playing Russian roulette with your system.
People keep saying this, but I just haven't found it to be true. I've used a Mac for about two years now, and in that entire time I have never had an APP screw up my system. The only APP I have that even installs a kernel module (a VPN client) loads the module dynamically. Which means that the module will get cleared by the next reboot at the worst.
So, would someone like to produce some actual evidence of an APP damaging their system?
http://www.versiontracker.com/ - Pretty much every serious Mac user learns about this one. The reason why you're not finding any other sites is that VersionTracker is considered to be THE source.
Dragging an application to the Trash will not delete anything the application has created such as user preferences. It's a valid argument to say the user might not want them deleted, but they should at least be given a choice.
This is very true, however NO scheme currently exists that will delete user data. Windows installers have the option, but precious few ever take that step.
Even worse is if you've installed third party drivers (my Brother laser printer driver comes to mind), kernel extensions, screen savers, preference panes and anything else that must be installed outside of an.app file.
This is still considered one of the biggest failings of the OS X install system. However, it doesn't matter too much in everyday use. The bigger issue is still the programs that everyone uses every day. OS X handles desktop programs beautifully, Windows handles them poorly but in a workable fashion, and Linux Distros just pretend to be handling them.
Reread my post. I wasn't complaining about Microsoft, I was stating that Dependency Hell is worse than DLL Hell. Nothing about DLL Hell still being an issue.:-)
I did complain about things like file associations and inability to relocate programs, however.
The thing that you can find in Control Panel > Software.
I don't have a "Software" icon. I assume you mean "Add or Remove Programs"?:-)
If so, be aware that it is *not* a package manager under the definition I gave. If you're not clear on what a package manager is, please reread the description I gave in the grandparent post.
And I have to disagree about it sucking less than OS X. Under OS X, I just drag the applicaiton to the trash and empty it. No more program. Under Windows I have to use an uninstall program that rarely even removes all of the program files, much less extraneous files left behind.
The only weakness on OS X is the installer. However, that installer is almost never used for user programs. Only Unix utilities and system updates use it. Most users will ignore any desktop program that comes in an installer. (Which usually just builds an APP folder anyway, but the develoers didn't understand Mac distribution.)
Stating that APT is unbreakable is an undefensable position. Everything is breakable. It just so happens though, that packaging systems are seen as far more breakable than more traditional install methods, and lack many of the features of such installers. For example, there is no APT solution when I can't find VLC/XFCE/Bob's Cool Script Library/[insert your favorite package that is commonly missing] in the repository. And there's definitely no APT solution for software that CAN'T be in repository. (e.g. Oracle, Real Player, Java, etc.)
So, are you going to keep swearing at me for attempting nothing more than an enlightened discussion, or are you going to acknowledge that some issues exist and then discuss how they might best be solved?
I've had a far far worse time with OS X installers leaving crap around than with the debian package system. But I don't then claim.debs are perfect.
Indeed. But as I suggested to Bruce, there's no reason why a package management system doesn't still make sense for core APIs. That would play on the strengths of the two systems and give you the best of both worlds instead of trying to force one world to cover everything.
You need to be careful about telling people that they're Just Plain Wrong(TM). You may be very wrong yourself.
This is a debian based (apt-get) packaging system. It was one of the first, and it "fixed" all the problems you complain about in your post.
If that was true, then why did the APT system break the first time I used Debian? I forget what the exact packages were (I think it was KDE), but the system just... broke. Classic dependency hell, on a system that wasn't supposed to be breakable.
This guy just complained about the same thing. I've heard the same complaints from many others in the past. Not to mention that I'm a big fan of the BSD ports system (as close to unbreakable as you can get), and yet I've had that break on me many a time. Package systems are flawed for the same reason that programs have bugs: Humans are not perfect. The problem with a packaging system is that it's a precariously stacks structure that relies heavily on someone not screwing up. The slightest mistake and the whole thing comes tumbling down.
I won't even begin to address the issue of commercial software and software that is not yet in the repository.
To be clear, I'm not saying that all distros should just up and adopt this scheme. There's always going to be a "different strokes for different folks" mentality in the Linux community. But there *are* a variety of distros, all with supposedly different goals. Today they are all pretty much clones of each other with slight strengths and weaknesses over one another. No one has yet taken a stand and decided to do a really different distro that does attempt to appeal to the home Desktop market. The closest thing to this is the Java Desktop System, but it's really intended to be a user interface to Java applications. (No comment on whether that has been achieved or not. That's a different discussion.)
The issue I currently see with Linux is that the community is *not* exploiting its ability to be different in an open environment.
But from a standpoint of supporting a diverse ecology of software producers and lots of competition, the cathedral isn't the most desirable structure. It seems that when one pays a draconian cost (central control) to solve smaller problems (package dependencies, file locations), it might not be the best deal in the end.
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.:-)
Because unless you are referring to home directory installations, which is a different matter altogether
Why yes, yes I am. But I can't have an application installed to my home directory because I need to install a package. And I can't install the package, because I don't have access to the package database.
If I may be so bold, none of the "issues" leveled against the OS X APP system are inherent deficiencies in the design. For example, there is nothing that prevents a Linux APP design from adding installer/uninstaller hooks. And most installers on OS X are used for either upgrading system components (via auto-update), installing Unix components (which can't be APPed), or to manually build an APP from a highly compressed archive or tailored to the system. Nothing actually prevents such installers from being APPs themselves.
I honestly have never understood this hostility toward the APP scheme. It's a good scheme, that actually *works*, as opposed to packages that constantly *don't*. Yet OSS developers just keep sticking their fingers in their ears and screaming "I can't hear you! La la la! I *like* having a completely unremovable mess of files across the entire system! La la la! I *like* the fact that I'm screwed if my package database should every get lost or corrupted! La la la!"
Your complaint that you can't install an application as a regular user makes me wonder if you're trolling. I think everyone here knows why it's a bad idea to let anyone install anything.
Ok, why? Why should the user be prevented from having personal programs? There's certainly no restriction against fat binaries, so why not a lightweight binary?
If the concern is system security, than the installtion level is not the place to worry about it. The place to worry about it is at the runtime level. Because a determined cracker will find a way to get a user to execute his program. And once its executed, it is the responsibilty of the runtime system to protect against anything malignant.
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.
By the standard applied above Win XP's 'package manager' isn't ready for the desktop
Ok, for one, that's just putting words in my mouth. I never said that any package systems "were not ready for the desktop". I said that package systems create a dependency hell in complex systems that's just as bad as DLL Hell.
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Thirdly, *what* Windows XP package manager? The closest thing Microsoft has to such a beast is the MSI format. And that's not so much a package format (where package format is defined as a standard structure to track dependencies and thus maintain system integrity) as it is a standardized installer archive. And even then, I've met a couple of programs that I couldn't install because something was screwed up in the checks done by the MSI or Installer program.
Its a really sad day when Mac OS X becomes a potential threat to one of its close relatives.
Considering that Linux is a ground up copy of Minux, which is a ground up rewrite of a simplistic System V system, which traces its roots all the way back to K&R, with a very brief stopover at BSD for a bunch of tech, whereas OS X is a direct derivitive of Mach/FreeBSD 5.x, I fail to see how they're close relatives. Unless, that is, you are referring to the large amount of BSD technology used at various points in Linux's life?
Truthfully, I don't think anyone is threatening anyone else. Mac OS X has always been attractive to Unix lovers because of its excellent ability as a desktop/laptop/workstation operating system. This is an area that Linux is really unable to compete, despite its best efforts. Similarly, OS X doesn't really compete in the server arena despite its best efforts. This will probably change in the future, but Apple moving to Intel will have no effect on the status of relations between Linux and OS X.
After looking at the screenshots, allow me to be the first to say: Wow. That's so beautiful, it brought a tear to my eye.
The one thing that stands out at me is that Symphony uses Yet Another(TM) packaging system that is supposed to fix all the woes of the previous packaging system. Haven't we learned yet? In a complex system, packages are just as bad (actually worse) for users than DLL Hell. And they certainly don't solve the issue of maintaining the sanctity of applications, and maintaining file associations across deletes/manual installs/program moves. These are some of the greatest break points in the Windows OS. Yet Mac OS X has none of these problems thanks to its amazing.APP application scheme, and IOKit interface which tracks files by INode instead of path.
Under OS X, installation consists of downloading the application, and optionally extracting it from an archive. That's it, nothing more. You can run the app from any location (although the "standard" is the Applications folder), including right out of the DMG archive! File associations are easy: Just have the program on your hard drive. That's it! The OS takes care of querying the program for its associations. If you move the program, the OS knows. And if you delete the program, the OS removes the association. No mucking around with manual configuration. The *only* thing you can change is the default program!
Given that OS X has shown us the power of this method, why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries, but the user experience is so much better!
Uh, yeah. The sysadmins can see the packets crossing from your computer to your home server. While HTTPS prevents them from packet snooping (something that probably IS an invasion of privacy, anyway), there's nothing that can stop them from knowing that traffic is passing between your computer and the Internet. The closest thing you can do to shield your activity is to use an SSH tunnel to access a proxy server.
Well, it seems to me, and I might be way off here, that thinking up an email by an employee is in fact his company's property and hence, they have all the rights to read it, and it doesn't breaks anyone's right to privacy.
Email is considered company property, but people have gotten a little miffed because work and home tend to mix some. (No worries. It's natural as long as you keep it under control and under wraps.)
The part that amazes me these days is that people bother to send personal email through their work address when perfectly good webmail clients exist (*cough*gmail*cough*). Yes, your employer can probably see that you're surfing Gmail/Hotmail/Yahoo/Home *nix Server. However, your email is not likely to be captured by their system, and remains private.
So, why do people still use work for private mail?
Well, see, right here is a problem. It doesn't frickin' MATTER if it was "fusion" or not. All that matters is more energy out than went in.
It does matter if it was an atomic occurance or not. Because if it was a simple chemical reaction, then it would be extremely limited as a power source. i.e. No world changing power source, just another potato clock.
Figuring out *why* it works might at least provide new scientific insight, though.
You have to refuel it every couple of hours (eating), it has half the speed of a car (unless you're well trained), it's nowhere near as comfortable, its range is limited in comparison to a car, it can't use the interstates, and you smell by the time you get anywhere.
2. Solar cells and a Woodstove.
Can Solar Cells power 3 computers, 15 lights, a Television, Stero System, Alarm Clock, DVD Player, Toaster, Microwave, Refrigerator, Dishwasher, Can Opener, Hub, Monitor, Water Cooler, Water Pump, etc., etc., etc. for 24 hours a day, 7 days a week with no interruptions in service? If they could, they'd already be used by everyone.
3. Sailboat.
Have you seen many sailboats hauling a few gigatons of cargo containers on the tight schedules maintained by current ships? Sailboats are NOT an answer.
- Segment: i.e. Data and Text. Most architectures today provide memory protection against data overwritting code, and code executing in a data segment.
- Intel Segmented Memory: Intel's architecture for protecting programs against illegal memory access. This is *required* by the Intel architecture.
- Page Tables: The practice of dividing up memory into discrete pages that can assigned addresses in a virtual address space.
Most modern processors set the read only/code attributes at the page or page table levels, thus allowing for segmentation of code vs. data. Intel, however, checks the virtual pages against the physical memory segments to find if a page is data or code.
Now things will get confusing, because "segment" is such an overloaded word. As a result, I will refer to "data segments" as "data" and "code segments" as "code". "Segments" will mean Intel's segmented memory scheme, and "pages" will mean virtually addressed pages.
On the Intel x86 architecture, as long as the data pages are allocated from data segments, and code pages are allocated from code segments, the processor will enforce the inability of programs to exploit buffer overflows. This protection will fail if the two segments overlap.
That was a joke. Fusion is one of those technologies that's perpetually "20 years away". It was 20 years away in 1947, and it's 20 years away today. If and when the nut is finally cracked, it will be much more like 5 years away.:-)
Slashdot Mirror
Dragging .app directories into the trash is playing Russian roulette with your system.
People keep saying this, but I just haven't found it to be true. I've used a Mac for about two years now, and in that entire time I have never had an APP screw up my system. The only APP I have that even installs a kernel module (a VPN client) loads the module dynamically. Which means that the module will get cleared by the next reboot at the worst.
So, would someone like to produce some actual evidence of an APP damaging their system?
http://www.versiontracker.com/ - Pretty much every serious Mac user learns about this one. The reason why you're not finding any other sites is that VersionTracker is considered to be THE source.
Dragging an application to the Trash will not delete anything the application has created such as user preferences. It's a valid argument to say the user might not want them deleted, but they should at least be given a choice.
.app file.
This is very true, however NO scheme currently exists that will delete user data. Windows installers have the option, but precious few ever take that step.
Even worse is if you've installed third party drivers (my Brother laser printer driver comes to mind), kernel extensions, screen savers, preference panes and anything else that must be installed outside of an
This is still considered one of the biggest failings of the OS X install system. However, it doesn't matter too much in everyday use. The bigger issue is still the programs that everyone uses every day. OS X handles desktop programs beautifully, Windows handles them poorly but in a workable fashion, and Linux Distros just pretend to be handling them.
Reread my post. I wasn't complaining about Microsoft, I was stating that Dependency Hell is worse than DLL Hell. Nothing about DLL Hell still being an issue. :-)
I did complain about things like file associations and inability to relocate programs, however.
The thing that you can find in Control Panel > Software.
:-)
I don't have a "Software" icon. I assume you mean "Add or Remove Programs"?
If so, be aware that it is *not* a package manager under the definition I gave. If you're not clear on what a package manager is, please reread the description I gave in the grandparent post.
And I have to disagree about it sucking less than OS X. Under OS X, I just drag the applicaiton to the trash and empty it. No more program. Under Windows I have to use an uninstall program that rarely even removes all of the program files, much less extraneous files left behind.
The only weakness on OS X is the installer. However, that installer is almost never used for user programs. Only Unix utilities and system updates use it. Most users will ignore any desktop program that comes in an installer. (Which usually just builds an APP folder anyway, but the develoers didn't understand Mac distribution.)
So in summary, you're fighting anecdotal evidence with even less anecdotal evidence? :-)
Allow me to go for the gold and get a "win" in the anecdotal argument. (As much as a "win" means anything.)
Google Groups: APT package database broken (4,890)
Stating that APT is unbreakable is an undefensable position. Everything is breakable. It just so happens though, that packaging systems are seen as far more breakable than more traditional install methods, and lack many of the features of such installers. For example, there is no APT solution when I can't find VLC/XFCE/Bob's Cool Script Library/[insert your favorite package that is commonly missing] in the repository. And there's definitely no APT solution for software that CAN'T be in repository. (e.g. Oracle, Real Player, Java, etc.)
So, are you going to keep swearing at me for attempting nothing more than an enlightened discussion, or are you going to acknowledge that some issues exist and then discuss how they might best be solved?
I've had a far far worse time with OS X installers leaving crap around than with the debian package system. But I don't then claim .debs are perfect.
Indeed. But as I suggested to Bruce, there's no reason why a package management system doesn't still make sense for core APIs. That would play on the strengths of the two systems and give you the best of both worlds instead of trying to force one world to cover everything.
You need to be careful about telling people that they're Just Plain Wrong(TM). You may be very wrong yourself.
This is a debian based (apt-get) packaging system. It was one of the first, and it "fixed" all the problems you complain about in your post.
If that was true, then why did the APT system break the first time I used Debian? I forget what the exact packages were (I think it was KDE), but the system just... broke. Classic dependency hell, on a system that wasn't supposed to be breakable.
This guy just complained about the same thing. I've heard the same complaints from many others in the past. Not to mention that I'm a big fan of the BSD ports system (as close to unbreakable as you can get), and yet I've had that break on me many a time. Package systems are flawed for the same reason that programs have bugs: Humans are not perfect. The problem with a packaging system is that it's a precariously stacks structure that relies heavily on someone not screwing up. The slightest mistake and the whole thing comes tumbling down.
I won't even begin to address the issue of commercial software and software that is not yet in the repository.
To be clear, I'm not saying that all distros should just up and adopt this scheme. There's always going to be a "different strokes for different folks" mentality in the Linux community. But there *are* a variety of distros, all with supposedly different goals. Today they are all pretty much clones of each other with slight strengths and weaknesses over one another. No one has yet taken a stand and decided to do a really different distro that does attempt to appeal to the home Desktop market. The closest thing to this is the Java Desktop System, but it's really intended to be a user interface to Java applications. (No comment on whether that has been achieved or not. That's a different discussion.)
The issue I currently see with Linux is that the community is *not* exploiting its ability to be different in an open environment.
Thanks for responding, Bruce.
:-)
But from a standpoint of supporting a diverse ecology of software producers and lots of competition, the cathedral isn't the most desirable structure. It seems that when one pays a draconian cost (central control) to solve smaller problems (package dependencies, file locations), it might not be the best deal in the end.
The part that boggles my mind about this argument is that the Cathedral already exists. Distro maintainers that use central packaging systems have already agreed to be that Cathedral. If they could leverage that Cathedral slightly more (e.g. a standard API base), then there would be less work and fewer frustrations for everyone.
Because unless you are referring to home directory installations, which is a different matter altogether
Why yes, yes I am. But I can't have an application installed to my home directory because I need to install a package. And I can't install the package, because I don't have access to the package database.
If I may be so bold, none of the "issues" leveled against the OS X APP system are inherent deficiencies in the design. For example, there is nothing that prevents a Linux APP design from adding installer/uninstaller hooks. And most installers on OS X are used for either upgrading system components (via auto-update), installing Unix components (which can't be APPed), or to manually build an APP from a highly compressed archive or tailored to the system. Nothing actually prevents such installers from being APPs themselves.
I honestly have never understood this hostility toward the APP scheme. It's a good scheme, that actually *works*, as opposed to packages that constantly *don't*. Yet OSS developers just keep sticking their fingers in their ears and screaming "I can't hear you! La la la! I *like* having a completely unremovable mess of files across the entire system! La la la! I *like* the fact that I'm screwed if my package database should every get lost or corrupted! La la la!"
It's just a... weird... reaction.
Your complaint that you can't install an application as a regular user makes me wonder if you're trolling. I think everyone here knows why it's a bad idea to let anyone install anything.
Ok, why? Why should the user be prevented from having personal programs? There's certainly no restriction against fat binaries, so why not a lightweight binary?
If the concern is system security, than the installtion level is not the place to worry about it. The place to worry about it is at the runtime level. Because a determined cracker will find a way to get a user to execute his program. And once its executed, it is the responsibilty of the runtime system to protect against anything malignant.
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.
By the standard applied above Win XP's 'package manager' isn't ready for the desktop
Ok, for one, that's just putting words in my mouth. I never said that any package systems "were not ready for the desktop". I said that package systems create a dependency hell in complex systems that's just as bad as DLL Hell.
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Thirdly, *what* Windows XP package manager? The closest thing Microsoft has to such a beast is the MSI format. And that's not so much a package format (where package format is defined as a standard structure to track dependencies and thus maintain system integrity) as it is a standardized installer archive. And even then, I've met a couple of programs that I couldn't install because something was screwed up in the checks done by the MSI or Installer program.
Darn. s/Minux/Minix/g
Its a really sad day when Mac OS X becomes a potential threat to one of its close relatives.
Considering that Linux is a ground up copy of Minux, which is a ground up rewrite of a simplistic System V system, which traces its roots all the way back to K&R, with a very brief stopover at BSD for a bunch of tech, whereas OS X is a direct derivitive of Mach/FreeBSD 5.x, I fail to see how they're close relatives. Unless, that is, you are referring to the large amount of BSD technology used at various points in Linux's life?
Truthfully, I don't think anyone is threatening anyone else. Mac OS X has always been attractive to Unix lovers because of its excellent ability as a desktop/laptop/workstation operating system. This is an area that Linux is really unable to compete, despite its best efforts. Similarly, OS X doesn't really compete in the server arena despite its best efforts. This will probably change in the future, but Apple moving to Intel will have no effect on the status of relations between Linux and OS X.
After looking at the screenshots, allow me to be the first to say: Wow. That's so beautiful, it brought a tear to my eye.
.APP application scheme, and IOKit interface which tracks files by INode instead of path.
The one thing that stands out at me is that Symphony uses Yet Another(TM) packaging system that is supposed to fix all the woes of the previous packaging system. Haven't we learned yet? In a complex system, packages are just as bad (actually worse) for users than DLL Hell. And they certainly don't solve the issue of maintaining the sanctity of applications, and maintaining file associations across deletes/manual installs/program moves. These are some of the greatest break points in the Windows OS. Yet Mac OS X has none of these problems thanks to its amazing
Under OS X, installation consists of downloading the application, and optionally extracting it from an archive. That's it, nothing more. You can run the app from any location (although the "standard" is the Applications folder), including right out of the DMG archive! File associations are easy: Just have the program on your hard drive. That's it! The OS takes care of querying the program for its associations. If you move the program, the OS knows. And if you delete the program, the OS removes the association. No mucking around with manual configuration. The *only* thing you can change is the default program!
Given that OS X has shown us the power of this method, why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries, but the user experience is so much better!
Not my home webmail, https baby!
Uh, yeah. The sysadmins can see the packets crossing from your computer to your home server. While HTTPS prevents them from packet snooping (something that probably IS an invasion of privacy, anyway), there's nothing that can stop them from knowing that traffic is passing between your computer and the Internet. The closest thing you can do to shield your activity is to use an SSH tunnel to access a proxy server.
Well, it seems to me, and I might be way off here, that thinking up an email by an employee is in fact his company's property and hence, they have all the rights to read it, and it doesn't breaks anyone's right to privacy.
Email is considered company property, but people have gotten a little miffed because work and home tend to mix some. (No worries. It's natural as long as you keep it under control and under wraps.)
The part that amazes me these days is that people bother to send personal email through their work address when perfectly good webmail clients exist (*cough*gmail*cough*). Yes, your employer can probably see that you're surfing Gmail/Hotmail/Yahoo/Home *nix Server. However, your email is not likely to be captured by their system, and remains private.
So, why do people still use work for private mail?
Well, see, right here is a problem. It doesn't frickin' MATTER if it was "fusion" or not. All that matters is more energy out than went in.
It does matter if it was an atomic occurance or not. Because if it was a simple chemical reaction, then it would be extremely limited as a power source. i.e. No world changing power source, just another potato clock.
Figuring out *why* it works might at least provide new scientific insight, though.
Oh, and try to be a little more civil. Please?
s/gigatons/kilotons/g
No idea what I was thinking. Probably the fact that a metric ton is a megagram, and kiloton is a gigagram.
1. Bicycle.
You have to refuel it every couple of hours (eating), it has half the speed of a car (unless you're well trained), it's nowhere near as comfortable, its range is limited in comparison to a car, it can't use the interstates, and you smell by the time you get anywhere.
2. Solar cells and a Woodstove.
Can Solar Cells power 3 computers, 15 lights, a Television, Stero System, Alarm Clock, DVD Player, Toaster, Microwave, Refrigerator, Dishwasher, Can Opener, Hub, Monitor, Water Cooler, Water Pump, etc., etc., etc. for 24 hours a day, 7 days a week with no interruptions in service? If they could, they'd already be used by everyone.
3. Sailboat.
Have you seen many sailboats hauling a few gigatons of cargo containers on the tight schedules maintained by current ships? Sailboats are NOT an answer.
Ok, still misunderstood me. Definitions:
:-)
- Segment: i.e. Data and Text. Most architectures today provide memory protection against data overwritting code, and code executing in a data segment.
- Intel Segmented Memory: Intel's architecture for protecting programs against illegal memory access. This is *required* by the Intel architecture.
- Page Tables: The practice of dividing up memory into discrete pages that can assigned addresses in a virtual address space.
Most modern processors set the read only/code attributes at the page or page table levels, thus allowing for segmentation of code vs. data. Intel, however, checks the virtual pages against the physical memory segments to find if a page is data or code.
Now things will get confusing, because "segment" is such an overloaded word. As a result, I will refer to "data segments" as "data" and "code segments" as "code". "Segments" will mean Intel's segmented memory scheme, and "pages" will mean virtually addressed pages.
On the Intel x86 architecture, as long as the data pages are allocated from data segments, and code pages are allocated from code segments, the processor will enforce the inability of programs to exploit buffer overflows. This protection will fail if the two segments overlap.
Clear as mud?
That was a joke. Fusion is one of those technologies that's perpetually "20 years away". It was 20 years away in 1947, and it's 20 years away today. If and when the nut is finally cracked, it will be much more like 5 years away. :-)