Slashdot Mirror
The Challenges Of Integrating Unix And Mac OS
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.
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.
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.)
"Tax preparation software eliminates errors your[SIC] may make...." From IRS home page.
maybe they should talk to Hemos?
___
Apple might consider spending a little effort on keeping some of its biggest supporters -- developers -- happy.
I use Macs for work, Linux for education, and Windows for cardplaying.
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.
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
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:
...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
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.
Keeping
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 more I learn about the Internet, the more amazed I am that it works at all.
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?
www.eFax.com are spammers
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
Since the core of the OS X is unix. Does this mean that quicktime will be ported to other *nix systems?(i.e. linux)
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
ya know... there's an interesting discussion over at cad-fu 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
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
-- Could you use my software consulting serv
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 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.
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.
/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.
Let's do a test. On a unix system, do rm -rf
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.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is the magic number.
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?
--
Sheesh, evil *and* a jerk. -- Jade
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.
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? :)
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
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.
/usr/lib/desktop, no doubt.
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.
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.
--
This space unintentionally left unblank.
mod this one up!!!
I think the quote you give was taken out of context a little. The guy was really referring to the fact that the Mac OS, while not the first GUI, was really the first to really drill home the need to focus on the needs of a consumer. It said that the main alternative in the 80s was just the ol' DOS for windows and in that context, the OS was quite a revolutionary - it paved the way for other GUIs into the consumer market.
As far as stability goes.. I think the Mac OS has really felt the impact of Apple's flirt with liquidation in the mid-90s. I do remember being promised pre-emptively multitasking and protected memory a bit before Windows 95 came out.... after that bungle after bungle... the whole thing seemed to just get pushed back and back... and it never really came. Mac OS isn't great by any stretch of the imagination but it certainly WAS revolutionary for its tiome
Changes under the hood in OS X is long overdue but IMHO Apple have usually (with QT Player being a notable exception) hit the mark with vibrant, clean, intuitive and innovative GUI. Which, I feel is pretty much the only claim that's being made in teh 1st para
d00d! u r c00l!
--- only for the squeamish
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.
:-)
Layering is Microsoft and Apple's favorite style of doing things. Try modal dialogs for example. An app crashes. Forget getting back focus.
As for Unix.. All processes run along side the others. I can run KDE apps in Gnome and vice versa w/ no problem.
The message on the other side of this sig is false.
Okay, I've just come back from the neighborhood bar, so bear with this rambling comment:
I saw my first computer in 1964, an IBM 360 installation at my father's company. Big iron, keypunch, card readers and sorters, blinkenlights, playing NIM...
In 1984, I built a recording studio, a Mac 512k running Sound Designer and an Ensoniq Mirage were my "poor man's Fairlight". I had a MIDI network before I ever heard of Ethernet or Appletalk or even the word "network".
In 1989, I started doing 2D and 3D animations on the Amiga, using Turbo Silver, Imagine, Deluxe Paint, and later Lightwave.
In 1993, I worked at a consultancy and learned about the corporate computing environment: PCs connected to Novell servers, X-terms connected to RS/6000s running AIX.
After that, I learned 3DStudio for DOS (still use it), Photoshop, Quark, Illustrator, etc. I started learning Perl, Lisp, Lingo (Director). Hung out a shingle and developed web sites until Microsoft made it no fun anymore. Right now I create virtual environments for a Japanese company. I'm building an idoru, IYKWIM, AIKTYD.
My point is: when I've had a few drinks in me I can say "It's all good". My computers, Mac, Windows, Linux, and IRIX, don't get in the way of what I have to do for a living too much, and that's all that really counts.
When I'm sober, I have to agree with the truism: "All operating systems suck. Some just suck less than others".
There are times I wish Adobe would release an operating system. Something like BeOS with Display Postscript. A media development operating system, with the Mac's variable screen resolution (and multiple monitor handling) and the best parts of DirectX, OpenGL, ATM, and Quicktime. Hello, Adobe?
(k., posting anonymously because I'm snookered)
--
I WUV U ALL IN CAPS! -- K.
Come On...
The article mixes apple's marketspeak with technical features. It uses "first personal computer" (tm) as a statement of oppinion of marketing claims, as opposed to the first IBM PC (aka personal computer) which was in actuality the real first personal computer.
Secondly, the Mac debuted only a couple of months before the Amiga. (Amiga was a separate company) It DID have multi-tasking (but it was non-prioritized). It did NOT have protected memory (The 68000 didn't support a MMU.. only the 68030 actually did. So there was no real way to detect page faulting)
The fact is that this paper is written by soneone who was probably 5 years old when the first Mac was released. He's probably never seen an original Mac.
The MacOS (as most people know it) began as a small loader (and various user/system programs. The REAL OS always lived in the ROM chip(s) inside the system. (Probably the real reason Macs were always slow, because the ROMs ran at half the speed of the system bus) The real OS has windowing and widgets mixed in with the i/o system. And the original MacOS was written in...
um
pascal and some assembly required.
Yep.. that's right. So MacOS has come a long way baby. And I am really happy that they are decidedly going towards MacOS X.
But they have real hurdles to jump over. In order to not alienate their developer base, they have to present Carbon as being a step up from the old API.
And Mac developers are a bunch of whiners when it comes to change.. JUST LIKE US *nix guys.. so have some sympathy. There's alot of work before MacOS X is going to work for your grandmother AND live on the *nix guys desk also.
Panaflex
I said no... but I missed and it came out yes.
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.
/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.
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.
>that on the Mac
Pure FUD. Plain and simple...
Are you lieing on behalf of your master up in redmond? Or have you just never used a Mac, but because your master tells you "all else but windows is bad" you feel qualified to comment despite your ignorance?
>You mean your 7 year old daughter can
>just go in there and waste the whole
>system without knowing it???
If you have your Mac set so that she can... yes. But then, if someone like you used Linux you'd probably just log in as root and have no password set anyway.
HINT for real users who want to control access to their Mac...
There's a little control panel called "Multiple Users"...
HINT for astroturfing trolls like schnedt...
Your lies can fool all of the people some of the time. Your lies can fool some of the people all of the time. But your lies cant fool all of the people all of the time.
john
Resistance is NOT futile!!!
Haiku:
I am not a drone.
Remove the collective if
Imagine all the people...
Please read the posted story and then this entire thread (except Mr TRoLL) and ask yourself: does the parent deserve +4 insightful or -1 flaimbait?
If you have any sense you will pick the latter... Cheers to those who do.
If nobody mods this down I think the Slashdot moderation system has completely broken down and it may not be worth reading computer related threads anymore, I'll just stick to the Katz articles for stories with knowlegeable moderators.
=8<0> (aaaaaahhhhhhhhhhhhhhhhhh!)
no sig.
This sounds like the definition on an inode number which is one of the central design features of Unix-like filesystems. This kind of feature needs to be emulated for things like the stat() system call and NFS for filesystems that don't support them. These are the unique IDs for files in a filesystem under UFS.
The nice thing about file IDs is that once the ID for a file is obtained, the file can be renamed or moved anywhere on disk and still be found and opened by the holder of the ID, and file access by ID is faster than access by path, as it avoids the path lookups.
One thing, though, you are NOT allowed to open a file based on inode number because it effectively allows you to bypass directory permissions. To fix that would make it as slow as directory access.
I guess HFS+ doesn't care about directory permissions too much.
Mac OS aliases are similar to symbolic links, with the addition of alternative means of finding the file. Because aliases include the target file's ID, moving the target file does not break the alias as it would a symbolic link.
They work that way because that is how they are _defined_ to work. If you want to be able to move or delete the destination you must use a hard link. Strangely, the author explain how HFS+ didn't have hard links and how it was very difficult to emulate them using symbolic links... but aliases sound very similar to them.
Also, I don't know if aliases can point to relative paths. This is the major problem with "shortcuts" under MS-Windows... they contain the full path including the drive letter.
If they don't get details like this it makes me wonder about the quality of the OS. Of course it might a bad writeup and the code could be OK.
On NT you get your focus back.Don't know about Apple.
And what being able to run KDE apps in Gnome has to do with anything.
One can easily run Photoshop along with Word and vice versa with no problem either.
gratuitous talking heads reference?
---- I made the Kessel Run in under 11 parsecs.
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.
I'm a loner Dottie, a Rebel.
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.
I'm a loner Dottie, a Rebel.
He seems to be pretty confused about computing history, and Apples place in it (although, from what I've heard, this view is probably beaten into Apple employees from day one.)
"When the Macintosh was introduced, it was to be the first personal computer."
Umm, I guess he's never heard of the Vic20? or C64? These predate the Mac by a couple of years, at least.
Well, despite his qualification ("the first truly personal computer" - presumably in terms of user friendliness), he seems to be thinking of the Apple II. It was the first mass-marketed non-hobbyist computer, introduced in 1977.
The VIC-20 came out in 1981, and the Commodore 64 in 1982. They were cheap and relatively powerful, but certainly not as easy to use as a Mac (and given the state of the hardware then, no one would reasonably expect them to be).
But it gets better:
It later became clear that running a few programs side-by-side could be very useful, but this wasn't really true until personal computers had gained enough power and memory for this to be feasible.
Umm, no. Ever hear of the Amiga? The A1000 started with 256K of RAM, and could multitask quite well, thankyouverymuch...
just because Apple couldn't write an OS that could multitask with a quarter meg of RAM and a 68000, don't assume nobody else could...
Oh, be fair. 256K was twice as much as the original Mac had, and Commodore introduced it a year and a half after the Mac debuted. Part of the reason the Amiga could multitask so well was because it had custom chips to support the 68000 CPU. The Mac by comparison had to do all its graphics on the main CPU, so not much power was left over for process management.
Don't get me wrong, the Amiga is a hell of a piece of engineering and I love it, although I never owned one. Remember, too, that Amiga development was tight and focused, but Macintosh was kind of an "underground" project at Apple and almost got axed. It was only after it made a splash that Apple management really got behind its development.
Anyway, this is just intended as a little defense of the Mac development team. They created a very complex and refined OS, and charted some very new territory beyond what they inherited from Lisa and Xerox. Give them some credit, because they absolutely were the inspiration for what came later out of Apple and its competitors.
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
The Alto predated the Apple I by several years. It was the first personal computer. It just cost a fortune and was never particularly available outside of Xerox. The Apple I was a hobbyist's machine, really. It was just a logic board. The first 'real' personal computer from Apple was the Apple II. Which was designed during 76 and 77 and began being sold in 77.
And the IBM PC hit the market in 80 or 81 IIRC, and had been started (as Project Chess) in probably 79.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
(The 68000 didn't support a MMU.. only the 68030 actually did. So there was no real way to detect page faulting)
:)
I'm in the nitpicking department at the moment.
It is true that the '030 was the first 680x0 that had an MMU on-chip.
The 68020 supported an external MMU chip. It was also possible to add an MMU to the 68010, but that required additional hardware trickery on the motherboard.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
It's a Mac FS, not a Unix FS. Support for it is really only to transition old MacOS users. If you use HFS+ as your primary FS and have those kinds of problems, don't expect much sympathy.
Anything graphical is written using Apple's proprietary APIs.
You couldn't be more wrong. The MacOS X GUI classes are contained in the AppKit, which is part of the OpenStep standard. For (rough) implementations of this for Linux and other OSes, see the GNUstep site.
Of course, that has nothing to do with QuickTime, since it is using the Carbon API instead of the Cocoa API.
Besides, you do not even have to let people download your GPL software. You are only required to distibute source with binaries, even on CD. And IIRC you can charge for the source seperately from the product. However, it is generally not done because whoever gets your software has the right to distribute under their own terms.
Redhat et al sell more than support. They also sell pretty manuals, hats, etc. In other words, they sell value rather than just holding the user hostage because their computer needs an OS or whatever. The largest cost in the production of software is the box it comes in, and any printed materials. Most closed-source software makes you pay ridiculous prices for the box and / or licenses, whereas the product itself may be of little or no use to you at all.
Is it just me, or is OSX starting to look ridiculously complex? They're doing stuff the Microsoft way. Instead of a well thought out integration of 2 seperate and distinct Operating Systems, they put a layer on top of the two so they can talk together.
I was never much impressed with the old MacOS.
I think the new Aqua interface is, frankly, tits on a bull. I mean, besides looking pretty, what does it *do*?
When MacOSX Server came along, the MacOS people bitched because they didn't think BlueBox.app was enough. And they were probably right, and Carbon got invented.
So now those of us from the OPENSTEP community who just want Apple to keep shipping some of the existing code are being invited to take it up the ass? The WebObjects stuff is at present unspeakably cool -- and Apple plan to make it pure-Java, which makes it substantially less cool. This also means they're going to trash some of the other supporting code -- EOF in particular. I like the existing EOF, implemented in ObjectiveC, because when I find bugs, I report them and then in many cases I can patch them in the existing software using "categories" or subclassing or "posing"; my ability to do that with Java is reduced by about two orders of magnitude.
Apple seem to be doing their damnedest to make sure no-one can ship anything that isn't either pure-Java or a Carbonized existing MacOS app. Follow the link to Stepwise; Apple have even crippled the Installer application for God's sake!
Have you heard of the 'file' command? It isn't perfect, but it works most of the time.
This is a new OS. New OSes require migration. They are migrating FROM two OSes. Thus, they must make migration possible from both lest they leave users without an upgrade path.
This is a nontrivial task, but they are making it as easy as possible. Complexity is bad when it means that system behavior is complex. However, complex code written to make system behavior as simple as possible is GOOD.
See what I mean?
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
Apple should of went with BeOS.
I do give them credit for trying but it's still too bad.
You mean like Project Appleseed? By jove, I'd love one!
The Happy Blues Man
The Happy Blues Man
I accept on blind faith that Cincinatti exists.
well, you could make an account and set it to -1,nested, and set the comment length to an absurdly high number.
You might want to check out Junkbuster if you use netscape/x11. I hear Adfilter and Norton Internet Security block banner ads on the Wintendo platform, although they are only free if you pirate them.
Lars -
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?!
Without a GUI. Big difference.
Do you click on Fawking DSL advertisements?
Cool anti-aliased fonts and an advanced metadata/bundling/call-it-what-you-will system where icons, start-up scripts and libraries
all form part of the application package which
can be deployed just by copying a directory from
A to B.
Welcome to the world of RISC OS, circa 1989.
It wasn't the metadata concept itself that made viruses so easy to write on the Macintosh, it was the search path for the resources. When looking for resources (for example a WDEF window definition, essentially a code snippet that describes how to draw a style of window) unless care is taken, an application first looks through the resource fork of the open document, then the current application, then finally the system file. This meant that a document or application could override the systems window drawing code, replacing it with its own. All the documents had to do is to copy itself into other documents and instant virus.
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Okay, I'll conceed you are right.. TECHNICALLY they could have used an MMU.
Howevere, most companies rolled their own MMU (Research Sun's PMMU, National, etc..)
The 68451 wasn't even configured for paging... to do it you needed multiple 68451's.
The first real usable MMU from moto was the 68851 and it wasn't cheap. Considering that the first mac came out for what.. 1,500 bucks (At a time when a car was 5 - 10k). A higher price would have possibly bust the platform. (Look at the LISA for a reference on that)
In other words, you couldn't use it UNLESS you were apollo or sun... because it was expensive. Besides, the MMU's moto designed ate up alot of bus time... not very good for an already slow system.
Also, moto wasn't getting good yield on these 68451 MMU's until mid 85.. a whole year after the MacOS and the AmigaOS were released. To change to an MMU in the kernel would have requred a big rewrite, and it didn't fit into the plane of having a cheap adaptable OS.
In other words, no PC ever manufactured included the 68451 or the 68851.. so it's kinda moot anyhow. Lots of people had 68k MMU's.. but they wern't viable for consumer products. (Remember, the CPU costs a whold lot of the product at the time)
(unrelated to MMU) As far as to whether the Apple II was a personal computer.. well they didn't call it that. They called it a HOME computer.
Pan
I said no... but I missed and it came out yes.
will this be frankOStain?
Ars Technica has a new Q&A with some more info on how files are handled in DP4, as well as about other aspects of X that people have been asking about.
--
Jake
>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 solution, of course,is not to write such puerile poetry, thereby not creating the file in the first place
hawk, apparently a borderline troll today