PDA

View Full Version : What's with the com.~ net.~ org.~ etc?



stefanlod
3rd January 2007, 09:10 PM
I've been bugged by this ever since OS X came out - classic Apps have always had nice logical names for their preferences files ("program Preferences" etc), but OS X preferences have com. or org. or net. (why the different prefixes?), and others just have normal names like in OS 9. Why bother having these names at all? Why can't they just have logical names?

iSlayer
3rd January 2007, 09:16 PM
the names are picked by each software developer so blame them ;)

forgie
3rd January 2007, 09:16 PM
AFAIK it's a Java thing - Java uses names that are the reverse of a website address for preference files. Maybe it's not Java, but another tech that does it - anyway, Apple adopted that system.

photobooth.apple.com
goes to
com.apple.photobooth

That way they are sorted in a "nice" grouped order in your file explorer.

rtc
3rd January 2007, 09:23 PM
Welcome to Unix.

Some will have you believe OSX is an awesome, intuitive, very Apple, not "sold-out" operating system, but I (and also Brains) have made several posts in the last few days declaring beliefs to the contrary.

I miss the days of logical preference file names (and a plethora of other differences).

But oh well that's change I suppose, embrace it, use it, complain or reminisce now and then, and look at all the good/better features you got in return for giving up logical preference file names etc.

It's the only approach that will keep you reasonalby sane.

Currawong
3rd January 2007, 10:20 PM
I don't see what's illogical about, say, com.apple.finder.plist. It tells me that it's Apple's Finder's preference file. I know if I want to find all the Apple preference files, I can do so without having to look for their individual names. It's also useful if you want to remove the clutter generated by an app when you un-install it. Quite impossible if a preference file has nothing indicating what program wrote it.

What you and Brains are missing are things done the old way. Old !- better always.

forgie
3rd January 2007, 10:31 PM
I too don't see what is illogical about it - a lot of UNIX ideas were based on theoretical reasoning and compartmentalisation rather then practical usage - there is definitely logic behind it all. 70s logic though it may be..... ;)

