Apple, PLEASE fix this...

jove

jove

Member
The following is a rant...

Ever since the beta release I have been waiting for Apple to fix the software update mechanism. Yes, I have sent numerous bug reports to them.

If you, as the administrator of a Macintosh, move one of the Apple installed applications from the Application root, the updater will install pieces of the applications where it expects it to be.

So the result is the existence of not-updated software and mutant packages in the application folder!

End-users have been, for a very long time, moving applications onto their desktop willy-nilly. Run the updater and they have corrupt junk on their machine. Not everybody has a charitable Mac neighbor to fix these things.

I categorize my innumerable applications into 12 sub folders. The dock is used for only the most common. Having all applications in the same directory is unusable. Hey, let's do a flat file system!

The user, who is not warned but actually encouraged to move applications, has to know what the package mutants are and how to repair them. Does it install the incomplete packages if the user has deleted the application?

I just move all apps into the applications root before any updates and resort them after.

This really needs to be of high priority. Warn people about moving an application (just like Windows), make the updater do searches or prompts (like most third party updates), or make the system intelligent enough to know where all the apps are (bringing up a complete listing of apps does not take to long - "open with" and "open dictionary" are good examples).
 
Welcome to the UNIX (aka crappy) way of doing things.

In MacOS every app was updated by its signature (creator code). Welcome to UNIX hell, where all files are referenced by paths and are thus as fragile as a URL.


AAAAAAAAAAAAAAAAAAGH!
 
how about making shortcuts instead of moving everything, occasionally users do have educate themselves on new operating systems ;)
 
Apple really did break the file system. Creator codes allowed files of the same type to be opened by different apps (Code Warrior vs. Project Builder, Graphic Converter vs. Preview, etc). Let us not forget logically different types that share the same extension. Is the desktop database still around? We also said goodbye to multi-forked files (although packages do have a lot more flexibility).

Was it avoidable?

Since Apple purchased a UNIX OS (after four failed attempts to update their own), they had to overcome many issues. For the most part, they have done well. The OS they purchased runs with file extensions, and so does every other OS it would talk to. Almost twenty years of creator code use and no other OS, mainly Windows and UNIX flavors, has adopted the technology. Lack of extensions has been one of the biggest end-user frustrations for sending files to and from their Windows friends.

Personally, I want better support of creator codes. I hate dealing with extensions. Placing a file attribute in the name just seams wrong (like the . prefix as well). I hate the "should append?" and the "certain change extension?" warnings. I just want to change the name! I shouldn't have to worry about some damn three-character code.

UNIX does many things very well. I am not a UNIX head, but damn, my Mac hasn't crashed in ages (except when using iMovie). Crashes used to be a daily occurrence.
 
As far as filesystems go the primary problem there is UNIX itself doesn't have an API to deal with filesystems which are more rich than those used 30 years ago. Furthermore UNIX lacks API abstraction for things like links. I also really hate the fact that the filesystem root is the root of a specific volume instead of a common root. MacOS, DOS, Amiga, etc. had the opposite whereby root would be a list of volumes.

Personally I think filesystems ought to GO. They suck. The file metaphor isn't as old as computing itself and just adds a lot of complexity which isn't needed. The idea of a registry for all forms of hierarchies ought to be used then the user-managed documents could merely be 'documents' and not files. Similar to OpenDoc I guess, where there is a root document and then you can embed any document in a document.

Failing that and we have to keep on using filesystems the Cocoa API ought to be reformed so it doesn't use file paths as file primitives. This just plain SUCKS! Apple long ago deprecated functions in MacOS which used file paths so Mac apps would become less dependent on the location of files. The same ought to be done with Cocoa.

The current UNIX-like situation SUCKS. I have to keep track of what files are open and where they are at all times or something will break.
 
I have developed many object-oriented systems that abstract to a fault :) I am all for the hiding the complexities of the hardware's unit of storage (the file).

As systems become "higher level", they tend to become less general (why 4G languages tend to be very solution specific). The philosophy of the digital lifestyle seems to be to discover how to move the general utility of a computer system to a higher level - more appliance-like.

UNIX does a very good job at resource provisioning. No matter how high of level a system becomes, it is going to need those, God forgive me for saying the word, *underpinnings*. Can it use more? Apple is working very hard to layer facilities on top of it. iTunes, iPhoto, iMovie, iCal, etc manage files. The interfaces try to express the movement of data, as opposed to files.

OpenDoc failed for two reasons. It crashed more often than System 7 running MS Word 6. The business model of small applets just didn't chive with the current stock of software companies. My father-in-lay has a shirt he uses for painting that IBM handed out saying OpenDoc was going to be the savior of Warp. Sigh.

The world isn't quite ready to move the file-system out of the end-user's control/perception. Just like floppies, the consumer base is going to be VERY resistant to letting go of tangible files. I have had the batch-file vs. real-time socket programming argument countless times on the job. For now people are used to files, not high level data sets.

I agree, it does suck ... but Apple is doing fairly well with the tools and attitudes at hand.
 
