But I am curious. What about the file system? Do Macs still have separate resource and data forks with each file?
Yes.
Will this be supported by the file system in OS X?
The OS X filesystem is HFS+, the same filesystem used by Mac OS 8.1 through 9.0.
What about the app and creator 4-byte codes (which are actually in the resource fork). Will that be used, or will they move to the horrible filename extension crap that UNIX and DOS world suffers under?:-(
Those are also supported, although filename extensions are also checked as a fallback and to support operaton on metadata-less filesystems, such as UFS (which is fully supported by Mac OS X) or most NFS installations.
So what's Apple's problem with having a GPL'ed package management system? I know many companies have an aversion to the GPL, but how does having a free and open package management system hurt them? The GPL wouldn't infect the packages. This isn't a flame - I really don't see where what the catch is from Apple's point of view.
Apple employees have discussed this issue several times on the Darwin-Development mailing list. Here's the latest, which was in regards to the GPL licensing of dpkg and why Apple couldn't use it for their installer.
Peter Bierman wrote:
The GPL doesn't prevent Apple from calling the command-line installer either, so the amount of work involved if you use the current tools shouldn't be much. You wouldn't be linking to the GPLed software, merely using it.
At the risk of starting another GPL flamefest, the GPL *does* prevent Apple from calling the dpkg tools from the installer.
Please don't offer to "educate" us about the GPL. We have to listen to our lawyers, and we've done a LOT to understand this issue. It is not as simple as everyone thinks.
The short version is that the "derivative works" clause of the GPL is not defined well enough to risk the assets of a corporation on. Getting an email from RMS saying otherwise does not fix anything. If you think this sucks, get RMS to __change the GPL__. (Not bloody likely.)
Why might it be a derivative work? Dependency. If the installer, or worse, the whole OS, is useless without a GPL utility, then it *might* be a derivative work. "Might" is enough doubt to deep six it.
Linking is just not very easy to define. If I link a library, I allocate address space for code, and call functions, passing arguments, for results. If I call a command line tool, I effectively am doing the exact same thing, with slightly different semantics. Shell can be thought of as a language, just like C.
Again, please don't bother arguing this point on this mailing list. I'm not trying to be obtuse, it's just that I have to defer to the lawyers, and they're responsible for protecting the assets of the company. If you disagree with my explanation, feel free to write your own Operating System that follows your differing understanding of these issues. Otherwise, please just accept that this is the framework that Mac OS X will have to live in. It's not the end of the world, just an inconvenience.
Later in the thread, Wilfredo Sanchez also followed up:
No GPL whatsoever in the kernel. That includes loadable code. Since they link into the kernel, they possibly taint the kernel. Now, that's Apple's rule.
You might be able to do so, though you might in theory be violating the GPL; but then you aren't in a position to relicense our code, and don't have assets at stake. But we won't be able to include such work in Darwin.
Basically, "gray area" translates to "no".
If you think we're paranoid, I actually asked RMS whether replacing/bin/sh (required by the OS) with bash would taint the whole system. His response, somewhat to my surprise, was yes, it does. Now I think that many GPL advocates and programmers who use the GPL do no see it that way, but there you go.
Does this mean that Apple is considering jumping ship for x86? They certainly would have a good reason since Motorola has been way to slow to release 550-700mhz PPCs. You can't explain to clueless newbies that a 500mhz PPC is a lot faster than a 500mhz Athlon or P3 so maybe Apple is contemplating this kind of move.
This isn't the case. At any rate, this is not a spur-of-the-moment decision to build the OS for x86. The maintainance of the cross-platform portions of the core OS are more common sense than anything; Apple started out with a cross-platform OS and is sparing enough care to keep it that way.
BTW didn't Stallman say that the Darwin license doesn't qualify as a free software license?
The APSL is incontestably not a copyleft ("free software") license. It has been approved as an Open Source license, however.
Apple only licenses under the APSL code which is theirs. For example, their GCC code is, of course, licensed under the GPL, and they're working in good faith on narrowing the gap between Apple GCC and GNU GCC by bringing Apple's most well-conceived changes up in mainstream GCC and reassigning copyright to the FSF.
Converting the software, especially an operating system, for different byte orientation, would be a major piece of work.
This is a far from insurmountable problem. And, honestly, it isn't as much a problem as you seem to imagine. I would typefy it as a problem solved, and it is not an impediment to brining Darwin up on Intel hardware. Keep in mind that Darwin is the core OS from OpenStep/Mach, which ran on x86, PA-RISC, and SPARC hardware before it was ported to PowerPC when Apple acquired NeXT.
I'm terribly sorry to say (I love apple, and I would love to see OS X running on my Intel box) but this is just another case of a bored engineer blowing off a little steam.
I think you've seriously misclassified Wilfredo Sanchez. His job is managing Darwin and Apple's other recent public source projects. He (and now David Zarzycki) are the conduits through which Apple and the open source community communicate. He's quite dedicated, and this is a big step; cross-compiling an entire operating system is far from simply "a [single] bored engineer blowing off steam." This build required that Apple's core OS development team be fairly rigorous in writing and maintaining cross-platform code. (Admittedly, Darwin is itself a port of OpenStep/Mach's core OS to PowerPC from a codebase that ran on x86, SPARC, and PA-RISC, but many, many, many changes have been made.) Not only that, but the build infrastructure is now such that Apple's public and private CVS servers are largely unified for the core OS; we're getting a live view of of Mac OS X's core OS' development.
Meanwhile, the modified GCC which Apple inherited from NeXT has an engineer dedicated to merging the codebase into the mainstream GNU GCC, copyright reassignment and all. There is even serious discussion of bringing together the GNU and Apple Objective C runtimes.
As I've said in other posts, I don't specifically do not believe Mac OS X will be running on Intel at any point in the forseeable future, but it is my opinion that you've sorely misjudged the rest of the situation.
Although it is a step in the right direction, I honestly wonder how far they will go with it after the darwin effort is completed. I don't believe that we will see full blown MAC OS chugging along on Intel for the long haul.
Keep in mind that the stories Slashdot posts are quite reactionary. "Apple UNIX cross-compiles to Intel!" You expected this not to show up on Slashdot?
Given that, I believe that we'll see Darwin liven up significantly as OS X becomes available, but I do not expect it to make any strong inroads towards replacing FreeBSD or Linux on x86 systems. I fully agree in that we will not be seeing Mac OS X running on Intel in the near future. One of Apple's most valuable assets is controlling the whole box from the operating system down; it allows them to sell well-integrated systems which, as they ship from the factory, rely upon relatively small range of devices whose coresponding software can be well-tested.
If you look on the Apple site [...] you will see the option to have two processors on the server-class machines.
This is not the case. Apple does not currently sell any dual-processor machines, and has not since the days of the PPC 604e-based Power Macintosh 9x00, which ended in late 1997 or so.
The rationale for this is that the current Mac OS takes ill advantage of multiprocessors. It uses assymmetric multiprocessing, and the second processor sits idle for the vast majority of time. (Furthermore, the G3's 3-state cache coherency model is insufficient to support more than dual-processor configurations, although the G4's 5-state model is enough to support it very well.) Mac OS X will fully support symmetric multiprocessing, so expect this picture to change in the next year or so.
Sorry, I'm maybe not following this to closely, but I wonder if It is goning to be GPL'ed[...]
For their own code, Apple is using their own license, which they call the Apple Public Source License, or APSL for short. It is not a copyleft license, but has been approved as an Open Source license. GPL'd software that they enhance--GCC, for a very notable instance--is, of course, submitted back to the FSF, and folks at Apple are working on reassigning copyright for such software to the FSF. Not, however, the entire operating system, which is APSL. They're playing nice, but probably not nice enough to satisfy many of the ranks Stallman has inexplicably managed to brainwash.
Personally, I think this is a good course of action; I dislike the GPL, and think it especially ill-suited as a license for the basis of a commercial operating system.
[a]nd if it is going to run Linux binarys like FreeBSD etc.
Darwin runs Mach-O (Mach object format) binaries. It is a BSD variant built atop a Mach 3.0 microkernel. I don't expect to see a Linux binary compatability environment spring up, but you never know.
He says that he builds all binaries fat . This means that all programms can run on both x86/PPC simultaniously . Maybe Apple will really use x86 in the future ?
Fat binaries are pretty cool, but he's referring only to Darwin, which is a pretty vanilla BSD variant, though with some interesting capabilities. It is very unlikely that Apple will be compiling and optimizing Cocoa, Quartz, QuickTime, Carbon, and all the other high-level libraries for x86 given they're not actually selling a product for that platform.
The fat binary capabilities could certainly ease future architecture transition, however.
I took it for granted that Mac OS X would be utilizing Altivec's special capabilities to make some significant speed boosts. When recompiling for x86 compatible machines, wouldn't those speed boosts be lost? And therefore wouldn't the version that runs on Apple hardware be significantly faster?
Most of what goes on in the core OS isn't going to be significantly advanced by vector processing, though certainly tasks such as copying memory will receive a boost simply due to the increased bandwidth. And remember that Intel and AMD has SIMD, as well, though it's certainly not as high-quality as AltiVec. So, yes, there will be something of a performance drop, but I would wager that it won't be huge.
Quartz (OS X's brand new imaging subsystem) would probably suffer a more noticable performance drop, given the extensive use of transparency.
My personal pet peeve is that the menu bar is permanently docked at the top of the screen and doesn't stay attached to the application that owns it.
There are advantages to that method: For one, you don't waste screen real estate duplicating the menu bar in every window. For another, it means you always know where to find the menu, no matter where a window is. I'm not saying one is better then the other, just that Apple's method is not without merit.
Actually, it is a lot like that; the Mac's menu bar is a demonstrably superior interface. In fact, if one is to actually time users, a Windows-like menu bar is a factor of five slower to use.
This superiority is a result of Fitt's Law, which states that the time it takes to point at a target with a pointing device is a function of the target's size and distance to that target. The larger the target and the nearer it is, the less time it will take to point to it. This is, of course, trivially obvious when phrased that way, but its implications are ignored far too often by software developers.
The Mac's menu bar uses a very special piece of screen real estate, exploiting Fitt's law. Because the menu bar rests all along the edge of the screen, it has an effectively infinite size; you can keep rolling the mouse upward as much as you like, but that cursor is always going to be in the menu bar. Because of this, it's faster to point at a menu title, and the entire process of using the menu is accelerated.
Of course, the most efficient place to put the mouse is right where it is, so that's an even better place for the menu bar: Under the mouse all the time. The problem is that we don't have a good user interface for that; hierarchical menus are inefficient to use (timewise) and cumbersome. NeXT actually did this, though: A right-click brought up the entire menu bar beneath the mouse, arranged hierarchically. This was in 1989, and most likely begat Windows 95's context-sensitive menus, which are a refinement in that they avoid necessitating the task of navigating cumbersome, deeply hierarchical menu structures to access the most useful commands.
But, all that aside, the Mac's menu bar, after nearly 16 years is empirically the best interface we have for presenting an entire menu hierarchy. Most likely just dumb luck, though; I doubt the designers of the original Macintosh considered these implications in the world of 1983's nine-inch, 512-by-384 monochrome displays while Steve Jobs was breathing down their necks with the refrain, "Real artists ship!"
You can read more about interface design and Fitt's Law at http://www.asktog.com/. It's an interesting, if oft-neglegted, subject.
Ambrosia's still around and still making games as well as utilities. http://www.AmbrosiaSW.com/ has the full scoop. Their games still aren't really up-to-snuff with commercial games, though, if you want my opinion. It would help if Andrew Welch spent less time being a freak and more time coding! (Are you listening, Andrew, you psycho?;)
On PowerPC Macs, having virtual memory on forces applications to leave their resource forks on disk rather than loading them into RAM.
This is incorrect.
The reason that Mac OS applications (appear to) consume less memory with virtual memory on is that enabling virtual memory allows the OS to swap out the application's code with file-mapping. With VM off, the code data must always remain resident because the MMU is inactive and thus cannot deal with page faults (accesses to inactive memory). Thus, while you have precisely the same amount of data with VM off instead of on, more of it can be paged out to disk, reducing real memory concumption (somewhat).
It's worth noting that, while with VM on, applications do use less memory, it's not as much less as the Get Info window's memory panel advertises or the About This Computer window reports. This is because some of the code has to be resident for the programs to run. However, none of the memory pages mapped to code are part of the application's heap and thus precisely zero of them are reported in heap-based memory usage statistics (such as the Finder's About This Computer window).
If you have enough RAM, though, there's no reason to run your Mac with VM on; the Mac OS has fairly static memory requirements and generally deals with memory exhaustion more reliably than UNIX applications (where not checking for null pointers is quite common). Turning it off removes one more slight performance hit.
Addressing the resource fork memory usage issue, purgable resources (and handles in general) are always purged if memory constraints are encountered. This mechanism is made possible by the wonderfully screwed up world of handle-based memory allocation.
Handle h; /*... */ if (!h) { throwSomeNullHandleException(); } HLock(h); if (MemError() != noErr) { throwSomeMemoryError(MemError()); } if (h && !*h) { reallocate(h); } if (!h || !*h) { HUnlock(h); throwSomeMemoryFullException(); } /* Now you can actually use the fucking thing safely! */ HUnlock(h); if (MemError() != noErr) { throwSomeMemoryError(MemError()); }
Just be glad you don't have to make the above code pre-emptable and/or re-entrant.
Apple is using EGCS/GCC 2.95 as its compiler for Mac OS X [client] (not OS X Server; that uses gcc "2.7.2.1" for now).
They've submitted a large quantity of code (mostly from the work done at NeXT) to the GCC maintainers, and work proceeds to integrate the two source bases.
Furthermore, Apple would be nothing short of braindead to release OS X [client] for G4 systems without using an AltiVec-aware vectorizing compiler to generate their code. Since GCC Is the compiler that they're using, it seems more than likely that they will expend considerable resources to making GCC's PowerPC codegen as good as possible. (And LinuxPPC will see the benefits, too. Very cool.) Perhaps they can even integrate some of their work from MrC/MrCpp, Apple's fantastically good optimizing PowerPC C and C++ compilers for MPW.
Apple is riding the wave of the longest economic expansion in American history. People can afford to buy Apples again. Take a look at your own price points for the new G4 systems. The first, at 400 MHz, starts at $1,599. Go up to 450MHz, and the price jumps to $2,499. Go up to 500MHz, and the price jumps again to $3,499. The trend is obvious. Going up 50 MHz in the G4 line costs about $1,000 for the privilege. Are you (and Apple) trying to tell me that going from 400 to 500 MHz is worth an extra $2,000? I don't think so. If the economy every turns sour, then Apple will be the first to feel it, and they'll feel it hardest.
It's worth noting that more than simply the clock speed changes in each of the standard configurations you've mentioned.
The 400MHz model has 64MB of RAM, a 10GB UltraATA/33 HD, and a CD-ROM drive.
The 450MHz model has 128MB of RAM, a 17GB UltraATA/66 HD, and a DVD-ROM drive.
The 500MHz model has 256MB of RAM, a 27GB UltraATA/66 HD, and a DVD-RAM drive.
Not that this totally excuses the price increases, but it's not as draconian as you paint it.
(There are also other changes between the motherboard used in the 400MHz G4 vs. the one used in the 450 and 500MHz models, but I haven't mentioned them.)
Like most BSDs, Mac OS X Server and Darwin use UFS. Apple has included an HFS[+] filesystem implementation, but you must boot from UFS. It's expected that Apple will make Mac OS X [client] bootable from HFS+. (Classic HFS will never work, though; doesn't know how to store UNIX permissions like HFS+ does.)
1) The APSL states that Apple may, at any time, revoke your license to use the software. So, if you are developer and have put hundreds of hours into making adjustments so that it fits your needs, you are suddenly without recourse, and your million dollar project is now DOA.
It states that, if Apple is faced with a patent violate lawsuit, they can revoke your license to only the affected portion of code, and they also give themselves the option to either write around the violation or obtain a license for the patent. They cannot revoke your license to the entire product under this clause. If they did not include this provision, they would be exposed to additional liability for providing that protected technology to the public. I think you'll find a similar provision in nearly all open source-ish licenses that corporations with actual legal departments might issue.
The complete termination clause states that (i) your license terminates if you violate the license and do not correct the situation 30 days after a you become aware of your own violation, (ii a) your license to only the affected code might terminate (as describe above) if an intellectual property claim is filed, (ii b) your license terminates if the law prohibits you from complying with the core sections of the license, or (c) your license terminates you file an intellectual property claim against Apple. None of these provisions except (c) are in any way unrealistic.
2) All changes that you make must be submitted to Apple.
You have to publish your changes under any other open-source license, as well. Apple requests that you notify them by using a simple form that they provide. Woe is me. You are free to fork the tree, you are simply asked to tell Apple about it.
3) and if Apple revokes your rights to the license, they get keep and use your modifications without compensating you.
I agree with your dissent on the core issue here, in that Apple's license grants inequal rights to Apple and to the licensees. However, I can also see the justification; Apple does utilize this same codebase for a commercial product that, while it includes this codebase, also includes additional code which is not covered by the APSL or any other public source license. (This is reasonable; expecting the entirety of Mac OS X Server to be available as a free download is currently unrealistic, given Apple's business model. Perhaps in time that will change, but it will be a very long time.)
Stallman makes good points, articulating them much more clearly than either RMS or Bruce managed to. He did such a good job at articulation and logic that I almost found myself agreeing with him by the time I was finished reading his thoughts.
Then I woke up.
Stallman, as always, places idealism before practicality and goes to far as to ignore the latter. Whether or not that's good is up to the individual. Idealism doesn't always work, communism being the classic example. Stallman's ideal is a far stone's throw from communism; his does actually work in the right circumstances. However, I think the point Stallman fails to recognize (or dismisses) is that Apple is a corporate entity that has a responsibility other than living up to Richard's ideals. It has a responsibility to its employees to make money so that it can comphensate them for their efforts; this is a virtuous goal. One of the most significant ways in which it currently accomplishes this is by selling software. Apple can't discard that business at the drop of a hat. Ultimately, it has to make money somehow. As such, I don't believe that we will see a license that agrees with Stallman's "copyleft" ideal from Apple in the near future. Indeed, doubt that you'll find in the near future one from any company that makes its money by selling its developer's time, as these companies have an obligation to their investors and to their employees to make money. This is why Apple retains rights under the APSL.
Another point that Stallman entirely neglects to mention is that Apple cannot currently release its entire codebase for OS X Server under an Open Source, Free, or Copyleft license currently. Most notably, it doesn't own Display PostScript, upon which the Yellow Box APIs (the interesting bits of OS X Server) are predicated. It is reported that. Other technologies that it has licensed are surely more common than I could recount, but, very significantly, all modern QuickTime codecs and all of the ColorSync color management modules are licensed code. In short, the Yellow Box doesn't work (currently) if you remove the licesnsed technologies.
Of the first three criticsms, as to why the APSL is not a Free software license, I agree with Stallman except on the third item, which is that the APSL can terminate at any time. The GPL provides a similar termination clause. The APSL shifts responsibility for patent infringement, however, from the individual to a particular Apple Computer, Inc. Whether or not this is agreeable is another individual decision, but the reasoning is sound--Apple cannot be sued for releasing code that infringes upon patents. Now, if it falls under a suit, it has a method to clear itself of infringement that does not involve broach of contract (that contract being the APSL, if it were not to include a similar termination clause). I believe it's clear from the license that Apple would make a good faith effort to clear the infringement, and it's also worth noting that only the code directly in infringement is affected.
The reason that this clause really becomes necessary, though, is that this software was not born and bred GPL. It's been extensively modified for more than a decade by both NeXT and Apple. If there is an intellectual propery violation in the code, the responsibility for that violation is not with the entire community (which is where the GPL places it), but instead with the entity which developed the original code that was released to the public, Apple; the company must protect itself from liability by allowing itself to back out of patent infringements gracefully.
In short, Stallman's idealism is incompatable with the corporate interests of Apple as well as the nature of the development of the code that is being released. This is why the GPL and the APSL are incompatable; they were written by seperate groups which have seperate goals.
Perens didn't notice another violation in APSL...
on
OSI APSL Response
·
· Score: 1
You're full of it.:) After the quoted section 2.1 of the APSL, you will find section 2.2, which describes what you must do if you are to deploy the code. Section 2.1 grants you rights to tinker with the code, but not find a web space, notify Apple, and put out your modifications so long as you do not deploy it. Deploy is defined near the top of the license, and includes internal use for purposes other than R&D as well as distrubution.
It'll be interesting to see how this turns out in the long run, but I'm quite pleased for now, as:
Apple's made a clean, well-architected operating system, Darwin, available to us for no cost and placed it under an open-source license, although not a free software license.
In a reasonable model to derive software revenue, Apple supplies server software (including WebObjects, Mac-centric file sharing, and NetBoot), an advanced set of APIs and development tools, and a state-of-the-art GUI to run on top of Darwin.
The DriverKit--an object-oriented driver model--is listed on Apple's Public Source Projects page. This is something that could potentially benefit the entire OSS UNIX community greatly.
Apple is considering placing more software under its OSS license. Obviously, Darwin is a test of the waters. If the results are poor, then the project will die out slowly, and we'll only be yet another UNIX clone poorer. If it is a success, though, Apple will place more and more code under the APSL.
This seems very reasonable to my eyes, and I can't see how it's anything other than either a positive--or perhaps irrelevant for some--development for the industry. It's certainly not a negative turn of events, though.
But, still, I've got a few comments in response to the various recurrant threads.
Termination and Liability First of all, regarding the license's termination clauses in case of an intellectual property lawsuit, I do think that you all have to think for a moment about the forces at work. Apple's a large corporation; they have to protect their employees and stockholders. I think that it's clear enough from the license that they would make a good faith effort to work around the dispute if possible. All licenses issued from large companies will most likely harbor similar clauses to protect the company from liability.
Liability from Termination In that same vein, I believe that it's not especially reasonable to expect Apple to use that clause to terminate your licenses on a whim. The APSL protects Apple's interests, certainly, but it doesn't make it easy for Apple to back out, either. If Apple were to bribe a company to sue for intellectual property violations, it would certainly create a scandal and perhaps even a class action lawsuit. (I am not a lawyer, however.) In my eyes, it would be more likely that, if Apple wished Darwin to go away, it would simply let the project languish instead of risking condemning press and exposing itself to even more liability. The company is under no contractual obligation to synchronize the Mac OS X and Darwin projects, so letting the project die out is not a difficult path to take.
OSS vs. Free (Again) Thirdly, those of you arguing against Open Source and for Free Software should perhaps take a dose of pragmatism. Apple is has just taken a very large step closer to your ideal; that they have not acheived it yet is an invalid justification for criticsm in the face of the fact that they are working toward that end. Given, they are moving cautiously, but that is as any entity of this company's scale should. Multibillion-dollar corporations do not turn on a dime.
Issues of Trust Finally, the arguments against trusting the company certainly have their justifications, and I won't pretend to contest them. Apple has a long history of turbulent management. From the Apple II, to clones and PPCP, to OpenDoc and the Newton, there are many instances of about-faces that were damaging to third parties. Looking at more recent history, though, I think that most of you would find that Apple has kept far more of its new commitments than it has broken in the past two and a half years since Steve Jobs assumed the titles of interim CEO and chairman of the board. The projects that died early in his reign were those which bogged down the company, spread its resources, and those which were not profitable. The company's management seems to have stabilized greatly, as Apple's "iCEO" Jobs has lent to it spark, focus, insight, and, not least of all, charisma. While it is not advisable to ignore the past when passing judgement, it is neither wise to dwell entirely there, ignoring in fact the present. In the end, investing even the smallest bit of faith in this company is a personal decision, but it is best to consider both the present situation and history instead of rejecting a concept out of hand.
Concuding Remarks With that, I'll conclude my discussion. Obviously, I'm fairly upbeat and optimistic about this all. My biases are that, admittedly, I own a G3, I run both LinuxPPC and the Mac OS, and I enjoy following Apple's moves in the market; few companies are as continually interesting.
Before I go, I do have a major gripe, though. There is no bug-tracking service or CVS repository!:) I'm sure Apple will rectify that in short order, though. Otherwise, Darwin might just die immediately.:>
I don't feel like finding the specific article to reply to, but someone complains about QuickTime not being documented in this thread. Nothing could be further from the truth; there are thousands of pages of documentation.
However, no, the modern codecs are not documented there. Those are proprietary software that Apple licensed from Sorenson (Sorenson Video), Intel (Indeo), QDesign (QDesign Music), Qualcomm (PureVoice), and Roland (GS MIDI).
Anyone hoping to make a QuickTime player not supported by Apple that would play those modern codecs would have to negotiate licenses with those companies.
And, yes, they would sue if you reverse engineered the formats.
What's wrong with older versions of Quicktime (e.g., the Cinepak CODEC) that played fine on a low-end Pentium or less, running Unix, Linux, Win3.*, Win9*, WinNT, or MacOS? Why pick a newer version of Quicktime that only works on two OSes?
Because CinePak blows goats. Hard. Really hard.
Sorenson Video acheives comparable quality with about a tenth of the bandwidth. A CinePak movie that looks as good as a Sorenson Video with a moderate data rate requires a data rate about as high as the actual decompressed video does.
On the upside, CinePak compresses well with our lossless compression and archival formats (.sit,.zip,.tar.gz,.bz, etc.).
Slashdot Mirror
Yes.
The OS X filesystem is HFS+, the same filesystem used by Mac OS 8.1 through 9.0.
Those are also supported, although filename extensions are also checked as a fallback and to support operaton on metadata-less filesystems, such as UFS (which is fully supported by Mac OS X) or most NFS installations.
Apple employees have discussed this issue several times on the Darwin-Development mailing list. Here's the latest, which was in regards to the GPL licensing of dpkg and why Apple couldn't use it for their installer.
Peter Bierman wrote:
Later in the thread, Wilfredo Sanchez also followed up:
This isn't the case. At any rate, this is not a spur-of-the-moment decision to build the OS for x86. The maintainance of the cross-platform portions of the core OS are more common sense than anything; Apple started out with a cross-platform OS and is sparing enough care to keep it that way.
The APSL is incontestably not a copyleft ("free software") license. It has been approved as an Open Source license, however.
Apple only licenses under the APSL code which is theirs. For example, their GCC code is, of course, licensed under the GPL, and they're working in good faith on narrowing the gap between Apple GCC and GNU GCC by bringing Apple's most well-conceived changes up in mainstream GCC and reassigning copyright to the FSF.
This is a far from insurmountable problem. And, honestly, it isn't as much a problem as you seem to imagine. I would typefy it as a problem solved, and it is not an impediment to brining Darwin up on Intel hardware. Keep in mind that Darwin is the core OS from OpenStep/Mach, which ran on x86, PA-RISC, and SPARC hardware before it was ported to PowerPC when Apple acquired NeXT.
I think you've seriously misclassified Wilfredo Sanchez. His job is managing Darwin and Apple's other recent public source projects. He (and now David Zarzycki) are the conduits through which Apple and the open source community communicate. He's quite dedicated, and this is a big step; cross-compiling an entire operating system is far from simply "a [single] bored engineer blowing off steam." This build required that Apple's core OS development team be fairly rigorous in writing and maintaining cross-platform code. (Admittedly, Darwin is itself a port of OpenStep/Mach's core OS to PowerPC from a codebase that ran on x86, SPARC, and PA-RISC, but many, many, many changes have been made.) Not only that, but the build infrastructure is now such that Apple's public and private CVS servers are largely unified for the core OS; we're getting a live view of of Mac OS X's core OS' development.
Meanwhile, the modified GCC which Apple inherited from NeXT has an engineer dedicated to merging the codebase into the mainstream GNU GCC, copyright reassignment and all. There is even serious discussion of bringing together the GNU and Apple Objective C runtimes.
As I've said in other posts, I don't specifically do not believe Mac OS X will be running on Intel at any point in the forseeable future, but it is my opinion that you've sorely misjudged the rest of the situation.
Keep in mind that the stories Slashdot posts are quite reactionary. "Apple UNIX cross-compiles to Intel!" You expected this not to show up on Slashdot?
Given that, I believe that we'll see Darwin liven up significantly as OS X becomes available, but I do not expect it to make any strong inroads towards replacing FreeBSD or Linux on x86 systems. I fully agree in that we will not be seeing Mac OS X running on Intel in the near future. One of Apple's most valuable assets is controlling the whole box from the operating system down; it allows them to sell well-integrated systems which, as they ship from the factory, rely upon relatively small range of devices whose coresponding software can be well-tested.
This is not the case. Apple does not currently sell any dual-processor machines, and has not since the days of the PPC 604e-based Power Macintosh 9x00, which ended in late 1997 or so.
The rationale for this is that the current Mac OS takes ill advantage of multiprocessors. It uses assymmetric multiprocessing, and the second processor sits idle for the vast majority of time. (Furthermore, the G3's 3-state cache coherency model is insufficient to support more than dual-processor configurations, although the G4's 5-state model is enough to support it very well.) Mac OS X will fully support symmetric multiprocessing, so expect this picture to change in the next year or so.
For their own code, Apple is using their own license, which they call the Apple Public Source License, or APSL for short. It is not a copyleft license, but has been approved as an Open Source license. GPL'd software that they enhance--GCC, for a very notable instance--is, of course, submitted back to the FSF, and folks at Apple are working on reassigning copyright for such software to the FSF. Not, however, the entire operating system, which is APSL. They're playing nice, but probably not nice enough to satisfy many of the ranks Stallman has inexplicably managed to brainwash.
Personally, I think this is a good course of action; I dislike the GPL, and think it especially ill-suited as a license for the basis of a commercial operating system.
The APSL: http://www.publicsource.apple.com/apsl/
Darwin runs Mach-O (Mach object format) binaries. It is a BSD variant built atop a Mach 3.0 microkernel. I don't expect to see a Linux binary compatability environment spring up, but you never know.
Fat binaries are pretty cool, but he's referring only to Darwin, which is a pretty vanilla BSD variant, though with some interesting capabilities. It is very unlikely that Apple will be compiling and optimizing Cocoa, Quartz, QuickTime, Carbon, and all the other high-level libraries for x86 given they're not actually selling a product for that platform.
The fat binary capabilities could certainly ease future architecture transition, however.
Most of what goes on in the core OS isn't going to be significantly advanced by vector processing, though certainly tasks such as copying memory will receive a boost simply due to the increased bandwidth. And remember that Intel and AMD has SIMD, as well, though it's certainly not as high-quality as AltiVec. So, yes, there will be something of a performance drop, but I would wager that it won't be huge.
Quartz (OS X's brand new imaging subsystem) would probably suffer a more noticable performance drop, given the extensive use of transparency.
Actually, it is a lot like that; the Mac's menu bar is a demonstrably superior interface. In fact, if one is to actually time users, a Windows-like menu bar is a factor of five slower to use.
This superiority is a result of Fitt's Law, which states that the time it takes to point at a target with a pointing device is a function of the target's size and distance to that target. The larger the target and the nearer it is, the less time it will take to point to it. This is, of course, trivially obvious when phrased that way, but its implications are ignored far too often by software developers.
The Mac's menu bar uses a very special piece of screen real estate, exploiting Fitt's law. Because the menu bar rests all along the edge of the screen, it has an effectively infinite size; you can keep rolling the mouse upward as much as you like, but that cursor is always going to be in the menu bar. Because of this, it's faster to point at a menu title, and the entire process of using the menu is accelerated.
Of course, the most efficient place to put the mouse is right where it is, so that's an even better place for the menu bar: Under the mouse all the time. The problem is that we don't have a good user interface for that; hierarchical menus are inefficient to use (timewise) and cumbersome. NeXT actually did this, though: A right-click brought up the entire menu bar beneath the mouse, arranged hierarchically. This was in 1989, and most likely begat Windows 95's context-sensitive menus, which are a refinement in that they avoid necessitating the task of navigating cumbersome, deeply hierarchical menu structures to access the most useful commands.
But, all that aside, the Mac's menu bar, after nearly 16 years is empirically the best interface we have for presenting an entire menu hierarchy. Most likely just dumb luck, though; I doubt the designers of the original Macintosh considered these implications in the world of 1983's nine-inch, 512-by-384 monochrome displays while Steve Jobs was breathing down their necks with the refrain, "Real artists ship!"
You can read more about interface design and Fitt's Law at http://www.asktog.com/. It's an interesting, if oft-neglegted, subject.
Ambrosia's still around and still making games as well as utilities. http://www.AmbrosiaSW.com/ has the full scoop. Their games still aren't really up-to-snuff with commercial games, though, if you want my opinion. It would help if Andrew Welch spent less time being a freak and more time coding! (Are you listening, Andrew, you psycho? ;)
This is incorrect.
The reason that Mac OS applications (appear to) consume less memory with virtual memory on is that enabling virtual memory allows the OS to swap out the application's code with file-mapping. With VM off, the code data must always remain resident because the MMU is inactive and thus cannot deal with page faults (accesses to inactive memory). Thus, while you have precisely the same amount of data with VM off instead of on, more of it can be paged out to disk, reducing real memory concumption (somewhat).
It's worth noting that, while with VM on, applications do use less memory, it's not as much less as the Get Info window's memory panel advertises or the About This Computer window reports. This is because some of the code has to be resident for the programs to run. However, none of the memory pages mapped to code are part of the application's heap and thus precisely zero of them are reported in heap-based memory usage statistics (such as the Finder's About This Computer window).
If you have enough RAM, though, there's no reason to run your Mac with VM on; the Mac OS has fairly static memory requirements and generally deals with memory exhaustion more reliably than UNIX applications (where not checking for null pointers is quite common). Turning it off removes one more slight performance hit.
Addressing the resource fork memory usage issue, purgable resources (and handles in general) are always purged if memory constraints are encountered. This mechanism is made possible by the wonderfully screwed up world of handle-based memory allocation.
Just be glad you don't have to make the above code pre-emptable and/or re-entrant.
Apple is using EGCS/GCC 2.95 as its compiler for Mac OS X [client] (not OS X Server; that uses gcc "2.7.2.1" for now).
They've submitted a large quantity of code (mostly from the work done at NeXT) to the GCC maintainers, and work proceeds to integrate the two source bases.
Furthermore, Apple would be nothing short of braindead to release OS X [client] for G4 systems without using an AltiVec-aware vectorizing compiler to generate their code. Since GCC Is the compiler that they're using, it seems more than likely that they will expend considerable resources to making GCC's PowerPC codegen as good as possible. (And LinuxPPC will see the benefits, too. Very cool.) Perhaps they can even integrate some of their work from MrC/MrCpp, Apple's fantastically good optimizing PowerPC C and C++ compilers for MPW.
Oops, omitted something. The standard 450MHz and 500MHz models also include Zip drives.
It's worth noting that more than simply the clock speed changes in each of the standard configurations you've mentioned.
Not that this totally excuses the price increases, but it's not as draconian as you paint it.
(There are also other changes between the motherboard used in the 400MHz G4 vs. the one used in the 450 and 500MHz models, but I haven't mentioned them.)
Like most BSDs, Mac OS X Server and Darwin use UFS. Apple has included an HFS[+] filesystem implementation, but you must boot from UFS. It's expected that Apple will make Mac OS X [client] bootable from HFS+. (Classic HFS will never work, though; doesn't know how to store UNIX permissions like HFS+ does.)
In the future, actually read a license before you comment on it. It's here -- http://www.publicsource.apple.com/apsl. html.
1) The APSL states that Apple may, at any time, revoke your license to use the software. So, if you are developer and have put hundreds of hours into making adjustments so that it fits your needs, you are suddenly without recourse, and your million dollar project is now DOA.
It states that, if Apple is faced with a patent violate lawsuit, they can revoke your license to only the affected portion of code, and they also give themselves the option to either write around the violation or obtain a license for the patent. They cannot revoke your license to the entire product under this clause. If they did not include this provision, they would be exposed to additional liability for providing that protected technology to the public. I think you'll find a similar provision in nearly all open source-ish licenses that corporations with actual legal departments might issue.
The complete termination clause states that (i) your license terminates if you violate the license and do not correct the situation 30 days after a you become aware of your own violation, (ii a) your license to only the affected code might terminate (as describe above) if an intellectual property claim is filed, (ii b) your license terminates if the law prohibits you from complying with the core sections of the license, or (c) your license terminates you file an intellectual property claim against Apple. None of these provisions except (c) are in any way unrealistic.
2) All changes that you make must be submitted to Apple.
You have to publish your changes under any other open-source license, as well. Apple requests that you notify them by using a simple form that they provide. Woe is me. You are free to fork the tree, you are simply asked to tell Apple about it.
3) and if Apple revokes your rights to the license, they get keep and use your modifications without compensating you.
I agree with your dissent on the core issue here, in that Apple's license grants inequal rights to Apple and to the licensees. However, I can also see the justification; Apple does utilize this same codebase for a commercial product that, while it includes this codebase, also includes additional code which is not covered by the APSL or any other public source license. (This is reasonable; expecting the entirety of Mac OS X Server to be available as a free download is currently unrealistic, given Apple's business model. Perhaps in time that will change, but it will be a very long time.)
Stallman makes good points, articulating them much more clearly than either RMS or Bruce managed to. He did such a good job at articulation and logic that I almost found myself agreeing with him by the time I was finished reading his thoughts.
Then I woke up.
Stallman, as always, places idealism before practicality and goes to far as to ignore the latter. Whether or not that's good is up to the individual. Idealism doesn't always work, communism being the classic example. Stallman's ideal is a far stone's throw from communism; his does actually work in the right circumstances. However, I think the point Stallman fails to recognize (or dismisses) is that Apple is a corporate entity that has a responsibility other than living up to Richard's ideals. It has a responsibility to its employees to make money so that it can comphensate them for their efforts; this is a virtuous goal. One of the most significant ways in which it currently accomplishes this is by selling software. Apple can't discard that business at the drop of a hat. Ultimately, it has to make money somehow. As such, I don't believe that we will see a license that agrees with Stallman's "copyleft" ideal from Apple in the near future. Indeed, doubt that you'll find in the near future one from any company that makes its money by selling its developer's time, as these companies have an obligation to their investors and to their employees to make money. This is why Apple retains rights under the APSL.
Another point that Stallman entirely neglects to mention is that Apple cannot currently release its entire codebase for OS X Server under an Open Source, Free, or Copyleft license currently. Most notably, it doesn't own Display PostScript, upon which the Yellow Box APIs (the interesting bits of OS X Server) are predicated. It is reported that. Other technologies that it has licensed are surely more common than I could recount, but, very significantly, all modern QuickTime codecs and all of the ColorSync color management modules are licensed code. In short, the Yellow Box doesn't work (currently) if you remove the licesnsed technologies.
Of the first three criticsms, as to why the APSL is not a Free software license, I agree with Stallman except on the third item, which is that the APSL can terminate at any time. The GPL provides a similar termination clause. The APSL shifts responsibility for patent infringement, however, from the individual to a particular Apple Computer, Inc. Whether or not this is agreeable is another individual decision, but the reasoning is sound--Apple cannot be sued for releasing code that infringes upon patents. Now, if it falls under a suit, it has a method to clear itself of infringement that does not involve broach of contract (that contract being the APSL, if it were not to include a similar termination clause). I believe it's clear from the license that Apple would make a good faith effort to clear the infringement, and it's also worth noting that only the code directly in infringement is affected.
The reason that this clause really becomes necessary, though, is that this software was not born and bred GPL. It's been extensively modified for more than a decade by both NeXT and Apple. If there is an intellectual propery violation in the code, the responsibility for that violation is not with the entire community (which is where the GPL places it), but instead with the entity which developed the original code that was released to the public, Apple; the company must protect itself from liability by allowing itself to back out of patent infringements gracefully.
In short, Stallman's idealism is incompatable with the corporate interests of Apple as well as the nature of the development of the code that is being released. This is why the GPL and the APSL are incompatable; they were written by seperate groups which have seperate goals.
You're full of it. :) After the quoted section 2.1 of the APSL, you will find section 2.2, which describes what you must do if you are to deploy the code. Section 2.1 grants you rights to tinker with the code, but not find a web space, notify Apple, and put out your modifications so long as you do not deploy it. Deploy is defined near the top of the license, and includes internal use for purposes other than R&D as well as distrubution.
The Apple Public Source License.
It'll be interesting to see how this turns out in the long run, but I'm quite pleased for now, as:
This seems very reasonable to my eyes, and I can't see how it's anything other than either a positive--or perhaps irrelevant for some--development for the industry. It's certainly not a negative turn of events, though.
But, still, I've got a few comments in response to the various recurrant threads.
Termination and Liability
First of all, regarding the license's termination clauses in case of an intellectual property lawsuit, I do think that you all have to think for a moment about the forces at work. Apple's a large corporation; they have to protect their employees and stockholders. I think that it's clear enough from the license that they would make a good faith effort to work around the dispute if possible. All licenses issued from large companies will most likely harbor similar clauses to protect the company from liability.
Liability from Termination
In that same vein, I believe that it's not especially reasonable to expect Apple to use that clause to terminate your licenses on a whim. The APSL protects Apple's interests, certainly, but it doesn't make it easy for Apple to back out, either. If Apple were to bribe a company to sue for intellectual property violations, it would certainly create a scandal and perhaps even a class action lawsuit. (I am not a lawyer, however.) In my eyes, it would be more likely that, if Apple wished Darwin to go away, it would simply let the project languish instead of risking condemning press and exposing itself to even more liability. The company is under no contractual obligation to synchronize the Mac OS X and Darwin projects, so letting the project die out is not a difficult path to take.
OSS vs. Free (Again)
Thirdly, those of you arguing against Open Source and for Free Software should perhaps take a dose of pragmatism. Apple is has just taken a very large step closer to your ideal; that they have not acheived it yet is an invalid justification for criticsm in the face of the fact that they are working toward that end. Given, they are moving cautiously, but that is as any entity of this company's scale should. Multibillion-dollar corporations do not turn on a dime.
Issues of Trust
Finally, the arguments against trusting the company certainly have their justifications, and I won't pretend to contest them. Apple has a long history of turbulent management. From the Apple II, to clones and PPCP, to OpenDoc and the Newton, there are many instances of about-faces that were damaging to third parties. Looking at more recent history, though, I think that most of you would find that Apple has kept far more of its new commitments than it has broken in the past two and a half years since Steve Jobs assumed the titles of interim CEO and chairman of the board. The projects that died early in his reign were those which bogged down the company, spread its resources, and those which were not profitable. The company's management seems to have stabilized greatly, as Apple's "iCEO" Jobs has lent to it spark, focus, insight, and, not least of all, charisma. While it is not advisable to ignore the past when passing judgement, it is neither wise to dwell entirely there, ignoring in fact the present. In the end, investing even the smallest bit of faith in this company is a personal decision, but it is best to consider both the present situation and history instead of rejecting a concept out of hand.
Concuding Remarks
With that, I'll conclude my discussion. Obviously, I'm fairly upbeat and optimistic about this all. My biases are that, admittedly, I own a G3, I run both LinuxPPC and the Mac OS, and I enjoy following Apple's moves in the market; few companies are as continually interesting.
Before I go, I do have a major gripe, though. There is no bug-tracking service or CVS repository! :) I'm sure Apple will rectify that in short order, though. Otherwise, Darwin might just die immediately. :>
I don't feel like finding the specific article to reply to, but someone complains about QuickTime not being documented in this thread. Nothing could be further from the truth; there are thousands of pages of documentation.
http://deve loper.apple.com/techpubs/quicktime/qtdevdocs/RM/fr ameset.htm
However, no, the modern codecs are not documented there. Those are proprietary software that Apple licensed from Sorenson (Sorenson Video), Intel (Indeo), QDesign (QDesign Music), Qualcomm (PureVoice), and Roland (GS MIDI).
Anyone hoping to make a QuickTime player not supported by Apple that would play those modern codecs would have to negotiate licenses with those companies.
And, yes, they would sue if you reverse engineered the formats.
What's wrong with older versions of Quicktime (e.g., the Cinepak CODEC) that played fine on a low-end Pentium or less, running Unix, Linux, Win3.*, Win9*, WinNT, or MacOS? Why pick a newer version of Quicktime that only works on two OSes?
Because CinePak blows goats. Hard. Really hard.
Sorenson Video acheives comparable quality with about a tenth of the bandwidth. A CinePak movie that looks as good as a Sorenson Video with a moderate data rate requires a data rate about as high as the actual decompressed video does.
On the upside, CinePak compresses well with our lossless compression and archival formats (.sit, .zip, .tar.gz, .bz, etc.).