rtc
3rd January 2007, 10:47 PM
Even more logical would be "Finder Preferences" (no ".com" or file extension as they aren't relevant to the NAME of the file).

Most OSs (e.g. tiger, XP) suck royally at putting extended file information (or "meta" data or "tags" or whatever terminology floats your boat) in the main file system browser (e.g. the FInder or Windows Explorer).

So much so, that there is a huuuuuuuge industry out there devoted to providing this funcitonality (think WorkSite etc), especially now in the days where many more documents are becoming electronic-only storage to increasing degrees in some industries.

Another side effect of this is that many users resort to putting some of this data in the NAME field, where it doesn't belong, because there's no proper place for it (not their fault, the OS inability fault).

Technology such as the MS Office suite and ID3 tags and many others have brought extended file information much closer to our daily use, but it still hasn't made it into the actual OS properly. Some OSs, especially recently, have commenced representing this type of data from these technologies or apps in the OS file browsing windows (e.g. mp3 information and image information in columns in some Finder and WinXP window views). However, this is not the same as having the information stored in the file properties by the OS itself.

This is needed even more so now with the OSX walk-away from the proper and full use of the bundle bit and other resource fork items.

The best we've got is the catch-all bucket "comments" field. Pathetic.

I would rather see the following fields (columns) in the preferences window (for example):
- Name (e.g. "Finder Preferences")
- Manufacturer (e.g. "Apple Computer Inc.")
- Host application (e.g. "Finder")
- File type (e.g. "System preferences file")
- Java preference domain type (e.g. ".com")
- Version (e.g. "2.1.3")

Note that a lot of those already exist, so this implementation would be pretty simple. It's just a matter of setting them for each of the myriad of different folder types, and of course also extending the availability of customisation to developers, perhaps via the API somewhere.

I've not seen Vista in the flesh yet.

Come on Leopard I've got my fingers crossed...... (though I suspect in vain) :(

Currawong
3rd January 2007, 11:53 PM
I'm sure you'd appreciate the ARStechnica whinge regarding metadata, which is absolutely right.

The problem was that there was a mexican stand-off in Apple over the issue of file suffixes vs. metadata. That was responsible for the mess we have today. However, one benefit of the plist system is that we can view the data easily with the Plist Editor, something that wasn't readily possible with the random methods of storing prefs in OS9 apps.

forgie
3rd January 2007, 11:57 PM
Yes, Apple should really have jumped ahead of the other OSes in the metadata stakes. Here's hoping they Sort Their Shit Out™ with Leopard. It's one of those things that would be absolutely fantastic... I just can't see them getting it done.

Squozen
4th January 2007, 12:02 AM
Hey, at least I can send an image across the internet with OS X without the recipient getting 3 different files or (if it was another Mac) having no clue what to do with it at the far end.

I hate, hate, HATE the OS 9 way of dealing with metadata. It sucked and I'm glad to see the end of it.

Brains
4th January 2007, 12:30 AM
We're not missing the old ways, Curra, we're pining for the loss of simple elegance and clarity that was the hallmark of Macintosh!! Bolting a jellybean UI with a light MacSeasoning onto a stupidly complex system does not a widely-acceptible end-user experience make, yet this is what NeXT 2.0 (trading as Apple Computer Inc) try to push down our throats.

As far as I'm concerned, Mac OS, and the founding principles of Macintosh, ended with OS 9.2.2. Macintosh was "the computer for the rest of us", and as will be apparent to anyone who has read any Apple history, the driving principle was to teach computers to use human paradigms, not force humans to understand the computer's paradigms. This extended beyond the interface and into the OS itself, with an elegant hirarchy, human-parsable naming conventions, the split-file resource approach and the concept of type-and-creator meta-tagging.

This all made system maintenance a lot easier, as well as simplifying the under-structures of the OS itself. it meant I could look at any file in the System Folder, and from its file-name and icon, tell you what its purpose was, and where it fitted into the scheme of things inside the OS itself, even when the OS 9 file-count blew out to nearly 1,200 discrete files. Now we have NeXT OS X with over 12,000 discrete files in a vanilla install, taking up ten times the disk-space and ten times the RAM requirements of its alleged ancestor, without providing much advance in productive capability and with a dramatically reduced comprehension of the OS itself. Once you poke behind the jellybean-and-Aerofix-plastic-metal-grey GUI, the learning curve is steeper than the west face of K2.

NeXT OS X pays but token lip-service to What Made Macintosh Great, has fallen back onto the nerd-centric model of complexity for complexity's sake ("we coded it because we could"). with an almost pathological dis-interest in gearing the technology around non-nerd human needs and concepts. It is the Coke Zero of software.


Brains

rtc
4th January 2007, 12:32 AM
I hate, hate, HATE the OS 9 way of dealing with metadata. It sucked and I'm glad to see the end of it.

I hate it too - you missed my two (semi)unrelated points, which were:
- I've never seen an OS that handles metadata properly or makes full use of it (this includes OS9), hence users put metadata in the "name" field where it doesn't belong. If we take the preference file example, this is more obvious under OSX than under OS9, but it will differ between examples.
- I hate some aspects of the way OSX has been Unixised, including the way it uses file extensions instead of fully using bundle bits or metadata

Brains, you certainly have a way with words. I'm sold.

Notwithstanding the fact that I use and appreciate many of OSX's cool, simple, reliable, handy or productive features, I also agree with most of what you say. I reckon it begain to get off the rails somewhere in 8.? but who's counting.

I too miss the ability to know my os like the back of my hand. Now the system, with its library and coreservices gibberish (containing goodness knows what), and applications that are actually folders, is making my feeble HUMAN mind struggle with this west-face-like stuff.

Oh how lightning fast my machine runs when booted natively into pre-OSX (not classic, but the actual OS without being hosted by OSX). How productive I am, and how joyously responsive it is. Much less waiting after each click (I know its barely perceptable in OSX but I'm pretty demanding). How much more power I have, man with power over the tool (my computer and its OS) that man has created to do my bidding, rather than the other way around. How much better life would be if I could combine the good points from each OS version and have them work together in one über-OS, running all the latest and best and most useful apps natively to boot.... (hint: Leopard: come on don't disappoint me.... ah well I will face it, however good Leopard is, it CAN"T succeed in this way...)

EDIT: Oh yeah, and it's not actually token lip service, it's deliberate alignment to make the most of the brand's sales potential that had been built prior... I guess i'd expect that if I were a stockholder though.

While i think of it.

COntrast having a "is this file visible or not" flag (call it metadata if you like, but I won't, I'll call it a resource flag), with prefixing the filename with a full stop.

Something else that has nothing to do with the filename but has been pushed into the filename as a workaround, due to a lack of metadata-handling capability.

And what about spotlight indexing?

I won't start up a list of things because it'll get too damn long too damn quickly.

And yes, some would be from pre-OSX OSs and some would be from OSX. I could even throw in a heap of Windows ones if you want, but again I've not got all night.

marc
4th January 2007, 01:45 AM
the driving principle was to teach computers to use human paradigms, not force humans to understand the computer's paradigms. This extended beyond the interface and into the OS itself, with an elegant hirarchy, human-parsable naming conventions, the split-file resource approach and the concept of type-and-creator meta-tagging.
I agree with that, except that type and creator didn't really solve all the issues too well. Resource forks were a nice idea, but after having massive issues recovering some Sound Designer II files, I won't touch a file format the depends on them now (I'm AIFF all the way now).


it meant I could look at any file in the System Folder, and from its file-name and icon, tell you what its purpose was, and where it fitted into the scheme of things inside the OS itself, even when the OS 9 file-count blew out to nearly 1,200 discrete files. Now we have NeXT OS X with over 12,000 discrete files in a vanilla install, taking up ten times the disk-space and ten times the RAM requirements of its alleged ancestor, without providing much advance in productive capability and with a dramatically reduced comprehension of the OS itself.
I think that's a bit silly. OS X is ridiculously more powerful than OS 9, and with that comes more... stuff. More files, more hierarchy, more need for oganisation etc. I think some of the bloat can be attributed to the large amount of frameworks that Apple has provided for developers. Devs are really spoilt on OS X, there's some seriously cool tech and it's pretty easy to use. Not so for OS 9.

FWIW, I don't have any issues navigating around OS X... it was a bit of a shock at first, but it's really easy now. It all does make sense. And as for things being more complex... take a look at your boot HD:

Applications
Library
System
Users

I think that's about as clean as it could be. The structure of Library and System is pretty easy to understand too. My old OS 9 extensions folder was a nightmare. I think you might be seeing things through rose coloured glasses.


NeXT OS X pays but token lip-service to What Made Macintosh Great, has fallen back onto the nerd-centric model of complexity for complexity's sake ("we coded it because we could"). with an almost pathological dis-interest in gearing the technology around non-nerd human needs and concepts. It is the Coke Zero of software.
The non-tech people I'm a help desk for (read: family and g/f) don't call much for OS X help. That wasn't the case with OS 9.

I do agree that we need better use of metadata (but keep in mind we don't want to lose compatibility with other OSs). Also, I agree that the com.apple.blah.plist naming convention is pretty unfriendly for Apple, but it is easy to use. I hated trying to find all the different preference files that related to a big app in the OS 9 days. They almost never started with the same prefix and were hard to find.

marc
4th January 2007, 02:10 AM
While we're on the subject... OS X "bundles" are GREAT. Why didn't someone think of it before?

Sticking all the files related to an application in a folder, but making it look like a single file was a stroke of genius. The same goes for other uses of bundles in OS X (widgets anyone?).

Squozen
4th January 2007, 06:50 AM
We're not missing the old ways, Curra, we're pining for the loss of simple elegance and clarity that was the hallmark of Macintosh!! Bolting a jellybean UI with a light MacSeasoning onto a stupidly complex system does not a widely-acceptible end-user experience make, yet this is what NeXT 2.0 (trading as Apple Computer Inc) try to push down our throats.


Ah, yes, the 'simple elegance' of an operating system that forced YOU to tell the COMPUTER how much memory each program would require! Or, for even more fun, having to troubleshoot extensions and in some cases fudge the order they would load to stop the machine seizing during bootup...


Now we have NeXT OS X with over 12,000 discrete files in a vanilla install, taking up ten times the disk-space and ten times the RAM requirements of its alleged ancestor, without providing much advance in productive capability and with a dramatically reduced comprehension of the OS itself.

I'd say having an OS that doesn't crash every five minutes and is impervious to viruses and user error (oops, I dragged my System Folder into the trashcan and now the computer won't start...) is worth the 'reduced comprehension'. I came to the Mac from the UNIX side of things and admit I probably had a huge advantage in understanding what was going on under the hood, but I think the average user needs to pay less attention to the inner workings of the system than they did under OS 9, simply because OS X is so much more stable.

Apple has made over $10,000 from me in hardware and software sales purely because of OS X. If they had stuck with OS 9, the Mac would be dead now.

bartron
4th January 2007, 07:46 AM
.....
As far as I'm concerned, Mac OS, and the founding principles of Macintosh, ended with OS 9.2.2.....

You're kidding aren't you? OS 9 was a dog of an OS...7.5 was better but that was still holding onto legacy 1984 stuff. Apple had to move forward and they did with OS X. (os 9 was ok if all you did was talk to other Macs). If you want to stay with OS 9 and PPC and all that then you're welcome to it, meanwhile the rest of the world moves on.

edit: reading that back I'll clarify....the idea behind the Mac was to build the best computer possible with the best OS that can be used by anyone. Intel Macs running OS X based on UNIX fufills that vision.

Like it or not UNIX has decades of thought process behind why it does what it does and despite it looking complex the principles behind it are all about simplicity and re-using routines and code. If it sucked as much as you say it does no-one would be using it...insetad UNIX is the basis of pretty much every major OS that isn't made by Microsoft.

Whatever the exact reasons are for listing prefrences in the com.appl.whatever method it still makes sense as it forces everything to be groupled in a similar manner. It's a case of listing things from the most common groups to the least (think of listing a numerical date...while 04012007 is human readable it's a bugger for automatic sorting into groups...if you reverse it to 20070104 then it is instantly sortable into year, month and day).

The other advantage of UNIX is that if you don't like the way it does something you can change it....the Darwin source code is out there.

Bartron

Johnny Appleseed
4th January 2007, 08:36 AM
When OS X was released I too mourned the loss of plain-English system file names (and the addition of filename extensions). But I've since found that as an ordinary end user, I don't have to dig around in the system files that much anyway, so it's all good. OS X is good for both the average user and the *nix geek.

iSlayer
4th January 2007, 09:00 AM
This all made system maintenance a lot easier, as well as simplifying the under-structures of the OS itself. it meant I could look at any file in the System Folder, and from its file-name and icon, tell you what its purpose was, and where it fitted into the scheme of things inside the OS itself, even when the OS 9 file-count blew out to nearly 1,200 discrete files. Now we have NeXT OS X with over 12,000 discrete files in a vanilla install, taking up ten times the disk-space and ten times the RAM requirements of its alleged ancestor, without providing much advance in productive capability and with a dramatically reduced comprehension of the OS itself. Once you poke behind the jellybean-and-Aerofix-plastic-metal-grey GUI, the learning curve is steeper than the west face of K2.

You have to be kidding. OS 9 = badly built OS that has no real power and looks awful. OS X = extreamly powerful OS that looks great.
OS 9 was just crap in general. It was just a flawed OS in many ways.
I dont get why you are complaining about the amount of files either. I mean really who cares how many files there are. If it took 50,000 files to make a good OS so be it.

As for system requirements. Well yeah 10.4 needs a more modern system then OS 9. What do you expect. OS 9 is about 10 years old now. Technology has advanced. If your not willing to advance with it then stay with OS 9.


Once you poke behind the jellybean-and-Aerofix-plastic-metal-grey GUI, the learning curve is steeper than the west face of K2.

The learning curve to understand to understand OS X isnt steep at all. Its much easier then windows and much easier then virtually any other OS
If you mean the learning curve to learn what every single file in the OS does then sure its steep. So was OS 9 and so is every other OS.Just because OS 9 may have had a simpler naming scheme it doesnt mean its any easier to know what things do.Sure you might know what belongs to which app but thats not the same as knowing what the file does


NeXT OS X pays but token lip-service to What Made Macintosh Great, has fallen back onto the nerd-centric model of complexity for complexity's sake ("we coded it because we could"). with an almost pathological dis-interest in gearing the technology around non-nerd human needs and concepts. It is the Coke Zero of software.

OS 9 made the mac great ? . OS 8-9 were the worst of all the pre OS X versions.
Nerd centric.... Whats nerd centric about OS X ???
Sure there is a unix base and all that but normal users virtually never need to touch it. Apple's apps in OS X are all extreamly easy to use. None of them are nerd centric.

OS X saved the mac and there is a reason many consider it the be the greatest OS ever made. You just have to look at the OS 9 userbase VS the OS X userbase, the amount of OS 9 developers VS the OS X developers.


Anyway back to the real point of this thread. Im sure apple had a good reason for using the namin conventions they chose. Yep not as easy to find things as it was in OS 9 maybe but the fact is you rearly need to touch any of these files anyway.

Silver
4th January 2007, 09:39 AM
If you're going to complain about Meta-Data, you really have no one to blame but Microsoft. HFS+ is capable of much more in terms of Meta-Data, but when Apple moved to OS X they bowed to the convention that Microsoft had established. The vast majority of the population understands suffixes as a means of determining file type. I agree it is ugly, but it is now what is expected. Having said that, under the hood, Tiger does some really nice things with universal file type identifiers. You can determine the true file type of any file depending on what kind of meta-data you have to work with.

There are problems with OS X. Applications co-opting the Documents and Application Support folders for one, but it is a vast improvement on OS 9.

Currawong
4th January 2007, 11:11 AM
We're not missing the old ways, Curra, we're pining for the loss of simple elegance and clarity that was the hallmark of Macintosh!! Bolting a jellybean UI with a light MacSeasoning onto a stupidly complex system does not a widely-acceptible end-user experience make, yet this is what NeXT 2.0 (trading as Apple Computer Inc) try to push down our throats.

What you've forgotten is that the complexity, as it was in OS9, is hidden from the user unless they want to see it. All the "unixy" stuff, apart from the Terminal, is invisible.


As far as I'm concerned, Mac OS, and the founding principles of Macintosh, ended with OS 9.2.2. Macintosh was "the computer for the rest of us", and as will be apparent to anyone who has read any Apple history, the driving principle was to teach computers to use human paradigms, not force humans to understand the computer's paradigms. This extended beyond the interface and into the OS itself, with an elegant hirarchy, human-parsable naming conventions, the split-file resource approach and the concept of type-and-creator meta-tagging.

Everything in /Library and /System/Library is much the same as it was in OS9 - elegant hirachy, human-parsably named. What's simple to a user about resource forks and resources? What simple user wouldn't become confused as soon as you tell them "Sorry, but because of blah-blah-blah resource fork..."? WE understand resource forks, the basic user doesn't.


This all made system maintenance a lot easier, as well as simplifying the under-structures of the OS itself. it meant I could look at any file in the System Folder, and from its file-name and icon, tell you what its purpose was, and where it fitted into the scheme of things inside the OS itself, even when the OS 9 file-count blew out to nearly 1,200 discrete files. Now we have NeXT OS X with over 12,000 discrete files in a vanilla install, taking up ten times the disk-space and ten times the RAM requirements of its alleged ancestor, without providing much advance in productive capability and with a dramatically reduced comprehension of the OS itself. Once you poke behind the jellybean-and-Aerofix-plastic-metal-grey GUI, the learning curve is steeper than the west face of K2.

All that's happened is that all the files that were in a resource fork before are now in a folder. You can look at an application or bundle or whatever, it's named sensibly, you know where it fits in because it's in a logical place and you don't need Res-Edit if you want to see inside. Sure, you've got to learn a few more file types, but how hard is that? What you're objecting to is actually being able to access the hidden complexity of the system that was once hidden. So what if it's file entries instead of resources? As I said at the start - they are hidden if you don't want to see them.


I too miss the ability to know my os like the back of my hand. Now the system, with its library and coreservices gibberish (containing goodness knows what), and applications that are actually folders, is making my feeble HUMAN mind struggle with this west-face-like stuff.

How did you learn the OS like the back of your hand? You took the time. Now you've just got to take the time to learn new things.

rtc
4th January 2007, 11:11 AM
As I said, 7.5 gets my vote over 9.2 any day.

What could be simpler than Apps, Users, Library, System? How about just Apps, System?

I agree resource forks had some issues, including what you mentioned and also handling transmission (e.g. via the net) in the form of .hqx etc was made overly complex. But this I reckon was to do with the finer points of the way resource forks were implemented, rather than the idea itself.

Squozen, the memory management was trying (and almost succeeded) for the best of both worlds - have the defaults set by the app vendors (in conjunction with whether VM was running on your machine or not), but give the user the power to tweak it to their needs.

OSX has completely different memory management, which to most purposes is a much better way of doing it, but it comes with two significant drawbacks:
- the power of the user is removed
- the computer is far more resource-hungry (both HD space as virtual memory, also real RAM) than it needs to be. Consequently we need about triple the RAM we really require in order to run OSX and its apps properly.

Before you ask, yes the user (e.g. me) DOES require the ability to intervene with memory management, and yes I know this can be dangerous sometimes but give us the OPTION and naturally only those who need and understand will tinker, and at their own peril.

Troubleshooting extensions was a piece of cake, miles better than in OSX. If you have a heap of dodgy, poorly-thought-out 3rd party extensions then you were prone to running into trouble, but fixing it was a snap - just took common sense. Utilities such as "conflict catcher" made the whole process as easy as you could want it. Contrast that with disableing a troublesome extension in OSX (okay , one that the system hasn't identified itself as troublesome), let alone finding what extensions are actually running!

Applications as folders being genius? Are you mad? What happens when 'dozers on a mixed network start saving things in the folders and inadvertantly moving their contents around? Shouldn't happen I know, but more importantly the difference between a FILE and a FOLDER is pretty fundamental, and mocking it by blurring the lines is asking for trouble.

The concept that the world "is" flat has many many years of thought process behind it at one stage. Did that make it right? Well, we don't know, but we now have a more popular premise. I guess in popularity terms this makes it the greatest theory? Perhaps, but not due to its popularity - more its accuracy. Clogging up file names with "20070104" is something that belongs in the date field, not the file name field. We have several date fields: Date Created, Date Modified, Date Last Accessed. Take your pick.

I used to know the entire contents of my system folder, not just what app but also what it did. The average user may not want to know this kind of stuff, but I found it immensely useful many times. Now with OSX i have no choice but to join the ranks of average users who rely on the techos to get it right. Sure they do a good job, but not all of them all of the time.

We used to pride ourselves (as one of many points of difference) on not needing file types and on having 31-character filenames. I hope I never ever see "NEW DOCU~1.DOCX" on a Mac but it's spiralling downward in that direction.

:D

I use OSX every day and it is clearly an improveent over its predecessor in many areas. However, it has discarded some of most logical features of Pre-OSX OSs, many of which I believe would improve OSX EVEN MORE if they were applied (perhaps in some cases not applied exactlly the same way or with the same hiccups but the same logical ideal applied).

:crosses fingers: come on leopard......

marc
4th January 2007, 11:38 AM
OSX has completely different memory management, which to most purposes is a much better way of doing it, but it comes with two significant drawbacks:
- the power of the user is removed
- the computer is far more resource-hungry (both HD space as virtual memory, also real RAM) than it needs to be. Consequently we need about triple the RAM we really require in order to run OSX and its apps properly.
You have some pretty old skool notions on memory management there. I can't think of many situations where anyone could make a better choice than the OS. Plus, apps like Photoshop can restrict the amount of ram they use if that's desirable (the new PS3 beta can).


Troubleshooting extensions was a piece of cake, miles better than in OSX. If you have a heap of dodgy, poorly-thought-out 3rd party extensions then you were prone to running into trouble, but fixing it was a snap - just took common sense. Utilities such as "conflict catcher" made the whole process as easy as you could want it. Contrast that with disableing a troublesome extension in OSX (okay , one that the system hasn't identified itself as troublesome), let alone finding what extensions are actually running!
I used to have to spend ages working out confilts and managing my OS 8/9 system folder. I can't think of a time when I've had to do anything like that for OS X. I've NEVER seen an extension cause my system to crash while booting. That was very common on OS 9. And let's not talk about extensions corrupting themselves...


Applications as folders being genius? Are you mad? What happens when 'dozers on a mixed network start saving things in the folders and inadvertantly moving their contents around? Shouldn't happen I know, but more importantly the difference between a FILE and a FOLDER is pretty fundamental, and mocking it by blurring the lines is asking for trouble.
So let me get this straight... you're using a Mac. You're on a network. You've given someone using running Windows or Linux read and write privileges to your Applications folder AND they've been stupid enough to go into it and edit something. WTF??!?!?!?

You'd have to want them to be able to do it and go through quite a few steps to make it happen. And yes, I think bundles are one of the best features of OS X. It's Apple flavoured organisation with no drawbacks. Dragging one "file" to the trash to remove EVERYTHING an app needs except the preferences file is amazing. Try that on ANY other OS.

By the way, saving a document into an application bundle (ie. misplaced .doc file) wouldn't break anything.

rtc
4th January 2007, 11:38 AM
Curra I geddit but I still se unixy stuff everywhere... file paths... file system... extensions... files that are folders (apps)... folders that are files (burn folders)... nonsensical volume referencing that routs through the machine first even when its unnecessary...

Humanely named? A library is for books, or perhaps for syntax references. Stuff in the library folder should be in the system folder. That way the "system" is contained within the folder called "system". Almost what I would expect, even.

Although with the advent of the current fashion (I hope it changes) of how to store multi-user info on one volume (/users/rtc/etc, or in 'doze /documents and settings/rtc/etc.), this makes it difficult to store system and other preferences logically. This is NOT OSX's fault though.

Prior to this, the only things that lied to us were the "desktop" and the "trash". Now, most of the HFS is an illusion.

rtc.

PS... and a further thought... if OSX has allowed itself to show signs of its true parentage, UNIX (which MacOS was raped by a few years ago, resulting in the child "OSX"), then why hasn't it got some of the basics changed? Like text encoding? We used to love the fact that we could use legitimate characters (option-whatever) for special characters, keeping the current font, instead of using an illusionery workaround by using some kinda dingbats font. We used to also love that our line feeds actually worked. Nowadays our PC-cousins STILL aren't on the same wavelength, and we've done nothing effective about it at all.

marc
4th January 2007, 11:43 AM
I used to know the entire contents of my system folder, not just what app but also what it did. The average user may not want to know this kind of stuff, but I found it immensely useful many times. Now with OSX i have no choice but to join the ranks of average users who rely on the techos to get it right. Sure they do a good job, but not all of them all of the time.
Keep learning then! I'm getting closer to that with OS X. I think one of the reasons we don't all know where every file is located is because we don't need to these days.


We used to pride ourselves (as one of many points of difference) on not needing file types and on having 31-character filenames. I hope I never ever see "NEW DOCU~1.DOCX" on a Mac but it's spiralling downward in that direction.
File name extensions exist in OS X for one reason: compatibility with the rest of the world. If OS X had 40%+ market share then maybe Apple would have a shot at saying "this is the way it should be done", but they don't. And until then we all need to be able to pass files to and from Windows.

marc
4th January 2007, 11:47 AM
Humanely named? A library is for books, or perhaps for syntax references. Stuff in the library folder should be in the system folder. That way the "system" is contained within the folder called "system". Almost what I would expect, even.

Although with the advent of the current fashion (I hope it changes) of how to store multi-user info on one volume (/users/rtc/etc, or in 'doze /documents and settings/rtc/etc.), this makes it difficult to store system and other preferences logically. This is NOT OSX's fault though.
So how would you do it?

iSlayer
4th January 2007, 11:49 AM
OSX has completely different memory management, which to most purposes is a much better way of doing it, but it comes with two significant drawbacks:
- the power of the user is removed
- the computer is far more resource-hungry (both HD space as virtual memory, also real RAM) than it needs to be. Consequently we need about triple the RAM we really require in order to run OSX and its apps properly.

I think you have got that completly wrong. Users dont need to be able to control how much memory an app uses. Thats just asking for problems. I dont know if your a developer or not ( i am) but if an app runs out of ram then big problems can occur.

As far as needing triple the ram we should need.... No thats not really right either. Having the user control the ram wouldnt make any difference really in a modern OS and as i said it would end up just causing more problems.

OS X is quite good when it comes to memory management. Sure it could probably be improved a little but in general its pretty good.

rtc
4th January 2007, 11:55 AM
Marc - Photoshop (and many other high-end apps) has always been the shining light surrounded by dimness in terms of memory management (both RAM and scratch).

Divvying up the memory is done more at the start and end of an app session in OSX - e.g. say an app needs (unrealistic figures used for illustration) 20MB to run, 2MB to open your document and potentially another 200MB if you happen to want to use every single feature and open many documents. Under OSX, it earmarks 222MB on startup (most in VM), returns 2MB when you close the document and returns the other 220MB when you quit. Pre-OSX, it takes 22MB on startup (it actually takes a buffer too, so say 30MB) and only adds more if you need it. Granted, this can cause troubles later if you DO wanna use 100MB more in that app later in the session, but that is the responsibility of trapping by the app developer. That way, I can run 3 such apps at the same time, using only say 90MB of RAM instead of 666MB, which is a huge bonus if my machine only has 200MB free after booting the finder and background apps, because it only uses VM when necessary.

I agree the OSX memory management is better, I just want the control back to be able to set minimums and maximums (only if I want to), or leave it on a "let the system manage memory for this app" box. I also want to be able to turn virtual memory off completely, or for specific apps (again, at my own peril).

I also can see the bigger picture that if a coupla years go by and I get more RAM the problem disappears - but the apps will get hungrier, so it won't.

By the way I have 1GB of RAM and run OSX fine with multiple apps, but I get sick of using valuable processing power pushing memory between RAM and HDD and translating the addressing (in times when it's not necessary) and I would rather have the processor doing my tasks instead.

The windows app-bundle thing was theoretical, of course I'd never get into this situation, but I just like to keep unexposed that's all. Sometimes things happen over networks that have a perfectly good reason in hindsight but only with hindsight.

As for all the files being in one place, the AREN"T in OSX - they are strewn throughout preferences, user preferences, user documents folders, framework and services and application library folders etc all through the system, just like in any other OS. No better, no worse.

Here's an example: in winxp I can have saved web pages (.htm or .html files) managed and viewed together, so that the user never sees the folder full of images and css and whatnot but only sees the webpage file. As you say, trasning the lot in one go is a breeze in that case. However, it gives me the OPTION of having it all there in reality, so I can have the folder moved or replace files in it etc at will - what I really love about that is having the choice between the two. App bundles give me no choice.

rtc
4th January 2007, 11:57 AM
I think you have got that completly wrong. Users dont need to be able to control how much memory an app uses. Thats just asking for problems. I dont know if your a developer or not ( i am) but if an app runs out of ram then big problems can occur.

As far as needing triple the ram we should need.... No thats not really right either. Having the user control the ram wouldnt make any difference really in a modern OS and as i said it would end up just causing more problems.

OS X is quite good when it comes to memory management. Sure it could probably be improved a little but in general its pretty good.

I agree entirely, I just want the option available. I'm not suggesting opening up the possibility of an app running outta ram and running into an untrapped error.

Refer previous post re needing triple the ram.

I agree that it's quite good and could do with onl minor improvements.

rtc
4th January 2007, 12:00 PM
So how would you do it?

Excellent question, and I have no answer. In the absence of a current alternative (that I've heard of anyway) for multiple user management, the current ideas in both OSX and Win (XP anyway, I've never seen Vista) will have to prevail for now.

It's a bit of a curly one because there are circular implications for security management so if you or I or anyone could come up with a better alternative I'm sure we could rake it in if we manage it correctly!

I don't have any ideas myself though...:(

EDIT: oh yeah, and re the library not being in the system folder, I'd put it in the system folder. (whether renaming the library folder or not I don't care). That way, the whole "system" (aside from the user stuff mentinoed above) is contained in some way or other within a folder called "system".

zillatron
4th January 2007, 12:05 PM
OS X is quite good when it comes to memory management. Sure it could probably be improved a little but in general its pretty good.

I agree. By improve do you mean things like when you have Safari open for 8 days with 7 tabs it eats all the available RAM making everything slow until you quit it and restart it?

Or is that just safari's fault and not the underlying managment of the memory?

Z

rtc
4th January 2007, 12:12 PM
I agree. By improve do you mean things like when you have Safari open for 8 days with 7 tabs it eats all the available RAM making everything slow until you quit it and restart it?

Or is that just safari's fault and not the underlying managment of the memory?

Z

That reminds me of Lotus notes 5, which in some circumstances didn't actually give the memory back when you quit and you had to restart...

I would say excessive tabs and time are in practice the fault of the user more than anyone. In THEORY though, preventing unnecessary memory leaks is the sole responsibility of whoever's building (and also rigorously testing) the app. Newcomer programmers can sometimes fall into a memory management trap of sacrificing too much total memory efficiency for runtime speed (I'm not advocating one or the other, which would be a whole 'nother discussion, just pointing out that different developers produce different results).

Although the OS has a certain responsibility to cater for all apps that meet a certain standard, which should in fact be a bit below "perfect standard". How far below? Well, how long is a piece of string?

iSlayer
4th January 2007, 12:17 PM
I agree. By improve do you mean things like when you have Safari open for 8 days with 7 tabs it eats all the available RAM making everything slow until you quit it and restart it?

Or is that just safari's fault and not the underlying managment of the memory?

Z

Id say its a combination of both. Web browsers by nature user a massive amount of memory simply because of the amount of objects they have to render.

rtc
4th January 2007, 12:20 PM
As far as needing triple the ram we should need.... No thats not really right either.

Have a look at a default install of OSX, freshly booted and with no apps running. See how much RAM (also virtual and total) it uses, and tell me it's not way too much???

Most of it IMHO goes toward UI stuff, which is in the interests of longevity of the OS commercial viability and also expects hardware to have much more grunt these days (which it either does, or will). The drawback is that in the SHORT TERM ONLY, productivity of the 1% of users who are ultrapoweruberusers suffers marginally. A trade off that is more than fair I think, but it exists all the same.

The transition from Win2k to WinXP involves similar memory and hence speed issues, and for similar reasons (supposedly-funky blue-looking GUI). And is similarly fair nonetheless.

zillatron
4th January 2007, 12:23 PM
I would say excessive tabs and time are in practice the fault of the user more than anyone. In THEORY though, preventing unnecessary memory leaks is the sole responsibility of whoever's building (and also rigorously testing) the app.

How is it the fault of the user? For using the application for too long?

I want to have Safari open and ready to go whenever i need it...if that means stopping what i'm doing and putting my laptop to sleep and coming back in 3 hours or 3 days to pick up where I left off - how is it my fault the app can't handle that?

I'm askng if thats the kind of improvment iSlayer was talking about...


Well, how long is a piece of string?
Twice the distance from the middle to one end.

Z

zillatron
4th January 2007, 12:25 PM
Id say its a combination of both. Web browsers by nature user a massive amount of memory simply because of the amount of objects they have to render.

That makes sense...

Is that the kind of managment that needs to improve in the future...espically given the apparent shift to more web based apps and the like?

Z

iSlayer
4th January 2007, 12:26 PM
Have a look at a default install of OSX, freshly booted and with no apps running. See how much RAM (also virtual and total) it uses, and tell me it's not way too much???


its not to much in my opinion. If you cut down the memory usage you would also remove alot of the features of the OS.

A few hundred mb's for the base system is perfectly fine. We live in a time where every mac currently sold supports between 2gb and 16gb of memory


The drawback is that in the SHORT TERM ONLY, productivity of the 1% of users who are ultrapoweruberusers suffers marginally. A trade off that is more than fair I think, but it exists all the same.
You cant ever have a situation where everyone is happy. If you have a situation where 99% of people are happy then your doing a damn good job.

iSlayer
4th January 2007, 12:28 PM
That makes sense...

Is that the kind of managment that needs to improve in the future...espically given the apparent shift to more web based apps and the like?

Z

Yep every single web browser can improve for sure.

rtc
4th January 2007, 12:35 PM
How is it the fault of the user? For using the application for too long?

I want to have Safari open and ready to go whenever i need it...if that means stopping what i'm doing and putting my laptop to sleep and coming back in 3 hours or 3 days to pick up where I left off - how is it my fault the app can't handle that?

I too have a discerning "I am master of my technology and not vice versa" attitude. I have a windows laptop that I regularly suspend, with apps open, for speed of resume time the next morning. After a certain time (previously about 3 weeks, but now with a new TOTL laptop, about 2 months) I need to exit all the apps and reboot. Although in PC-land I need to reboot now and then anyway to get new settings and refresh network access etc. but that's hardly the point.

Technically this is the fault of the apps, as you correctly point out.

However in pracice, until every app out there is 100% perfect (and hell freezes over), we must remember that computers are machines and there are some limitations that they should be able to cope with and can't, like operating for ages and ages without gobbling memory.

Regarding the shift to web-based apps, there are a multitide of delivery methods that all have different considerations. Some choose a server-side focus, some choose a client-side focus. Of the client-side ones, some choose their own app and memory management, and some choose to be hosted by another app or plugin that manages the memory for all such content/files of the same type. Some even (shudder) rely on the browser, though to be fair they all must rely on the browser to some extent.

Web development has always had a huge element of minimising file sizes and load times and such, this will not disappear.

Enterprise-class solutions are a different story altogether.

ilostmypassword
4th January 2007, 12:42 PM
I love the fact that osx just works.... that's all i need to know :thumbup:

rtc
4th January 2007, 12:46 PM
its not to much in my opinion. If you cut down the memory usage you would also remove alot of the features of the OS.
Like the translucent blue GUI, is my point. Imagine how much worse this could become if your vector-icons kick in? And it would need a bit more in terms of resources to remember both raster (for small-displayed) and vector (for larege-size) versions. (this not meant to trigger any vector icon discussion, sorry).


A few hundred mb's for the base system is perfectly fine. We live in a time where every mac currently sold supports between 2gb and 16gb of memory
But new macs don't come with 2gb ram though, you have to buy the extra.

I remember the days when we used to bitch about OS install discs being on DVD, then on multiple CDs, then about OS installs being >1gb, etc etc etc, hey I even remember the days of saying "why should I buy the 60MB network file server, I'll NEVER need that amount of space, you're already ripping me off selling me the 40MB one"...

I guess the software and hardware development cycles seesaw a bit on which is more advanced (humgrier of the resources of the other) and in the points in between cycle parity you will always get idiots like my good self moaning about the gap one way or the other. Just ignore me and it'll pass....


You cant ever have a situation where everyone is happy. If you have a situation where 99% of people are happy then your doing a damn good job.
I agree, that's good enough for me.

zillatron
4th January 2007, 12:51 PM
they should be able to cope with and can't, like operating for ages and ages without gobbling memory.

Yep. Its not the users fault. Which was my original point :D



Z

Currawong
4th January 2007, 01:38 PM
Troubleshooting extensions was a piece of cake, miles better than in OSX. If you have a heap of dodgy, poorly-thought-out 3rd party extensions then you were prone to running into trouble, but fixing it was a snap - just took common sense. Utilities such as "conflict catcher" made the whole process as easy as you could want it. Contrast that with disableing a troublesome extension in OSX (okay , one that the system hasn't identified itself as troublesome), let alone finding what extensions are actually running!

All conflict catcher did was apply common sense and process-of-elimination, the same trick we used to try and find out what was causing a problem. In OSX, it's not different, just the locations are. Login items, user's and global Library for plugins and the like. The good thing about the global Library NOT being in /System is that we know not to touch /System, it wont become clogged up with stuff to the point we stuff around and break it, like the time an ignorant sysadmin 7 or so years ago tried to fix a mac and deleted the Finder because it was a bulky file and didn't think it was useful!




You want this back because I don't believe you understand how well OSX manages memory. The result of regaining control would be dozens of people complaining their system was running oddly because they'd stuffed around with the memory settings. Another nightmare to troubleshoot.

[QUOTE=rtc;239074]Have a look at a default install of OSX, freshly booted and with no apps running. See how much RAM (also virtual and total) it uses, and tell me it's not way too much???

Most of it IMHO goes toward UI stuff, which is in the interests of longevity of the OS commercial viability and also expects hardware to have much more grunt these days (which it either does, or will). The drawback is that in the SHORT TERM ONLY, productivity of the 1% of users who are ultrapoweruberusers suffers marginally. A trade off that is more than fair I think, but it exists all the same.

Most of it goes towards the features that allow programs to view graphics, audio and video and, consequently, 100% of users, whether professional developing multimedia or a regular user viewing a web page.

In classic Mac OS, you only had a text editor built into the system. Now you have an entire system of multimedia. If it wasn't there, each app would have to use its own memory and code to generate these things, using up MORE memory and each having its own individual problems. Then we'd be back to the days of third party apps causing all the issues. Now, in OSX, you can throw in a single Quicktime plug-in (Perian) and ANY app can play the movies that the plug-in supports. In OS9, an extension that did that, if it was dodgy, would take down the system. In OSX, it just causes things to be temperamental, and it's just as easy to remove that component to see if it is the cause of issues.

Anyway, I understand the sentimentality wanting the old days back. I personally wish they'd just coded a Finder and UI that looked identical to OS9 and was functionally the same. However, I know that the OS9 code was horrific. I still have memories of classic Mac OS going all the way back and of having to reboot the system quite often, especially after web browsers came out that used system shared memory and took down the machine on a regular basis. I'll take the future thanks.

Silver
4th January 2007, 01:43 PM
EDIT: oh yeah, and re the library not being in the system folder, I'd put it in the system folder. (whether renaming the library folder or not I don't care). That way, the whole "system" (aside from the user stuff mentinoed above) is contained in some way or other within a folder called "system".

But this is done for a good reason. the 'System' folder is the core operating system supplied by Apple. It should not contain any 3rd party software, and if you should still have a usable system if you delete your 'Library' folder (albeit with much functionality removed). This is also a result of the multi-userness:

~/Library - user level
/Library - computer level 3rd party
/System/Library - computer level Apple
/Network/Library - network level (The path may be wrong, but it is something like that).

This complaint also completely ignores the usr, bin, var, etc folders that are inherited from unix and are still present and used, but not visible.

The point is that the software in /Library are not necessarily part of the Operating System.

rtc
4th January 2007, 01:59 PM
But this is done for a good reason. the 'System' folder is the core operating system supplied by Apple. It should not contain any 3rd party software, and if you should still have a usable system if you delete your 'Library' folder (albeit with much functionality removed). This is also a result of the multi-userness:

~/Library - user level
/Library - computer level 3rd party
/System/Library - computer level Apple
/Network/Library - network level (The path may be wrong, but it is something like that).

This complaint also completely ignores the usr, bin, var, etc folders that are inherited from unix and are still present and used, but not visible.

The point is that the software in /Library are not necessarily part of the Operating System.

Put /Library into /System, the fact that you already have /System/AppleLibrary (which is called /System/Library) means you will need to rename one or both of them.

Sure have a designated place for third party stuff to distinguish it from apple stuff. But all of these places should be contained within the one /System folder I think.

It's just semantics when boiled down I guess.

The multiuser stuff I will accept for now, in the absence of a better alternative (see discussion with marc earlier in this thread).

OSX, OS9, Unix and Win all have a plethora of used/unused folders & files scattered throughout the place outside of the system folder. Either you or I could argue that these are too many or unnecessary (some of them) but it wouldn't get us far. Obviously we would stop short of discussing "thumbs.db" and ".trashes" and "system volume information" and such. Or would we?

marc
4th January 2007, 02:05 PM
As for all the files being in one place, the AREN"T in OSX - they are strewn throughout preferences, user preferences, user documents folders, framework and services and application library folders etc all through the system, just like in any other OS. No better, no worse.
Err... nup. If you ignore cross platform apps that break a lot of OS X conventions (Adobe, I'm looking in your direction), then there's really only a small percentage of apps that spew files all over your HD. Most are just one bundle in /Applications and a preference file (which isn't crucial). Copying the app is as simple as copying the bundle. What other OS does that? I can't think of any.


Divvying up the memory is done more at the start and end of an app session in OSX - e.g. say an app needs (unrealistic figures used for illustration) 20MB to run, 2MB to open your document and potentially another 200MB if you happen to want to use every single feature and open many documents. Under OSX, it earmarks 222MB on startup (most in VM), returns 2MB when you close the document and returns the other 220MB when you quit. Pre-OSX, it takes 22MB on startup (it actually takes a buffer too, so say 30MB) and only adds more if you need it. Granted, this can cause troubles later if you DO wanna use 100MB more in that app later in the session, but that is the responsibility of trapping by the app developer. That way, I can run 3 such apps at the same time, using only say 90MB of RAM instead of 666MB, which is a huge bonus if my machine only has 200MB free after booting the finder and background apps, because it only uses VM when necessary.
That doesn't sound right at all. I'm not a memory management OS X expert though, so I'll leave it alone. Keep in mind that OS X's Unix heritage means that it's pretty efficient when it comes to resources.


Here's an example: in winxp I can have saved web pages (.htm or .html files) managed and viewed together, so that the user never sees the folder full of images and css and whatnot but only sees the webpage file. As you say, trasning the lot in one go is a breeze in that case. However, it gives me the OPTION of having it all there in reality, so I can have the folder moved or replace files in it etc at will - what I really love about that is having the choice between the two. App bundles give me no choice.
So "Show package contents" is too much of an effort for you??!??!?!?! I edit files inside bundles all the time. There's nothing difficult about it at all.


I agree the OSX memory management is better, I just want the control back to be able to set minimums and maximums (only if I want to), or leave it on a "let the system manage memory for this app" box. I also want to be able to turn virtual memory off completely, or for specific apps (again, at my own peril).
Here's how to turn off VM. (http://www.macosxhints.com/article.php?story=20040809191855264)

As iSlayer said, minimums should NEVER be set by users. An app with not enough RAM is an app that crashes. As for maximums? Apps will use as much as you ask them to use (by opening documents etc).

I'm happy to have VM and modern memory management... the last thing I want to see is an "out of ram" dialogue (I used to see heaps of these using PS and OS 7).


The windows app-bundle thing was theoretical, of course I'd never get into this situation, but I just like to keep unexposed that's all. Sometimes things happen over networks that have a perfectly good reason in hindsight but only with hindsight.
So in one breath you're saying "we need more meta data and way to do cool things with it", which I'm all for, and in the next you're saying bundles are bad because they appear as folders when viewed by other OSs.

Here's a reality for you: Any cool meta data OS X has would be lost when viewing an OS X volume from another OS (that's if the other OS could even read the volume).

So at the very least, bundles are cross-platform compatible. Meta date probably won't be (unless you're using ZFS on the other OS), and resource forks certainly aren't.

rtc
4th January 2007, 02:06 PM
like the time an ignorant sysadmin 7 or so years ago tried to fix a mac and deleted the Finder because it was a bulky file and didn't think it was useful!
...
You want this back because I don't believe you understand how well OSX manages memory. The result of regaining control would be dozens of people complaining their system was running oddly because they'd stuffed around with the memory settings. Another nightmare to troubleshoot.

At least give me some credit.

Hopefully it wouldn't be dozens, because it would have warning messages all over it. If you click on the system (or even apps) folder in windows it gives you a great big warning that you shouldn't be in that folder messing around. If you turn off the "hide and protect system files" you have to read two dialogs that say "oy, I don't recommend this, if you proceed you're on your own".

[ Why to I keep referencing Win features in this thread? I'm digusted with myself! ]

I agree it's always a tough one (with designing almost anything at all) that enabling customisation yet retaining a certain level of idiot-proofness is often a trade-off to one or the other.

rtc
4th January 2007, 02:15 PM
the last thing I want to see is an "out of ram" dialogue (I used to see heaps of these using PS and OS 7).
Agree. Sadly, not all apps have these dialogs and just result in fatal errors instead.


So in one breath you're saying "we need more meta data and way to do cool things with it", which I'm all for, and in the next you're saying bundles are bad because they appear as folders when viewed by other OSs.
Spot on. The solution: put it in the file itself.


Here's a reality for you: Any cool meta data OS X has would be lost when viewing an OS X volume from another OS (that's if the other OS could even read the volume).

So at the very least, bundles are cross-platform compatible. Meta date probably won't be (unless you're using ZFS on the other OS), and resource forks certainly aren't.
Again, the solution: put it in the file itself (at the beginning of the data fork).
e.g.:
- ID3 tags
- JPEGs (and a plethora of other image and movie file formats)
- PDF metadata
- Many other files from "pro" apps, particularly those with cross-patform counterparts, e.g. most things from Adobe for starters.
- Even MSOffice files have a FORM of metadata/tagging capability that is cross-platform and resides in the files themselves (at the start of the data fork).

Granted both OSs will have to learn to read the same formats, but with the above examples they already have - the difference is that it's the 3rd party apps and not the OSs that have led the way. So far...

marc
4th January 2007, 02:19 PM
Like the translucent blue GUI, is my point. Imagine how much worse this could become if your vector-icons kick in? And it would need a bit more in terms of resources to remember both raster (for small-displayed) and vector (for larege-size) versions. (this not meant to trigger any vector icon discussion, sorry).
Firstly, I'll put money on the table that says bitmaps are here to stay for icons. Here's some previous thoughts on that. (http://islayer.com/blog/?p=87) Vectors seem like a good alternative until you actually work out what's required to get the same speed an quality we're used to.

And the "translucent blue GUI"... let's say a certain UI "widget" needed for the OS is 50 pixels wide and 10 pixels high... it doesn't really matter if it's ugly and simple or complex and pretty, it's still going to take up the same amount of space when sitting (uncompressed) in ram. The difference between having a REALLY nice looking OS and an average looking one is pretty minimal in terms of overhead, especially when you consider the bulk of the work is done by the GPU. So ram might take a hit, but CPU won't. Modern GPUs handle OS X's screen redraw with ease, even when using Exposé etc.

Silver
4th January 2007, 02:20 PM
If that is your major problem, why don't you simply add /System and /Library to your 'hidden' file? Then all you'll have when you open a window at the root level would be:
/Applications
/Users

marc
4th January 2007, 02:21 PM
Hopefully it wouldn't be dozens, because it would have warning messages all over it. If you click on the system (or even apps) folder in windows it gives you a great big warning that you shouldn't be in that folder messing around. If you turn off the "hide and protect system files" you have to read two dialogs that say "oy, I don't recommend this, if you proceed you're on your own".
THAT'S IT!! YOU'RE BANNED FROM DESIGNING ANY OS I USE! :P

rtc
4th January 2007, 02:28 PM
it doesn't really matter if it's ugly and simple or complex and pretty, it's still going to take up the same amount of space when sitting (uncompressed) in ram.

It's not only the visual stylings I'm on about, also all the transitions and effects. Things like exposé and genie effect are fine (and minimal anyway) but aren't there also things that together combine to be both intensive and unnecessary? Anything that checks the 'net in the background is a good start. I am under the impression that there are lots and lots of things that PRE-LOAD a lot of their code into memory, some of which are very poorly and uneconomically written. If this impression is incorrect, then I stand duly corrected.

Thanks for the VM-turnoff link, but despite my earlier rants I never have any intention of disabling VM under OSX.

Ideally if I lived in a perfect world I would have 16GB of physical RAM and an external RAM bank, but even then I probably wouldn't disable VM under OSX because it has been written to be too reliant on it whether it needs it or not (which granted in most cases it does).

marc
4th January 2007, 02:29 PM
Spot on. The solution: put it in the file itself.
Why? You the most efficient way to manage something that's like a folder is as a folder. Also... the way the user sees the bundle wouldn't change using your method... they'd still see a file and be able to edit it. What's the advantage in actually storing the files in a file (apart from creating filesystem chaos)?


Again, the solution: put it in the file itself (at the beginning of the data fork).
e.g.:
- ID3 tags
- JPEGs (and a plethora of other image and movie file formats)
- PDF metadata
- Many other files from "pro" apps, particularly those with cross-patform counterparts, e.g. most things from Adobe for starters.
- Even MSOffice files have a FORM of metadata/tagging capability that is cross-platform and resides in the files themselves (at the start of the data fork).
...and in doing that you'll take a massive performance hit (ever wondered why iPods use an XML database for their library? If they read the ID3 tags on the fly they'd be MUCH slower and have shorter battery life). The same applies to desktops and laptops.

Also, sticking the meta data in the files works, but it's not something that works for ALL existing file types. The only way to do that is for it to be part of the filesystem. Read up on ZFS (http://en.wikipedia.org/wiki/ZFS), because it looks like it might be the cross-platform filesystem that solves all of this and is likely to be supported on all major platforms.

rtc
4th January 2007, 02:30 PM
THAT'S IT!! YOU'RE BANNED FROM DESIGNING ANY OS I USE! :P

Sloppy, I know.

Refer:
[ Why to I keep referencing Win features in this thread? I'm digusted with myself! ]

I just should've thought of a better example that's all.

marc
4th January 2007, 02:32 PM
It's not only the visual stylings I'm on about, also all the transitions and effects. Things like exposé and genie effect are fine (and minimal anyway) but aren't there also things that together combine to be both intensive and unnecessary?
Like what? Be specific! I can't believe you want to get rid of extravagance, but KEEP Exposé!

Edit: Just on that point... the idea is that the OS has great frameworks (CoreImage, CoreVideo, CoreAnimation). These are loaded into ram when the OS boots, so you lose out there, HOWEVER, any app can use these (including the Finder etc), so the amount of ram that these effects take up ends up being quite minimal if you add it all together. Honestly though, if you hate the candy then you're on the wrong platform. Leopard adds CoreAnimation which makes it really easy for a tiny application to do some very big visual effects. We're going to start seeing them everywhere.

And again, these are mostly GPU-driven, so don't have a big performance hit.


Anything that checks the 'net in the background is a good start. I am under the impression that there are lots and lots of things that PRE-LOAD a lot of their code into memory, some of which are very poorly and uneconomically written. If this impression is incorrect, then I stand duly corrected.
Like Software Update? I like knowing that I have all the latest security patches thanks!

Again, please be specific!

rtc
4th January 2007, 02:38 PM
...and in doing that you'll take a massive performance hit (ever wondered why iPods use an XML database for their library? If they read the ID3 tags on the fly they'd be MUCH slower and have shorter battery life). The same applies to desktops and laptops.

Yeah and I value that idea of iTunes, eveen so much that I shrug off the side effect of it not writing to them either (which shouldn't really be related but is, so when I move an MP3 file to another library, itunes or not, it discards my tag changes if they're made in itunes in a certain way).

I was under the impression PDFs were designed by be darn good performance-wise. (despite this, I do see "parsing metadata" now and then in different apps with different filetypes now and then, I guess you could argue that that's too often).

DISCLAIMER: THE FOLLOWING PARAGRAPH IS ENTIRELY IN JEST:
Surely if my processor wasn't too busy processing RAM address translation to shift stuff in and out of swap files unnecessarily, It would easily be able to cope with reading a few text characters from the start of the odd file.

But I get your point.

Thanks for your input.

rtc
4th January 2007, 03:01 PM
If that is your major problem, why don't you simply add /System and /Library to your 'hidden' file? Then all you'll have when you open a window at the root level would be:
/Applications
/Users

Not an actual problem, just a theoritical one. Thanks anyway.