Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

The Challenges Of Integrating Unix And Mac OS 215

Posted by timothy from the apples-and-oranges-and-breadfruit-and-kumquats dept.
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.
This discussion has been archived. No new comments can be posted.

The Challenges Of Integrating Unix And Mac OS More

The Challenges Of Integrating Unix And Mac OS

Comments Filter:
  • I like the job done so far making OS X and Darwin I use and like both. Windows and UNIX would be a diff story, IMHO.

  • Ugh (Score:1)

    by seizer ( 16950 )
    As fantastic as it is, I'd hesitate to call BSD an

    established, beloved interface

    Honestly.

    (Let the religious wars commence ;-)

    --Remove SPAM from my address to mail me
  • From the paper itself, it seems almost as if there were no big problems in creating a BSD substructure for the MacOS. I wonder what the catch is?
  • Which mascot? The apple or little daemon guy.

    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.)
  • haha... I think they should use a Pie actually. Outside is the well baked MacOS crust all the users want and inside is that smoove BSD flava. Well OPENSTEP flava too. It's like a strawberry rhubarb pie. Someone pie Bill G. with that one.
  • maybe they should talk to Hemos?
    ___
  • I wish it was so simple to do anything so core to any OS. My goddess!, the hassles we've had with xMach (www.smegsite.com/xmach) in the past weeks. Writing or rewriting anything so complex, and indeed merging two seperate bodies, written by different programmers, even, in different styles, is insanely difficult. Imagine taking all those pretty Toolbox calls and all the BSD API stuff and merging them. They're gonna end up like IRIX -- applications bitching over which libraries to use -- if they aren't careful. From past experience with OPENSTEP, and the similarities (shared roots) to it, I'd say it will probably be done pretty well, in the end. It's doing not too bad right now, as it is.

  • He's got bigger problems than integration (Score:4)

    by imac.usr ( 58845 ) on Saturday June 24, 2000 @04:10PM (#978267) Homepage
    just ask the guys at Stepwise who wrote this [stepwise.com]....

    Apple might consider spending a little effort on keeping some of its biggest supporters -- developers -- happy.

  • 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)

    by gwernol ( 167574 ) on Saturday June 24, 2000 @04:19PM (#978269)

    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.

  • Apple succeeded in making Mac OS a best-of-breed operating system for personal computers: Mac OS has set the standards against which modern graphical user interfaces are now modeled.

    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!"

  • I'll correct what I can here:

    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

    ...one can do really fast searching of a volume for files with a given name in HFS+ because of how its storage is layed out. laid...you are bound to get dissapointed eventually
    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)

    by gwernol ( 167574 ) on Saturday June 24, 2000 @04:26PM (#978272)

    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 :-)

  • Check out the xMach operating system at www.xmach.org and new gold technology's page at
    www.newgold.net

    I'd love to, but neither one works. /.ed?
  • My greatest impression from reading the paper was one of a schizophrenic system. The differences between the two systems that form the basis for OSX seemed not to have been resolved, instead they were patched over with an additional layer of complexity, and a great deal of hope applied that the two different OS's at the core wouldn't misbehave and contradict each other.

    Usually, this is the sort of thing that makes software developers run screaming down to the pub.

    Charles Miler
    --

  • The first sentence I quoted, which you omitted in order to support your flawed retort, states:

    Apple succeeded in making Mac OS a best-of-breed operating system for personal computers

    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!"

  • Also, Mac OS 9.0.4 is significantly more stable than previous versions. It's probably the most stable Mac OS version out there, greatly exceeding Windows, despite Windows' "protected memory," (or lack thereof.)

    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)

    by wowbagger ( 69688 ) on Saturday June 24, 2000 @04:39PM (#978277) Homepage Journal
    One of the things that I've seen being discussed in the Kernel development threads is adding metadata support to Linux. This would allow for "resource forks", "file types", "file icons" and all sorts of other stuff that actually would be useful. Many of the problems described in the article were also brought up in the kernel thread: how do we cp/mv/tar the whole file (metadata and all) but allow open() to just get the "data fork".


    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?

  • (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.)

    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)

    by Sneakums ( 2534 ) on Saturday June 24, 2000 @04:43PM (#978279)
    Application programmers are just lazy now, is all.

    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!"

  • "More subtle" is perfecly valid English. The construction works better for some words than other; it's fine in this case.

    --
    "Where, where is the town? Now, it's nothing but flowers!"
  • I discovered the following link to the darwin kernel. Why is it that this kernel is so huge compared to the linux kernel?
    Darw in [apple.com]
  • 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.

    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.

  • If your foundation is not stable, then anything you build will also be unstable. I feel this to be the case with this filesystem.

    How do you explain it having worked transparently and flawlessly for Lisa/Mac users since 1983 through four major revisions then? Hmmmm?
  • Since the core of the OS X is unix. Does this mean that quicktime will be ported to other *nix systems?(i.e. linux)
  • My immediate thought is to have a "new blue" apple, with a daemon: sitting inside poking his head out, sitting on the ground by the apple roasting an "old apple" on his pitchfork over a fire, superimposed over the apple, take your pick or come up with a new one. Mascots and icons are the make or break of an OS, eh?
  • Actually, the paper is the other way around. The originally-MacOS-based HFS+ filesystem uses colons as its path seperator (Mac HD:Application:Simpletext), while UNIX uses slashes (/bin/echo).

    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)

    by Anonymous Coward
    Think back to stories in the bible.
    a) Apple
    b) Devil

    Wow. Talk about really representing the Apple business plan.
  • Who needs a devil, fruit, or penguin when you can have the state of the art genetically engineered mascot

  • 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.

  • NTFS works the same way. Preserves case but not case sensitive. Sure, it's annoying, but it's not that big of a deal and it makes OS-X compatible with all of the legacy Macs as well as NT/Win2k desktops.

    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
  • Since the core of the OS X is unix. Does this mean that quicktime will be ported to other *nix systems?(i.e. linux)

    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?)

  • Usually, this is the sort of thing that makes software developers run screaming down to the pub.

    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. =)

  • ya know... there's an interesting discussion over at cad-fu [cadfu.com] about how all software is going to the ASP model. Now, you merge that with some transmeta type action, and boom, you have the software that runs through the internet everywhere. or do you?
    well, its the thought that counts.


    kicking some CAD is a good thing [cadfu.com]

  • Re:Not the best of impressions... (Score:3)

    by cowscows ( 103644 ) on Saturday June 24, 2000 @05:25PM (#978294) Journal
    Well, it is to a degree, two fairly different systems cobbled together. This was mostly done in the name of backwards compatability though, to keep all the older mac software running happily. That's what Carbon is all about. Apple is hoping that developers will write all their new stuff for Cocoa, which isn't just a combination of the two OS', but rather an evolution that takes parts from both, as well as some new and improved stuff. Writing for it won't be making a program that'll run under both MacOS and BSD, but one that'll run under OS X.

    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)

    by MrBogus ( 173033 ) on Saturday June 24, 2000 @05:27PM (#978295)
    Bottom line is that, after years and years in denial, the NeXTStep crowd just figured out about 6 months ago that their high budget OpenStep-on-Wintel consulting market is dead. They just can't/won't adjust to selling software and services on a low-end home user platform, and are lashing out at Apple.

    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.)
  • When I decided to stop being a MacOS developer and become a BeOS developer, I wrote I'm Worried about My Future. That's Why I'm a Be Developer [scruznet.com].

    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

    Tilting at Windmills for a Better Tomorrow


  • 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?

    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 /usr/share tree of your develoment machine.

    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
  • I hope Linux/Unix never does this.

    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.

  • How about the little guy tossing an apple core in a recycle bin (^^ [linux.com])
  • The Mac system makes it impossible to make simple programs that copy files and also provided a fertile breeding ground for viruses.
    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.
  • One of the things that I've seen being discussed in the Kernel development threads is adding metadata support to Linux.

    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.
  • 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.
    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)

    by Ukab the Great ( 87152 ) on Saturday June 24, 2000 @05:52PM (#978303)
    Mac OS is built like a tank in the areas that really count in the area of average user computing. A program can be installed at any time and that won't kill other, existing programs. Similarly, a program that is already installed will never preclude another program from being installed (like RPM does). And if you delete all the mac OS configuration files, programs can still run. How many times has someone installed one windows program and this has totally killed another working program? Or the registry got corrupted in one particular area and dragged other areas down with it? Or how many times has someone has tried installing a linux application, only to find out they have to screw around with environment variables to even get the program to start up. Mac OS doesn't have these problems, and in the Reality That Is The Average Joe Consumer Desktop(tm), crashing is far less of a concern than something not running at all or something screwing up the computer. A crash in this area of computing is an annoyance, something failing to work at all is completely unacceptable.

    Let's do a test. On a unix system, do rm -rf /etc, on windows delete the registry, and on MacOS, trash the preferences folder. Reboot and see which computer has the most functionality that an average computer user requires. Guarentee you it won't be the first two. Which is unfortunate since it would be great if linux and windows had the system/application integrity that consumer level usage requires. True, anyone geek enough could fix the first two computers, but keep in mind that most average joe computer users are not like us geeks.
  • This is Apple "we don't need no stinkin' grammar around here" Computers we're talking about here. Their slogan is "Think Different". They could have chosen "Think Differently" or, "Choose a different way in which to think" but no, Apple thinks different. Anyone who has a problem with Apple's grammar can eat my balls.
  • Programmers have to program more carefully *because* the Mac OS has no real memory management to speak of. That's like saying 'Cars should be built with no safety features, so that drivers will HAVE to be more careful.
  • Because it's not the kernel, it's the whole OS distribution.
  • 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.

    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.

  • Wanna bet Bill Gates is losing sleep over the possibility of an essential merger between the Mac and Linux communities, based on a (presumably) evolving interoperability and transparent portability between the two?

    --

  • Re:Nope, don't like at all ... (Score:1)

    by Anonymous Coward
    Well, there are design tradeoffs that may seem silly to the uninitiated, but may actually have value.

    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 /dev/dsk/c0t1d0s0 and /dev/dsk/c0t1d0S1.

    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.
  • To most users, the GUI is the operating system. It is the thing that makes their computer work.

    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.

  • Can't have the little devil guy (cute as he may be) because we have too many religious whackos here in the US. The Mac would be banned in the South. Steve Jobs would be branded a heathen. They'd probably burn all copies of OS X, thinking it's the third sign of Satan.

    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)

    by be-fan ( 61476 ) on Saturday June 24, 2000 @06:20PM (#978312)
    Meta data is a seriously nifty concept if implemented correctly. BeOS has a similar (though much superior, read up on it) system called attributes. Not only does it allow for info such as icon to be stored within an attribute attached to the file, but it allows things like bookmarks to be implmented entirely as attributes. The cool thing about that is that since attributes are indexed by the file system, they are searchable database style! The contacts database is a set of files with attributes, and just by moving a file into a directory you get an instantly searchable database of contacts. Of course, it necessitates some additional stuff. open() can't read attributes (and it probably won't be able to read meta data, an alternate OS call would have to be implemented). Also, you'd have to switch to something like the .zip format because gzip and tar don't preserve attributes or metadata. If it can be done within the Linux architecture, I think it should. ReiserFS is getting database functionality eventually, and if you could connect the two, you could do some nifty tricks. (And isn't that what Linux is all about? :)
  • I was really looking forward to the released code, but after reading the paper, my impression is that of a mess created out of sheer market necessity instead of a beautiful combination of MacOS front end and Mach/BSD back end.

    I've got a G4, I'm definitely going to give it a whirl and hopefully I'll be proven wrong.
  • I think the NT guys have the right idea on how to support backwards compatibility with two different OS architectures (don't laugh!) Microkernel OSs (like NT) use servers to provide system services to applications. In NeXT there is a BSD system server running on top of Mach. NT has POSIX, OS/2, DOS, and Win32 servers running on top of the NT kernel. What the MacOS X people should have done is have a BSD/Cocoa server along with a Carbon server running next to it. What they chose to do is layer it instead (Carbon / BSD /Mach). I have a bad feeling that comes more from the macrokernel approach of MacOS than any conscious design decision.
  • shit i didnt change my sig yet. heh. we had umm severe server troubles... i.e. IDE controller failure on a machine out of warranty. the site was being redirected to our colocation anyways -- a nice fast site as opposed to our DSL cnx hehe... www.smegsite.com/xmach
  • It has to do with the users not the developers. Apple has done everything they can to make sure that the developers don't have to do anything (and it looks like they've done a good job). Assuming they're 100% perfect coders and do not have any bugs, all MacOS and all BSD programs should run unmodified together in fairyland.

    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?
  • What do you mean?

    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.
  • Well, then find someone else to do it. The quickest way isn't always the best. As fast at the computer field moves, there's a lot of legacy technology in it. Sometimes you have to bite the bullet and just leave the old stuff behind in the name of progress. This isn't like giving up century old cultural tradition, it's technical evolution, and it's defiantely a good thing, although not necessarily an easy one. Apple pushes this a lot, particularly in hardware. The iMac only had usb ports for peripherals at a time where usb wasn't all that common (despite having been around for quite some time). Love or hate the iMac, there's not denying that it caused a usb device flood that intel was having no luck doing on its own. Yeah, people's old ADB mice and joysticks and whatnot wouldn't work on the imacs, so they had to buy new stuff, but in the end, isn't that kind of a good thing?

    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.

  • Mac OS was developed in the early-1980s around the idea of providing the best possible user experience. Apple succeeded in making Mac OS a best-of-breed operating system for personal computers: Mac OS has set the standards against which modern graphical user interfaces are now modeled.
    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.

    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,

  • I think the only sensible route for a small third-party developer is to develop for an operating system which is GPL'ed.


    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.
  • Ok but lets play devils advocate here. The OS sucks major donkey balls. After dealing with a lab full of mac classics for a year, I will be the first one to agree. Maybe this is the reason why they are trying to integrate BSD in as the new system OS of choice......finally beef things up to something a bit more robust......Personally I will be interested to see what happens....IF they do this right, they could win a lot of people over imho.......
  • "Subtler" is more efficient and Arian then "more subtle"

    Geez, did you get your Grammar Nazi badge from a cereal box?
    --

  • Am I the only one who thinks these design decisions seem awfully similar to what MS choose to do for backwards copatability with DOS? We now, once again, has a filesystem which is sort of compatible but loses information (compare long file NAM~1s). We have "special" directories which the user "should" not look into.

    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.

    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.
  • The Apple logo already has interesting religious connotations that I'm sure somebody, somewhere, objects to. Or has the significance of an apple with a bite out of it been totally lost on most people?

    --
  • sigh. Why must I reply to these slashdot puppies? Guess I have nothing better to do than whomp on the ignorant.

    "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.
  • It's probably the most stable Mac OS version out there, greatly exceeding Windows, despite Windows' "protected memory," (or lack thereof.)

    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...)
  • That's not just the kernel, it's more like an entire precompiled freebsd distro. The kernel is just one linux-kernel-sized file inside that big ol' self-mounting image archive.
  • well actually, it is confusing, but only if you are looking at both levels at once as the author does.

    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.
  • On a unix system, do rm -rf /etc, on windows delete the registry, and on MacOS, trash the preferences folder.

    Oh, puh-leese! First off, don't log on as Root. Go ahead and try to delete /etc. On NT, configure it so you don't run all the time with Administrator level priveledges. Try to delete the Registry.

    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???
  • Rob, we need a killfile of some sort here.

    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)
  • DP4 is reportedly crammed full of debug code, and some components (e.g. QuickTime) are still extremely unoptimized. At least wait for the public beta before declaring it slow.

    --
  • I'm shocked by you, grammar nazi. Though you usually find a couple of the more egregrious grammar errors in documents and miss the more subtle ones, I find it amazing that you make so many in your posts.

    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 ;). Additionally, according to my 20 volume OED (as well as dictionary.com), "Arian" refers to one born under the sign of Aries or relating to the Roman bishop Arius. Perhaps you were looking for "Aryan," which refers to the Nordic Caucasian gentiles of Nazism.

    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.
  • Am I the only one who thinks these design decisions seem awfully similar to what MS choose to do for backwards copatability with DOS?

    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

  • This article goes a long way towards rebuilding my respect for Apple, which began to wither years ago when Copland never appeared.

    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.

    :-)
  • 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???

    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.

  • A program can be installed at any time and that won't kill other, existing programs.

    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.
  • Of all the ways of dealing with file resources, I think only the Windows format has got it right. When I speak of resources here, I will limit my discussion to the icon for an executable file.

    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 /usr/share/icons or somewhere. Personally, I have always hated this. I like programs to have a known icon associated with them. For one, it makes them easier to recognize when using other's systems.

    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)

    by Snocone ( 158524 ) on Saturday June 24, 2000 @08:21PM (#978353) Homepage
    Transparent and flawless? I guess you've never talked to anybody who went through the 68K/PPC conversion kicking and screaming, eh?

    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 ... guess you've never talked to any Mac OS developer with a CLUE, eh?
  • In my opinion, whoever came up with "data" and "resource" forks in Mac OS was an idiot.

    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.
  • It would probably read more correctly if he had said "Mac OS is a best-of-breed desktop environment for personal computers". Obviously the core kernel of MacOS is utter crap, that's why they are moving to Mach/BSD, to bring the OS kernel into the 90's.
  • gratuitous talking heads reference?
  • Many of Apple's customers are ones that have been customers for many years, there are plenty of these customers along with brand new ones that just want something to get on the internet. If you've been using Photoshop or Premiere for years on the Mac and knows all the ins and out and shortcuts to get things done quickly, why would you want to switch to a different OS? That is why people go from their trust 7100 and 9600's to the G4 Macs. They want to use the same software, they just want it to run a bit faster.
  • Do you have the faintest clue why it is not feasible to port Mac OS over to x86 hardware? If you can put Unix and user friendly on the same box then you're going to rush boxes out the door. The problem here is that Apple produces their software and hardware and therefore don't need to worry much about third party driver support with their hardware. When you port OS X over to Intel hardware you're got people wanting to stick it on their 400$ chump change PC with parts that have absolutely no drivers for the new OS. If you've ever tried getting X to work on a POS cheap PC you're really out of luck. Since hardware vendors are reluctant to spend the money to produce Linux drivers, why the fuck would they produce OS X drivers? I don't think GNU Beta home brew drivers are going to fly with the ease of use crowd.
  • Why should he write his application for Cocoa? Mac OS X hasn't been released yet and it will be quite a while before it becomes the dominant OS on the Mac. If he writes it for Carbon, it will work on current and future Mac systems.
  • The problem with Win95 and 98 was that they run apps in a virtual machine; there is an 8, 16, and 32 bit VM that is launched when an 8, 16, or 32 bit program is launched. DOS apps are each run in their own separate VM which means they won't kill other DOS apps (usually). The main stability problem is in the 16 bit arena. All 16 bit processes are run in one large memory space and cooperativly multi-tasked. This means a fault is one 16 bit app (library, extension, ect) will take out all of the 16 bit apps. Things arent really run in a layered fashion, 16 bit resources are just managed in one big heap on top of the process scheduler which make it seem like you're working through layers. Unix also has a process scheduler which does the same thing as the one in Windows, it is the basis of multi-tasking and premptive multitasking. The ability ro run KDE apps in GNOME has nothing at all to do with the system's scheduling and process handling, it has to do with the libraries that are available. As long as a program can access the libraries it needs it can run since both GNOME and KDE are running on top of X.

  • Re:File MetaData (Score:3)

    by Detritus ( 11846 ) on Saturday June 24, 2000 @11:50PM (#978380) Homepage
    OS/2 supports metadata in the form of extended attributes. NT tried to get rid of extended attributes but added stream support to files in the NTFS file system, although I'm not aware of any programs or operating system functions that use them.

    OS/2 solved the problem of copying a file with metadata by providing an API function (DosCopy) to copy files.

  • I'm sorry, but you're information is totally wrong. NT is a microkernel, it does messaging, and the OS/2, DOS and POSIX servers are actual servers. True, the Win32 server provides I/O support for the other servers and the microkernel runs drivers and other servers in kernel space, but they are still seperate servers and communicate by passing messages. Read BYTE circa 1993 to read about the introduction of WindowsNT. One issue in particular deals with microkernel OSs and covers WinNT, WorkplaceOS (the planned successor to OS/2), QNX, Chorus, and Taligent. One section in particular about "personalities" tells that NT uses servers to provide the OS/2, DOS, and POSIX personalities.
  • Of course, these issues would still exist, but the whole architecture is made cleaner through the server approach and is just easier to manage.
  • > Even the users that would rather not know about the internals of the system will encounter it sometimes.

    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 /etc, /dev, /var, and so on. There is no reason you couldn't have a /system, and put all those things in there, but Linux/Unix isn't designed from the user point of view.

    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.
  • Have you heard of the 'file' command? It isn't perfect, but it works most of the time.
  • That's not entirely true...

    >A program can be installed at any time and that won't kill other, existing programs.

    This doesn't apply to Microsoft products :-) Installing Internet Explorer 5, Outlook Express 5, and Outlook for Exchange in the wrong order will break one or more of those applications. Of course, Microsoft's sloppy practices with shared libraries are hardly Apple's fault. There are a few other programs where deleting the preferences hoses the app, but that's also because the programmers didn't do things the way they're supposed to.

    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.
  • I use similar configs. My problem is what to call my hybrid beasties:

    WindeX?

    U-knows?

    I thik maybe I should call it maybe the McGuyver Operating Environment. (MOE.)

  • I didn't understand why they cannot integrate hard links, the author only seems to explain the consequences, not the reason for it. Anyone care to explain?!
  • If the net result is that it's safer on the road, and fewer people die, then wouldn't it stand that it's a Good Thing?

    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])
  • So, let me get this straight - you're basing the perceived merits or lack thereof of an OS on the work of a single 3rd party application by a single company?

    And this company is, of all people, Netscape?



    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])

  • 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.

  • A lot of people, including me, have notebooks as their primary computing platform. I run Linux on an IBM ThinkPad 770Z and it works great as a development platform for my server-based applications.

    So I agree with the original complainers - it would be a bummer for the OS not to work on PowerBooks.

    D

    ----
  • There is no 8 or 32 bit virtual machine. I don't know where you get your info. DOS has *never* been 8 bit. Its main selling point when it was released was that it was 16 bit and CP/M was not.
  • Hrm, okay. Just checking.



    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])

Slashdot Top Deals

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry

Close