The Challenges Of Integrating Unix And Mac OS 215
Schemer writes: "Wilfredo Sánchez, the lead developer on Darwin has posted his usenix paper, 'The Challenges of Integrating the Unix and Mac OS Environments' on the Web. In it he describes the difficulties and solutions to the problems encountered while trying to adapt BSD Unix for use with MacOS X. It's a very good read, even if you aren't a fan of the Macintosh." The OS X team have been dealing with the serious complications of mixing one established, beloved interface with another -- this is a thoughtful look from the inside at how they've dealt with it, and a good explanation of some underlying assumptions and conventions of each OS.
darwin and osx (Score:1)
Ugh (Score:1)
established, beloved interface
Honestly.
(Let the religious wars commence
--Remove SPAM from my address to mail me
Mac on BSD? No problem. (Score:1)
The real problem as far as "plain users" care (Score:1)
While fruit is nice, let's face it, that lil' devil guy is just plain cute. I'd love to see one engraved on the outside of an imac's case.
(Though I've only gotten as far as reading about the integration of the filesystems. That's one of my few complaints about Java, using the file_seperator token is just plain annoying/tedious, though it looks like that won't be an issue for working with this system, but I haven't finished reading yet.)
Re:The real problem as far as "plain users" care (Score:1)
Getting 2 together as one . . (Score:2)
___
Re:Mac on BSD? No problem. (Score:1)
He's got bigger problems than integration (Score:4)
Apple might consider spending a little effort on keeping some of its biggest supporters -- developers -- happy.
Nope, don't like at all ... (Score:2)
From starting with 'case preserving' but 'case insensitive' filenames ... ??? WTF???
Excuse me for being overly indoctrinated with Li/*nix -- but something seems wrong with this.
If your foundation is not stable, then anything you build will also be unstable. I feel this to be the case with this filesystem.
Re:He's got bigger problems than integration (Score:3)
just ask the guys at Stepwise who wrote this....
Apple might consider spending a little effort on keeping some of its biggest supporters -- developers -- happy.
Don't forget that Mac OS X is (very approximately) the combination of two previous operating systems: Mac OS 9 and OpenStep. The Mac OS 9 developers outnumber the OpenStep developers by about 1000:1
Stepwise represents only the OpenStep developers, not the Mac OS 9 developers. Apple has given the OpenStep developers a forward path through the Cocoa API layer, and several of the complaints in the Stepwise article are actually bogus.
But at the end of the day, Apple has limited resources and is trying to ship an OS within a time limit. It makes much more sense for the company to focus on getting Mac OS 9 developers on board (via the Carbon API layer) even if this is at the expense of some of the support they might, in an ideal world, give to the OpenStep community.
Apple is putting a huge effort into supporting its developer base, its just choosing where to prioritize. It knows that right now its Mac OS 9 developers are more important. Seems like a pretty sensible strategy to me.
The age-old confusion that Mac people make (Score:2)
Not a good start to the article. The operating system that Apple developed is poor at best; a single application crash almost always brings down the machine.
The interface, on the other hand, feels solid and reliable; serious thought went into every part of it.
Nice GUI, shame about the OS.
--
"Where, where is the town? Now, it's nothing but flowers!"
Warning: article contains bad grammar (Score:1)
Other filesystem problems are more subtle.
subtler
Unix achieves this by going ahead and removing the link, but the file continues to exist while it it open.
is
disappointed
This lead to the need for preemption and
leads
Spell checker and grammar checker would have caught any of those. Apple has always had a nice style in the way that it deals with anything. Too bad that this guy doesn't share that style in his writing. I'm a little saddened by this.
Re:Nope, don't like at all ... (Score:4)
From starting with 'case preserving' but 'case insensitive' filenames ... ??? WTF???
Excuse me for being overly indoctrinated with Li/*nix -- but something seems wrong with this.
I think you may have slightly misunderstood the thrust of the original article. The point was Apple has no choice in this. Everyone realises that its a less-than-perfect situation, but the new Mac OS X has to be able to work with the filesystems from Mac OS 9. This is an absolutely essential feature. Because HFS and HFS+ (the Mac OS 9 filesystems) are indeed both 'case preserving' and 'case insensitive', Mac OS X has to be able to handle this sort of filesystem. As Wilfredo says, in practice its not nearly as large a problem as it would appear at first glance. Which isn't to say its never a problem, of course...
If your foundation is not stable, then anything you build will also be unstable. I feel this to be the case with this filesystem.
This seems like a pretty large leap. The use of HFS+ as a Mac OS X filesystem is not at all "unstable". I have three machines running Mac OS X with pure HFS+ filesystems throughout. This really isn't an issue at all. The filesystem is about the most stable part of the entire OS :-)
Re:The real problem as far as "plain users" care (Score:1)
www.newgold.net
I'd love to, but neither one works.
Not the best of impressions... (Score:4)
Usually, this is the sort of thing that makes software developers run screaming down to the pub.
Charles Miler
--
Re:The age-old confusion that Mac people make (Score:2)
The first sentence I quoted, which you omitted in order to support your flawed retort, states:
Now, operating system means operating system. If he meant GUI, he should have said GUI.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:The age-old confusion that Mac people make (Score:2)
I'd say that speaks more to the quality of software available for MacOS than anything else. If the OS is less protective, that means programmers have to be a little more careful with their pointers. Contrast that with Windows, where even with its better memory management (which is highly questionable), commercially available software crashes it on a regular basis, or slows the system down to a crawl.
Application programmers are just lazy now, is all.
File MetaData (Score:4)
The interesting question is: should the day come that Linux implements metadata, could/would the Apple team merge the same Unix API into the BSD layer of OS-X?
Re:The real problem as far as "plain users" care (Score:2)
That actually seems like it'll be their biggest problem. The paper states that MacOS X will translate slashes in Mac filenames into colons when read from BSD. Um, the colon is like the universal token separator under UNIX. (Paths, passwd, etc).
A similar problem occurs where I work. The directory naming convention for packages is packagename,vX.X. Unfortunately, some programs use a comma as the separator, and you can figure out what happens.
Personally, I never get hurt by this, because I use the intersection of available characters from all OSes in my filenames. That means things like colons, slashes, commas, and usually spaces (just for easy shell access) are always out.
Re:The age-old confusion that Mac people make (Score:4)
A facetious statement at best. Application programmers have to rely on large bodies of code over which they have little or no control, e.g. MFC and other class libraries/frameworks.
And to say that a poor OS encourages good application engineering is silly, to say the least. An OS with memory protection, such as Windows NT, Unix or Mac OS X, makes it much more practical and efficient to debug applictions suffering from stray pointers, etc.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:Warning: article contains bad grammar (Score:2)
--
"Where, where is the town? Now, it's nothing but flowers!"
Darwin ? (Score:1)
Darw in [apple.com]
Re:The age-old confusion that Mac people make (Score:2)
I wasn't making any such claim, because it would be silly. A friend of mine used to code on Macs, and I've worked with Windows quite a bit. I absolutely despise both systems for their pathetic attempts at multitasking and memory management.
My point was that even with MacOS, a poorer operating system than Windows in that arena, there is a higher quality user experience (from when I've used 'em, anyway). That would imply apps on MacOS are better behaved.
Re:Nope, don't like at all ... (Score:1)
How do you explain it having worked transparently and flawlessly for Lisa/Mac users since 1983 through four major revisions then? Hmmmm?
quicktime for *nix (Score:1)
Re:The real problem as far as "plain users" care (Score:1)
Re:The real problem as far as "plain users" care (Score:2)
I said "filenames", not "pathnames". MacOS will let you have a file called "baz:foo/bar" ("foo/bar" in the "baz" directory). BSD programs will see it as "baz/foo:bar". Now, try accessing that file in a colon-delimited environment, like your password file. Or your path.
Something just occurred to me (Score:1)
a) Apple
b) Devil
Wow. Talk about really representing the Apple business plan.
Clarus the Dogcow, of course (Score:1)
Re:quicktime for *nix (Score:2)
Since the core of the OS X is unix. Does this mean that quicktime will be ported to other *nix systems?(i.e. linux)
No. QuickTime runs on top of the Carbon API layer on Mac OS X. The Carbon layer is effectively the previous Mac OS 9 API and libraries running on top of the Mac OS X BSD and Quartz layers. Moving QuickTime from Carbon/Quartz to another UNIX is no easier than moving it from Mac OS 9 to another UNIX.
If you ported Carbon and Quartz from Mac OS X to (say) Linux, then you could relatively easily move QuickTime over to Linux, but that would be a massive effort and isn't going to happen any time soon.
Re:Nope, don't like at all ... (Score:1)
So far the only problem I have encountered with this is building Python. It trys to pop the compiled "python" binary into the top level directory where there also lies a "Python" directory. A few hacks of the Makefile to change the Python directory to something else and all is well. I'm sure future distributions of Python won't have that problem.
Burris
Re:quicktime for *nix (Score:2)
People keep asking this, and the answer is probably not. The BSD layer is in the middle, underneath all the GUI stuff. Anything graphical is written using Apple's proprietary APIs.
I can imagine, though, that if you're running on PPC, something like Wine [winehq.com] might work out. And of course, you can run MacOS under Linux/PPC right now with Mac-on-Linux [ibrium.se]. (Hey, anyone know if MacOS X will work under that?)
Re:Not the best of impressions... (Score:2)
Really? It actually seemed like a pretty decent job to me, especially in the area of where to draw the line between the 2 environments. Like, MacOS programs won't delete a file that's in use, but BSD can. Which is all well and good, because if you crack open a terminal window and start rm-ing stuff, you had darn well better know what you're doing!
Heh... I remember some guy's review of MacOS X. He complained that if he did "cd directory-of-dock; ln -s ~/* .", the dock slowed down and became hard to see. (This with like 2000 files in that directory.) It was pretty funny, assuming he was joking. Well, it was pretty funny period; if he wasn't kidding, it was just funny in a different, more pathetic way. =)
interesting... (Score:1)
well, its the thought that counts.
kicking some CAD is a good thing [cadfu.com]
Re:Not the best of impressions... (Score:3)
There aren't really two operating systems at the core, the core is basically unix. All the complexity is abstracting unix so that the older MacOS standards can make sense out of it. As long as developers can shake those old MacOS standards, and write for the OSX standards, they'll do fine.
Re:He's got bigger problems than integration (Score:3)
Most of the Mac user base seems pretty happy about the direction of OS X and Apple in general -- it just the folks that had heavily invested in Objective C/OpenStep who are complaining. Would they be happier if NeXT had just gone out of business?
(I know NeXT had it's technical merits -- however the plain facts are that it was a bust in the marketplace. It makes sense to migrate that tech to someplace that someone will actually use it.
If Apple was a little smarter, they would have maybe thrown the NeXT guys a bone. They're a well-spoken, long-winded, bitchy little bunch, and having them talk trash continually can't be good when you are just about to launch your most important product in a decade.)
My Own Complaints about MacOS (Score:2)
Sad to say, I've had similar experiences with Be, Inc.'s treatment of developers. While I feel that the BeOS is a technically superior operating system for desktop machines, I think the only sensible route for a small third-party developer is to develop for an operating system which is GPL'ed.
Mike
Re:File MetaData (Score:2)
This is an excellent thought, but, I think the opposite should be considered -- Apple (building on the work done at NeXT) has come up with a design for application resource packaging that has been tested and tweaked through several generations at this point. Can the Linux team overcome its own "NIH" issues and look at adopting this as an api for Linux apps? Ditto the *BSD teams. Certainly the GNUStep teams are looking into this, but I think the core teams need to be looking into it as well.
As a WebObejcts developer, I can attest to the fact that having such a single app bundle structure can make your life a lot easier. For instance, when you go to deploy a large app on a server, some security regimes require that the actual servers should not have development tools such as a compiler available on them (to make life more difficult for crackers). As a result, you need to do your build on a staging machine and then copy over all of the bits and pieces to the production machine. This process is much easier if all you need to do is tar up one or two directories, ftp them over, and then untar them, rather than digging through the various places where stuff could end up and ftp'ing them over one by one, and trying to make sure you got them all, because there's a lot of stuff in the
For more info, look at the Mac OS X System Overview [apple.com], on page 71, where the bundle format is specified. There's a lot more to it than just the format of the directory structure; there's also default search paths, versioning (for frameworks), and more.
Just so you know, I'm a Consulting Engineer with Apple iServices [apple.com], but the opinons here are my own, not Apple's.
--Paul
Re:File MetaData (Score:2)
When you open the file you should be able to read all the data. It is a lot easier for any program that open()'s a file to just skip the "metadata" if it only wants the "data". The Mac system makes it impossible to make simple programs that copy files and also provided a fertile breeding ground for viruses.
What is needed is perhaps "meta directories" which are directories that look like regular files to most programs, but if you open a subfile by name in them you get that subfile: ie you can open "foo" and read data, or you can open "foo/bar" and get a subsctream of data. The parent data would be the entire contents of all subdirectories, so that a brain-dead "cp" would reproduce the entire tree somewhere else.
This would not conflict with anything (because you have been unable to read() a directory in any modern Unix) and would be incredibly useful.
Re:The real problem as far as "plain users" care (Score:1)
Re:File MetaData (Score:2)
Please explain to me how metadata provided a breeding ground for viruses. I guess I don't see this.
As for the "metadirectory" approach - that was actually discussed. You might go look at the archives and read the discussion: many of your concerns were discussed there.
ALBODs (Score:2)
The nicest idea I've seen is Application Logical Bundles of Data (ALBODs), which look like a tarball if you open(), stat(), etc. them, and look like a directory if you opendir(), readdir(), etc with them. Check out Treating Multiple Files as One [linuxcare.com] for Kernel Traffic's summary of the linux-kernel discussion last year on this topic.
This would allow applications to do the kind of substorage that they need to efficiently; a word processor document may have jpegs, spreadsheet tables, etc. embedded into it; things that can be more efficiently stored and manipulated as a directory full of files than as a single file. However, people don't want to manage a directory for each document, they want to manage a file. So, only new applications (or wily users; imagine being able to copy the images out of a document with "cp my.doc/*.jpg ~") that know to expect an albod actually try treating it as a directory; old tools that try to treat it as a file just get a file, so "cp my.doc my2.doc" still works without changing cp.
Unfortunately, this wouldn't let you add forks to normal files, and in fact adding forks to normal files seems impossible without breaking POSIX semantics and rewriting a bunch of old programs. You got it exactly right: "cp", "tar", "ftp", "apache", and a billion other programs act on files by simply doing an open() and read or mmap on the file. If we provide metadata at the end of that reading, then it gets copied correctly, but the program actually using the file probably breaks. If we don't provide metadata that way, then applications work unchanged, but we need to change all the applications that copy files around. And either way, what happens when you use FTP, scp, HTTP, etc to transfer your file around? Do you send the other end a tarball and leave it to the resource fork aware receiver to handle it ok? It'd be a mess.
Re:File MetaData (Score:2)
I didn't mean to imply that Linux should come up with it's own solution and Apple should then be forced to use it. However, Apple is coming at this with a very focused perspective: make old Mac programs work alongside Unix-like programs. The Linux kernel team were discussing it in a more general manner: metadata good, how do we implement it? It's possible that Apple might make choices that are more optimal within the limited problem space Apple is trying to solve that are suboptimal in the larger problem space. In that case, I'd want the more globally optimal solutions.
Obviously, if Apple comes up with a globally (near-)optimal solution (and doesn't immediately lock it up with patents), then everybody else (Linux, *BSD, even Microsoft) should be man enough to join in.
yes, but... (Score:5)
Let's do a test. On a unix system, do rm -rf
I say Bollocks to grammar (Score:1)
Re:The age-old confusion that Mac people make (Score:1)
Re: Darwin ? (Score:1)
Re:Not the best of impressions... (Score:1)
Or not shake them. You've also got to consider the investment that Mac developers have in learning the old API.
I'm in the middle of a relevant case. I programmed Macs from 1989 until 1997 or so, and I know the old Mac API very well. I've now been asked to do a Mac port of a Windows app I recently wrote. Well, I have zero experience with the new Mac API (Cocoa), and frankly, I don't want to spend the time learning it, since I plan to put most of my efforts into Linux from now on. So for me, the quickest way to get the job done is to port it as an old-style Mac program.
Bill Gates' worst nightmare? (Score:2)
--
Re:Nope, don't like at all ... (Score:1)
If you see the word 'Word' and the word 'word', are they the same? In the Real World, the answer is 'pretty much'. Most people don't need a level of specificity below that. There are, of course, emphatic reasons for total case sensitivity, but they should be obvious too (see above).
If you have a document called 'Makefile' and a document called 'makefile', they are the same file, to the uninitiated. Likewise
The real reason *nix is case sensitive is most likely because it's less computationally expensive. *nix was developed as a specific app for a specific purpose, and the decisions made back then were made with the design parameters of that purpose in mind. Just because *nix is moving to general-purpose does not mean that *nix is the most valid comparator.
Re:The age-old confusion that Mac people make (Score:1)
Kernels, file systems, network stacks, etc. are just things that geeks want to argue about.
I wouldn't consider this to be "confusion". Something that Mac people got right is a focus on user perceptions rather than upon implementation details.
What about the religious whack-jobs? (Score:1)
Next thing you know, the Southern Baptist Convention would seek to have all Mac users become subservient to their Windows-using counterparts.
MetaData is cool. (Score:3)
Now I really want to try it out (Score:1)
I've got a G4, I'm definitely going to give it a whirl and hopefully I'll be proven wrong.
Probably a better way to do this. (Score:2)
Re:The real problem as far as "plain users" care (Score:1)
Re:Not the best of impressions... (Score:1)
But from the users' point of view, things are different. If I try to load a file in program X, it's called "happy/sad: a poem"; if I try to load the same file in program Y, it's called "happy:sad/ a poem". The part of mounting drives in legacy code and having to keep it a secret from the BSD part of the OS is especially scary.
So in conclusion:
developers: yay happy fun
users: what's going on?
Re:darwin and osx (Score:1)
I have a snappy NetBSD machine down in the lab here, a Slackware box beside it. I'm using my Window Manager of choice, Hummingbird Exceed, to deliver really great X Window System performance to my Windows 2000 machine. My Windows/X integration couldn't be finer. I can go down to the start menu and pop up a session to run LyX any time I like. Heck, since I've got Interix installed on this W2K box, I could go down to the lab and open up an Xterm to this machine too. All the basic X tools are installed on W2K/Interix, and I can build about anything else that I'd like. (but of course Interix could never rival the Packages system that NetBSD provides.) I haven't ported much software over to W2K using Interix, but most of what I have tried, has worked great.
What's the problem getting Windows/Unix integration? I wouldn't be without either platform.
Re:Not the best of impressions... (Score:1)
There's always going to be a need for legacy technology and knowledge, and often it's a case of, "if it ain't broke, don't fix it." But the computer industry as a whole is a relatively new thing, and to sit back and say, well, what I know how to do now is good enough isn't wise.
Re:The age-old confusion that Mac people make (Score:1)
You left out the first sentence starting it out: "Mac OS was developed in the early-1980s around the idea of providing the best possible user experience."
What do you mean it's not a good start to the article? The article is about how the Mac OS has one of the most well-thought out GUI's, and Mac OS IS a "best-of-breed" in the user interface arena. Blasting Mac OS for lack of system stability when they're talking about how it was designed for user interface above all else is nearsighted, and frankly shows an ignorance of the basic realities of computing in the 80's. NO commercial personal computing operating system had great system stability back then.
The article is about taking the "best of breeds" from two arenas, the GUI arena and the reliability and scalability arenas and melding them together.
Dissing Mac OS as "poor" is stupid. One, a single application crash does not "almost always" bring down the machine. Frequently, yes, but I've always experienced more fatal reboot necessitating errors with Windows than with the current versions of the Mac OS. And frankly, many many people use the Mac OS daily and get tons of work done on them. Rock solid stability is not the only facet of an OS: otherwise why would Windows be so popular (aside from monopoly considerations)?
You praise the interface, then diss the OS. If the interface is so damn good, then why is the OS "poor at best"? If an OS is the standard against which modern GUI are now modeled, that means that the Mac OS is far better than "poor at best". As a matter of fact, the Mac OS belongs in the hall of fame of OSes and showing the world that user interface matters.
--
Yours,
Re:My Own Complaints about MacOS (Score:1)
Maybe that's a realistic strategy for someone who wants to sell technical support (a la Red Hat.) I don't see how you'll sell more than one copy of anything to anybody, though, and a small shop will just perish.
Re:The age-old confusion that Mac people make (Score:1)
Re:Warning: article contains bad grammar (Score:1)
Geez, did you get your Grammar Nazi badge from a cereal box?
--
Windows 95, five years later. (Score:1)
We even have the very same double-root kludge: the underlying os (DOS/unix) expects one structure, and the user another, so we have a "real" root which users are not supposed to know about, and then the friendly
And programs are supposed to move to a "package" model for un/installation, like the "add/remove program" item in the Control Panel. I predict it will take five years for Apple, too, to get that trick to work.
This is not to say that the problem could have been solved much better (although I personally think they should have discarded much more of the Unix side of the system -- they have no obligation to be backwards-compatible there!). But the net result is a less elegant system than any of the ingredients (MacOS, Unix, NeXt) that went into the brew. This makes MacOS X a much less interesting OS alternative for me.
Re:What about the religious whack-jobs? (Score:1)
--
Re:The age-old confusion that Mac people make (Score:1)
"poor" depends on your evaluation criteria.
Unix is also poor because the underlying security philosophies are multi-faceted and self-conflicting. Applications take advantage of this, and can breach the apparent security.
The MacOS is poor because the philosophy is "we're going to decide not to implement security, because we'd rather be doing UI."
What is the priority differential here?
Every OS is a combination of tradeoffs given the legacy of the initial design goals, targets, and hardware. *nix is case-sensitive because it's cheaper; the design decision was to sacrifice user semantics for performance. The MacOS is not robust because it was (is) a single-user system designed for a box with 128k of RAM and a bitmapped, wysiwyg display, so shortcuts were taken to reduce the OS footprint and complexity that, with hindsight, were skanky hacks. *nix commands are terse because the designers didn't like typing, and the pathname semantics may very well be due to the fact that the '/' key is easy to find on the keyboard.
So enlighten yourselves! Most, if not all computing was designed, and there is usually a reason behind everything you see. That reason has strange effects down the timeline, and the reason may not be what you expect.
Re:The age-old confusion that Mac people make (Score:1)
You're talking about Windows 9x, aren't you?
Windows 2000 is rock steady, NT 4.0 considerably less so, but definitely better MacOS. And what the hell? Still cooperative-multitasking??
(yes, we know MacOS 10 will be pre-emptive. Watch for the Apple marketing to finally admit it's a good thing after release...)
Re: Darwin ? (Score:1)
Re:Not the best of impressions... (Score:1)
There is the Carbon layer, and the BSD layer. The Carbon and BSD layer semantics are different, but the semantics are internally consistent within each layer. If you write Carbon, you think in Carbon. If you write BSD, you think in BSD. It's nowhere near as bad as the long pointer/short pointer stuff in Win16. It's not as bad as MFC vs Win32API.
It is a bit different, though.
Re:yes, but... (Score:2)
Oh, puh-leese! First off, don't log on as Root. Go ahead and try to delete
Yikes? There's no protection whatsoever like that on the Mac? You mean your 7 year old daughter can just go in there and waste the whole system without knowing it???
Re:Warning: article contains bad grammar (Score:1)
Would it be hard to implement something like that? Seems to me that giving registered users the ability to blackhole some of these putzes would enhance the quality of your site.
(yes, I know, Off-topic)
Re:damn shame it runs on Mach (Score:1)
--
Re:Warning: article contains bad grammar (Score:2)
To be fair, my first nit to pick is style and not grammar: "imroper, non-American, and redundant grammar" is indeed redundant from your point of view
I've seen various other grammar errors in your other posts, but have refrained from pointing any of them out to you. I suggest you pick up a copy of Sleeping Dogs Don't Lay : Practical Advice for the Grammatically Challenged or, preferably, Elements of Grammar. In any case, you can always email me for grammar tips; I proofread theses and papers for fun. To the morrow.
Re:Windows 95, five years later. (Score:2)
Quite possibly...
We now, once again, has a filesystem which is sort of compatible but loses information
You mean like Linux's support of the DOS filesystem? If I copy a Linux file to my DOS partition and back, I lose the permissions. With MacOS X, it's less radical than that; that only happens when someone uses the same physical volume on both MacOS 9 and MacOS X (which for most users will be exceedingly rare).
(compare long file NAM~1s).
That's not a good comparison; the NAM~1s creep up all over the Windows "experience", from FTP transfers and the like. Getting default permissions on a file instead of the real permissions? Bah, most users would hardly notice, especially if sensible defaults are used.
We have "special" directories which the user "should" not look into.
No, we have a UI that hides certain uncommmonly-user-manipulated directories from the user. Much like files beginning with a period in Unix. If you know they're there and want to muck with them, well, go ahead, but be sure you know what you're doing. Besides, the bsd-ish directories aren't hidden from MacOS X users in the shell window.
We even have the very same double-root kludge: the underlying os (DOS/unix) expects one structure, and the user another, so we have a "real" root which users are not supposed to know about, and then the friendly /usr/lib/desktop, no doubt.
MacOS X's structure is fairly elegant in this domain, please see the online docs at apple's website for a clue about how this is done.
And programs are supposed to move to a "package" model for un/installation, like the "add/remove program" item in the Control Panel. I predict it will take five years for Apple, too, to get that trick to work.
Well no, it's the "add/remove program" item and uninstaller type of nonsense that they're trying to get away from. Instead, they have all of an application's resources bundled up together in a single directory. This way, the user can do the intuitive thing: drag the Application from the installer disk onto their own disk, and it's installed. Drag it to the trash, and it's gone. No registry entries to clean up, no preferences folders or extensions or random little files laying around. One nice big handle to pick up a whole app by.
This is not to say that the problem could have been solved much better (although I personally think they should have discarded much more of the Unix side of the system -- they have no obligation to be backwards-compatible there!).
I think it's highly debatable whether Unix is something one is "backwards" compatible to, especially in this audience :) Going to a Unix-based OS is a very bold move, and rather than reinvinting the guts of a high performance scalable OS, they've chosen to adapt to one. With that decision comes the obligation to actually interoperate with said OS.
But the net result is a less elegant system than any of the ingredients (MacOS, Unix, NeXt) that went into the brew. This makes MacOS X a much less interesting OS alternative for me.
From what perspective is this less elegant? (and have you seen linux source code!?) It's far more elegant than letting these issues fall on the floor; instead the average user, and average developer, get a tightly integrated OS with some impressive functionality. Apple's been very good about smoothing technology transitions (e.g., x86->ppc), and this continues to be true.
My $.02
pragmatism and/or idealism (Score:2)
For a long time I really wanted Apple to come out with a new OS that would kick the pants off of System 7, and I could have cared less about backwards compatibility. I would have bought all new applications, converted my old data, and kissed the old Finder goodbye. I bet some developers at Apple would have liked to have started from scratch too.
I'm glad they didn't, because they would have left a lot of people out in the cold.
The fact that Apple is making HFS work with a unix filesystem shows that they care about thier customers. My grandfather has been a Mac user since he gave up his TRS-80 in 1988. He's published three books and dozens of papers on his two Macs. (his current a 7100 that still runs beautifully) I really think he is a poster Mac user. He is very intelligent, creative, and he has no interest at all in how his computer works - it's just a tool to him.
Tell my grandfather that to use a new operating system he'd have to give up programs he's used for 10 years, and convert all his files for use in a new filesystem, and he'd tell you that his current Mac OS was just fine.
While PC users (myself included) have been sucked into the complete hardware / software upgrade every 2.5 years cycle, the core constituency of Mac users hasn't - and asking them to change everything just wouldn't work.
So please read the complaints about the mechanics of OSX in this discussion keeping in mind the balance between pragmatism and idealism Apple has kept.
Idealism: Make a perfect OS
Pragmatism: Make it backwards-compatible
Idealism: Care about the customer enough to be pragmatic.
:-)
Re:yes, but... (Score:2)
MacOS 9 has multi-user functionality which locks down the system folder, limits the applications a given user can use, etc. It's more functional in that respect than Win98. And Apple's had that confounded shell, At Ease, around for years. With a simplified, big button interface, it's great for your 7-year-old daughter.
The real risk on any platform isn't the innocent 7-year-old; you can set up almost any OS to withstand their attack. It's the user who thinks he knows what he's doing, but doesn't, that's the real risk. If the person with the root/admin password doesn't know what he's doing--and this is the case with most home PCs--user protections are irrelevant.
Re:yes, but... (Score:2)
Tell that to Noteheads, Inc. Don't get me wrong, their Igor 1.0 Light is an excellent product by all other accounts: a musical expert system, written from head to toe in Common Lisp, which is just ridiculously full-featured: at 27 megs of RAM wastage, it's a classical composer's best friend. I've never seen a better composition program. And it's free (as in beer).
However, its installer suffers from a chronic case of the Software Egocentrism Syndrome. For starters, it's non-modal: you can't switch to other programs while installing it. That's annoying enough.
Even worse, however, is the fact that, when you done, a non-modal "notice" window pops up.
It says "your computer must be restarted".
It's only got one button: "Restart".
"But I was in the middle of..."
"Your computer must be restarted."
"But I was chatting with..."
"Your computer must be restarted."
"Lord! Why hath thou forsaken me?!?"
Ah well. Just my software installation pet peeve.
My thoughts on file "resources" (icons, etc...) (Score:2)
In my opinion, whoever came up with "data" and "resource" forks in Mac OS was an idiot. What you have is a file that is effectively two files. This is fine as long as the files are only delat with on a Mac, but when you get into file servers or trying to FTP these files across the internet, all sorts of complications arise. The two files have to be somehow combined into one. This makes it really difficult to deal with Mac files on other OS'es, as the author explains.
On Unix/Linux X applications there is, as far as I know, no way to imbed an icon in an execuatble file. If one is even included, it must come along as "icon.xbm" and be put into
Windows, or the PE executable format, I believe, has it right. The icon (and other resources) are embedded in the file, and are shown as the default icon, even though they can be changed, if you so desire.
I conclude that Unix/Linux needs either a new executable format that will allow for standardized resource embedding, or an addition to the existing executable format (whose name I forget) to allow this.
I'd like to hear other's opinions on this. I think this is one thing that would help make Linux a better desktop OS.
Re:Nope, don't like at all ... (Score:3)
Actually, I made a lot of money cleaning up after those idiots.
Programs I wrote in 1984 compile perfectly today. Anyone who followed Apple's rules for compatibility, which are 95% unchanged since the days when Inside Macintosh came in three-ring binders (I'm pretty much as old-school as a Mac developer gets) didn't have any significant problems then, and hasn't upgrading to Carbon today.
Now, before people jump all over me about API limitations, yes I realize that there's a lot of places where jobs have to be done in a non-compatible fashion. That's holding me up Carbonizing right now because all four projects I'm responsible for at my day job do CD ripping and there's no OS X equivalent of DV 22 yet. But if you were smart enough to ISOLATE those portions of the code which you knew would eventually be a problem, replacing them was straightforward then and is straightforward now. Well, will be once I get the new APIs anyway, I imagine.
So, to turn your question back
Re:My thoughts on file "resources" (icons, etc...) (Score:2)
That's because you misunderstand the problem space of the original Macintosh design. The Resource Manager was a rather elegant way to gain most of the benefits of virtual memory with no physical resource cost and a reasonably minimal runtime overhead. On a single 400k floppy 8 MHz 68000 with 22K of usuable RAM, coming up with the Resource Manager was not idiotic. Perhaps not an act of utter genius, but somewhat clever at the very least, I would think.
I conclude that Unix/Linux needs either a new executable format that will allow for standardized resource embedding...
That's a great idea! We call them "Packages" in OS X. Help yourself to the design. We don't mind, really.
Re:The age-old confusion that Mac people make (Score:2)
OT: yer sig (Score:2)
Re:pragmatism and/or idealism (Score:2)
Re:integrating win9x with unix? (Score:2)
Re:Not the best of impressions... (Score:2)
Re:u~soft knows zip of ultitasking/threading/corin (Score:2)
Re:File MetaData (Score:3)
OS/2 solved the problem of copying a file with metadata by providing an API function (DosCopy) to copy files.
Re:Probably a better way to do this. (Score:2)
Re:Probably a better way to do this. (Score:2)
Re:The age-old confusion that Mac people make (Score:2)
I agree with this. Fortunately, current versions of the MacOS aren't as bad as people make it out to be.
> So they were right to focus on marketing instead of programming?
Now that's just stupid, and not what he said at all. Focusing on the user dosn't have anything to do with marketing. Why do you think mac users are so loyal, because we like the commercials? No. It's because the MacOS is the only OS I've ever used that feels like it was designed with the user's needs in mind.
For an example of user-focused design, take a look at directory layout. If you are designing a system for use by non-techies, you want it to be obvious where files go, and what they are for. You have a 'System Folder' where all the system files go, and not
That's what people around here don't understand - a good easy to use GUI takes a lot more than a pretty window manager and a nice file manager. It has to go much deeper than that.
not necessary (Score:2)
Re:yes, but... (Score:2)
>A program can be installed at any time and that won't kill other, existing programs.
This doesn't apply to Microsoft products
A lot of the Chewy Goodness of the Mac OS is actually due to programmers voluntarily following conventions Apple has set out (i.e., the Human Interface Guidelines). Apple deserves credit for thinking beyond the OS to the entire user experience.
IMHO, the Mac GUI is simply the best thing out there (I haven't given BeOS a fair shot yet, though). What's behind the scenes in Mac OS 9 isn't nearly as nice. As a programmer, I hate how Mac memory management works. Handles might have been a good idea 16 years ago, but they sure suck now. All the pascal crap floating around in the OS is annoying, too. Of course, the user never sees any of that...
OS X should be the best of both worlds. As for the case-sensitivity weirdness, there's a simple solution: if you want backwards compatibility with Mac OS 9, use HFS+. If you want a case-sensitive file system, use UFS. You can even mix and match to get everything you need.
Namespace problems (Score:2)
WindeX?
U-knows?
I thik maybe I should call it maybe the McGuyver Operating Environment. (MOE.)
Problem with hard links?! (Score:2)
Re:The age-old confusion that Mac people make (Score:2)
Frankly, for Apple's intended market, far more time is gained in having a halfway usable GUI than in the occasional crash takes away.
Your argument seems to be based on some theoretical idea of perfection ("An OS should never crash! Ever!") rather than practicality ("If the OS occasionally crashes, but I'm much more productive on it, then I would rather use it instead."). You can't get over this perceived flaw that, apparently, isn't hurting the average person.
[not to say that stability isn't important, or that the MacOS could use some work in that regard - but it just seems that stability is your only criteria for judging the OS, when Apple's market has a much different idea in what they want.]
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com [velocinews.com])
Re:The age-old confusion that Mac people make (Score:2)
And this company is, of all people, Netscape?
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com [velocinews.com])
Re:yes, but... (Score:2)
However the posters original point is still valid, which operating system deals with loosing all of its configuration information best?
Unix - trash /etc - your screwed, boot into single user mode and hope you have a recent backup, or copy another similar machines into place and then restore by hand.
NT - trash the registry - I don't know I don't run NT, how well does it deal with this?
MacOS - trash the preferences - All applications are restored to default settings, generally if you are having problems with a MacOS program or with the OS the best thing to do is to move individual preference files.
Which one is best for Joe User? (which is who we are talking about here remember)
With MacOS, at worst Joe is going to have to ring up his ISP's helpdesk and get them to run him through setting up his account again and resetting his password.
With Unix he'd better have a friend who knows about linux - or he's going to have to rebuild the machine.
With NT/98 I suspect it involves a rebuild, or at least some windows administration skills.
Server operating systems on laptops (Score:2)
So I agree with the original complainers - it would be a bummer for the OS not to work on PowerBooks.
D
----
Re:u~soft knows zip of ultitasking/threading/corin (Score:2)
Re:The age-old confusion that Mac people make (Score:2)
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com [velocinews.com])