Actually the hardware's unit of storage is NOT the file or even the block, but the sector. Files are a wholly unecessary metaphor and abstraction. In fact they get in the way of more finely grained storage units.

As for floppies, I didn't find ANY resistance to get rid of those. In fact I didn't find anybody using them prior to Apple dropping them. I guess I don't hang around losers (yes, seriously, what loser would use a floppy when it's the smallest, slowest, most fragile means of moving data?). Anyway I consider it a poor analogy. The problem of legacy software is far, far more difficult. Everybody including Apple is making legacy software MORE entrenched, not less! I mean crap, Apple has even given the friggin filename extension legitimacy.

UNIX and POSIX only make the problem worse with more legacy crap which we will never get rid of. Welcome to the world of everything-is-a-file and all-files-are-in-static-locations. Oh joy.

If I were to grade Apple on how they have improved the human <-> computer bottleneck in the past decade I would given them a D-. System 7 was a step forward, everything since then has been sideways. As for their "i" apps, I don't use any of them and I don't see how specific apps matter since the API and interface guidelines are at fault!

The only band-aid solution I see possible from this point is reforming Cocoa so it stops using file paths as file primitives and make this issue more clear in interface guidelines. Then Apple can fix it's horrid update system so it too doesn't use file paths.

File paths have got to GO!
 
Strobe,

Since you now have resorted to name-calling in our discussion I will post the last response.

Bit, byte, sector, block, file - they are all units a hard-disk manages; layers of abstraction. A bit is in fact the smallest unit :)

The floppy issue is more perception than reality. So-called loser friends and family of mine do not realize how little they depend on them after 15 years of constant use. You haven't seen any resistance? My what a small world you live in.

An important part of marketing a machine is balancing between breaking away and supporting existing technologies. When the whole friggin loser world uses extensions, guess what? The POSIX legacy crap has given us many standards that help computers communicate. A few bad standards are a small price to pay.

System 7 was simply a C rewrite of an old out-of-date Pascal architecture. And they added more color, woohoo. Apple did not announce that 7 was a failed attempt at modernizing the kernel. Yes 8, and 9 were feature bloat of the already crippled 7.

There is no band-aid to apply. Apple made a do-or-die decision to adopt a 10 year old but pretty advanced system. The process to evolve it into an appliance-like OS is slow, especially with all them losers clinging on to known computer concepts. It has taken the losers of the world a long time to learn that files are something tangible with boundaries.

All I want is a system that keeps track of where apps are located. I don’t care if they use paths, file IDs, or black magic. That is all implementation details. Design dictates that the requirements drive the implementation, not the other way around.

So long.
 
Originally posted by jove

System 7 was simply a C rewrite of an old out-of-date Pascal architecture. And they added more color, woohoo. Apple did not announce that 7 was a failed attempt at modernizing the kernel. Yes 8, and 9 were feature bloat of the already crippled 7.
Click to expand...

System 7 revised a large chunk of the toolbox API not to mention adding a lot more functionality. I don't know where you've been getting your misinformation, you're dead wrong here.

Your comments about the 'kernel' is quite odd considering there wasn't even a nanokernel until System 8.6. Your comments concerning Pascal is also odd considering Pascal is in no way inferior to C, and in fact its typing scheme allows for more efficient optimization than C does. Your comments about 'color' trivialize the complextity of managing different color spaces in an efficient manner, something X11 or Windows doesn't even do.

You also managed to completely ignore the POINT! What Apple did was to change how the user interacts with the filesystem by introducing the alias manager and reforming the API by deprecating functions which used file paths! Why don't you THINK what consequences such a move would make today? Consider deprecating all Cocoa methods which use NSStrings as file arguments and replace them with FSRefs or something equivalent. What happens, for example, when I move a Cocoa app while its running, or move/rename a file or one of its host directories of non-root volumes? If the application keeps track of such locations by a file path then you're SCREWED!


There is no band-aid to apply. Apple made a do-or-die decision to adopt a 10 year old but pretty advanced system. The process to evolve it into an appliance-like OS is slow, especially with all them losers clinging on to known computer concepts. It has taken the losers of the world a long time to learn that files are something tangible with boundaries.

All I want is a system that keeps track of where apps are located. I don’t care if they use paths, file IDs, or black magic. That is all implementation details. Design dictates that the requirements drive the implementation, not the other way around.

So long.
Click to expand...

You've obviously haven't given this any thought at all. If they are referenced by path then they cannot keep track of them! Not even with "black magic" can this be done. It is a limitation of the file path, not how they are used.

The "process" you talk about isn't happening. I have been pointing out this issue since Rhapsody to no avail. The fact of the matter is the programmers maintaining Cocoa don't see the problem and are simply not going to fix it. This process isn't "slow", there is no process!

You talk of "requirements", well you don't need OS X at all, you could use DOS. This fails to address the very concern which begat this thread! The issue is OS X is a fragile UNIX-like OS which is not human-friendly. You move something, it gets broken! What kind of insane system is this anyway?!

File paths HAVE GOT TO GO!
 
You must log in or register to reply here.
Back
Top