Another Look At OS X
mduell writes: "Apple has been close to their golden master copy of OS X for a week or so, but they've still been making nightly builds to squash the rest of the bugs. These last minute copies have all sported a "Build 4K78" in their info window, and many of them have been leaked to outside sources. Reviewers who got their hands on the system wrote extensively about how 4K78 was horrible, yet today resellers across the world received boxed copies marked as 4K78. This article explains what happened, as well as explains how many bugs to expect, and why Apple dropped the ball on a few features (like DVD)."
If true, then why do people get the same checksum for the final and the RC that was shipped to devs? And why do some with the dev version say it's fast, and some with the final say it's dog-slow(slower than the PB!), if the final is so much different(I know you're not saying "so much" different, but if they removed the debug code and fixed a few remaining bugs...)
That article is BS. The retail version is bit by bit, byte by byte identical to 4K78 shipped to devs. Here is a post from MacNN forums explaining the situation(was a reply to the same article):
-----
No this is wrong, and I've already contacted the author. The article about 4K78 couldn't be more wrong. There was one single, unique build of 4K78 and that's it. The Developer RC CD and the final Retail CD have identical bytecounts, checksums, creation and modification dates, etc. Apple/NeXT's versioning system had ONE unique build number per build, and that is it. Between builds, there can be modifications and builds of components, but each full build with an associated build designation is the only one there is. Now: there were some 4K78's floating around the net that had been imaged with Disk Copy rather than Toast that won't show proper sizes and dates. But any properly created images and/or actual, official CDs will all be identical. There are NO CHANGES, in any way, from the Developer RC CD to today's Retail CD. I don't know how more pointedly to put it. Some people actually go so far as to say Apple is tricking you by making the Retail CD "look like" the Developer RC, even though it's really different. You have to be fucking kidding me. The bottom line is Apple does not have dozens, several, or even two builds of 4K78. There is one, and it was accepted as RC, accepted as GM, and accepted for manufacuring. There WERE NOT daily builds of OS X after RC was declared. 4K78, in its single incarnation, was the end of the line. If people want to *believe* that the Retail 4K78 is different from the RC 4K78, great. But it's not true. Posting articles like this further confuses the issue. The MAIN reason 4K78 was left in was so that people could see FOR SURE that the Retail was the same as the RC: that's the WHOLE PURPOSE of a build number - to uniquely and certainly identify a build. It started out with people being convinced that there were 4K8* series builds (there were never, and never will be, 4K8* builds. Future OS X development will happen in totally different build trees with different versioning, milestones, etc.), with people wanting to believe there was something oh-so-much-better than OS X 4K78. Then, when people were finally convinced that what was in the boxes was 4K78, build number in the About Box and all, they said "maybe Jobs will announce something on the 21st". When nothing was announced on the 21st, they started grasping at straws, making up ridiculous stories about how there were many many different 4K78's and the developer 4K78 was an internal debug version and the retail version is some magical optimized version rebuilt several times, yet still maintains the 4K78 designation and was even designed to LOOK identical to the developer RC to throw people off, with fake checksums and all?? It defies logic. And well it should, because none of it is true. 4K78 is 4K78 is 4K78, period. What's in peoples' boxes this Saturday is identical in every way to what developers received 3 weeks ago. And it's a great release; enjoy.
PS - Doesn't anyone realize what a support nightmare having multiple builds with the same build number would be. That's just rediculous. For the LAST TIME: any (legitimately obtained) copy of 4K78 is the same as ANY other 4K78.
THE MAC OS X DEVELOPER RELEASE CANDIDATE 4K78 CD IS IDENTICAL IN EVERY WAY TO THE MAC OS X 10.0 RETAIL 4K78 CD. THERE ARE NO DIFFERENCES WHATSOVER.
The author of the article was kind enough to respond, and conceded that it was just a "theory", i.e. he hasn't compare the CDs himself. Additionally, he's more referring to illegally obtained builds of of hotline and carracho, which could be fake, improperly imaged, etc. All REAL 4K78's out there, i.e. ones obtained legitimately from Apple, are CERTAIN to be identical.
OSX has two local filesystems (let's just leave the network out of this).
.AppleDouble type folders, I don't know exactly how it works, I use HFS+)
UFS: The traditional UNIX filesystems. This FS is case sensitive and act's like UFS is supposed to act. Apple had to do some clever (or not so clever) hacks to get UFS to invisibly support Mac resource forks (ala
HFS+: The third version of the Macintosh filesystem, this FS is NOT case sensitive, but is case aware. Thus README and readme would be the same file. However, since the FS is case aware, it keeps the case you want. (REaDMe would remain REaDMe). Apple had to do some clever kernel hacks here too, since HFS+ does not support hard links either.
--
Though I use a Macintosh, I am not a mac-bigot. I just hate Windoze.
This is most evident in the NeXT, which had a 2-button mouse. There was a control-panel "preference" that said "make the buttons act alike". This made the right-mouse button act like the left one so it was a single button. The machine shipped with this mode set by default.
The really odd thing about it was the implementation: turning on this mode actually changed the "server" (similar to an X server) so that clicking the right mouse button returned an event indistinguisable from a left button. It was not done inside the NeXTStep code which ran in user space, which would seem to be the obvious implementation. Unlike everything else on the server (like keyboard mapping!), you could not change it with PostScript code, and only a program with suid privleges could change the setting (and even then it was undocumented). As far as I can tell, every other preference on the control panel was done simply in user space by NeXTStep.
He really really wanted to make sure it was impossible to write a program that used the right button, and was willing to make bad software design just to enforce it!
For this reason I have said many many times here that file systems should be case sensitive, in fact the file system should just treat filenames as strings of bytes and only an identical stream of bytes will identify the same file (thus if UTF-8 is used, only a single encoding of a name works even though the UTFUnicode mapping is not really 1:1). Only by using such a scheme can the file systems be fast and free of security holes.
The problem is, many people seem to think that if the file system is case sensitive, that the user has to type filenames with the correct case. This is false, there is no reason that user-level programs cannot do their own case-insensitive search for a matching file (they could also do more complex things like spelling correction).
I'm not sure why so many otherwise bright people are under this delusion, but it is causing a great deal of trouble.
It is good to see that Apple is supporting a case-dependent file system. It would be interesting to see their user-level solutions to making this user friendly, perhaps when (if?) they do it it will wake up all the idiot FS designers and NT defenders out there.
First of all, cars have bugs.
Second of all Linux probably has more than 63,000 bugs if you look at what ships from distributors. It's just that people classify bugs differently.
If I have a window that leaves artifacts if I move it around, that's a bug, even if they go away the next time something is moved over them. In fact, that may be several bugs, especially if it occurs at the driver level (it may happen on 20 drivers, so that's 20 bugs).
If Mozilla shifts an image one pixel to the left too far, that's a bug, even though anyone but the most hardcore testers may ever notice it.
Linux people tend to misunderstand what a bug is. We're used to dealing with and complaining about major bugs. Then when someone says, "the O.S. has 63,000 bugs" we think it has 63,000 major bugs. But that just isn't true. Bugs can also be potential race conditions that have never been exploited, or potential memory leaks that have never been looked at.
For example, if I'm programming, and I'm not sure if something I'm doing will cause a memory leak, I should add that as a bug. If the program is "notepad", there's no reason to ever even examine that bug, simply because notepad isn't a long-running app that will be affected by memory leaks.
Anyway, I agree that software has too many bugs, and that its the fault of both the distributor for not testing and the consumer for not demanding better. However, I do think you should take any bug count with a grain of salt because many of them refer to conditions that most people may not think of as bugs.
Engineering and the Ultimate
I don't think the author is proposing a "none is better than some" plan. He is merely saying that it's better to have an almost flawless overall system, missing a few specific features, than have an overall crappy system. In a situation such as Apple's, these are indeed the only two choices of the matter.
The thing is that they're NOT fixing bugs right now. They neglected to include a few features (like DVD) in order to meet deadline, but still nail all the bugs. Personally, I'm glad they chose this route.
Despite the tone of occasional disappointement at "missing" features (so write it or port the Linux version,) I'm glad to see that /.-ers are more concerned about the new qualities of the OS than its short comings.
Jobs was right. Just like Apple became the largest unit sales seller of RISC machines within one year of the introduction of the PPC boxes, Apple will become the largest unit sale seller of Unix boxes within one year of the introduction of OS X.
That's twice Apple has accomplished a complete change of supporting architecture without throwing the baby out with the bath water.
M$ must be feeling a little ill after failing at least twice to get off the x86. The coming 64 bit machines (needed to handle biometric information to turn packets on the 'net "black," and make life much, much harder for the "script-kiddies,") will wipe M$ off the map.
The OS Wars are over. Unix won.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Your answer is not quite right - I plan to get an OSX box for Java work as well, and possibly one as a server.
Why? One simple reason is that at the core, Mach (which is what OSX is built around) offers light-weight threads which should mesh better with the threads Java uses than Linux or BSD alone would.
Also, from what I've read it seems like there is much better Java integration throughout the system (like a Java Coco (sp?) API) so I stand a better chance of being able to customize some of the UI using Java.
Also, a last point unrelated to Java is that I simply have to offer what support I can to an OS that offers a sane standard package management structure. I think that for everyday use, OSX will require a bit less of my time to work with than Linux. Not that I still wont have other boxes that run Linux, I just plan to do most of my work in OSX.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think there needs to be a new moderation category for ill-informed repetitive posts like this - "Nuke". It would take all five moderation points to perform, and could only be done once a month. The effect would be the removal of the post, the canceling of the user account and/or IP that generated the post, and removal of all other messages from that poster/IP. It would also launch an IRC bot that would make constant disparaging remarks about the user in a variety of forums.
Then, we would cease to hear from people that do not realize the mac supports USB mice and thus three button mice - with wheels.
A side note - the Mac ALSO supports single button mice, so it is actually superior to just about anything else by virtue of supporting a wider range of mice. Can you imagine trying to use a single button mouse in X? I guess you don't care about usability of systems at all, yet another reason why we need a NUKE moderation.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I couldn't find any info in the article if there is no support for DVD or just no DVD player bundled.
No player - I've been using the OS X Beta on a G4 with a DVD-ROM drive, and had no problem accessing DvDs. You can always dual-boot with Mac OS 9 to play DVDs until OS X gets that feature - it's not hard to do (just install Mac OS 9 on a separate drive or partition). I know I'll be dual-booting to the classic Mac OS for a while anyway, since not all hardware is going to be supported in Mac OS X for a while, and I'm sure a lot of 3D-accelerated games will play better under straight Mac OS 9 without going through the compatibility layer.
Naked.
I have build 4k73 (very close to final version) and it has a tool in the control panel that you can have it fetch updates from Apple. It is added to the cron automatically if you wish and it will look for updates every night or every friday for example.
--------------------
Would you like a Python based alternative to PHP/ASP/JSP?
I have been using it for about 4 weeks (Got build 4k73 when it was first released).
With exception of a the occasional IE crash (not OS crash) the system ran without a hitch. I had it on a iBook which is a relatively slow and old machine. (Especially when compared to my Dual PIII 800 SCSI 166 running Debian SID with KDE).
I am not one of those people that need DVD playback. I have a DVD player and TV for that. I just need good Java support and a decient terminal and X windows. OSX gives me all of that.
My G4 just arived this week and now all I need to do is buy a Gigabit ethernet for my Linux box and I have one of the coolest development environments I could ask for. (Linux apps for server and Java profiler...) I was able to get JBuilder 4.0 Enterprise for Windows actually working on OSX.
I was quickly able to get wget, vim, Lynx, Python and Perl working fine on the machine and was quite comfortable. As far as the Unix side of things, the only problem people might find is that the directory structure is a LITTLE bit different than what you are used to. (Still has
But the nice thing is now I can run Photoshop, JBuilder, IE, Mozilla, Netscape, iMovie (Which is actually a DAMN cool program
But OSX most importantly stays out of my way and just lets me work.
Also the fact that Apple is packaging everything needed to do full development is pretty neat. They are starting to learn that they will get market acceptance with empowerment of the programmer.
I am also happy that OSX allows me to very openly work in a heterogenious environment as Windows and the old MacOS seem to do the exact opposite. I see it as Linux, BSD, etc just gained a great ally.
--------------------
Would you like a Python based alternative to PHP/ASP/JSP?
What, a distribution CD-Rom for buggy software? First, all software of any complexity has bugs -- always. There are only three kinds of programs, those with bugs you knows about, those with bugs you don't know about, and those with both.
Fixes to software do not change this. A fix of a bug you know about can at best change a type A or type C program to a type B program.
Nobody has been in this business for very long who does not understand this.
So, the question isn't whether the distro is buggy -- the question is whether the distro works well enough that known bugs can be repaired by updaters, ideally through the network. If we can install it, boot it, get online, download the updaters, and run them, the distro did its job.
Physical distros serve two purposes -- (1) to serve as a token of ownership; and (2) to serve as a vehicle to reduce the amount of time/bandwidth necessary to install the software.
I assume OSX, as delivered, will be a type C program. It will have bugs and megabugs. I also presume that Apple did sufficient Q/A to assure that the installation and updating processes will work. If so, thats all that it needs to be.
To the naysayers, what is the alternative? Can anyone suggest a fully-tested on-time bug-free distribution CD?
Bugs in an installation media don't really bother me.
They should, the vendor has your purchase now, what guarantee do you have they will fix the bugs?
I work for the Technical Support division of a major (multi-platform) vendor. We do this shit all the time, release stuff to satisfy a marketing schedule, then decide to drop fixes that -really, really- should have been in the released product.
All the time we (as customers) accept buggy products with a promise to 'fix it in a service pack', companies will not improve the fundamental reliability of their products and release practices.
EZ
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
I don't know how much sense porting OS-X to Linux would make. Altough Linux 2.4 is a much better system than Mach/FreeBSD 3.2, by taking out BSD and Mach, you get rid of much of OS X. Maybe you're thinking of porting Quartz, Aqua, and OpenStep to Linux? In that case, you won't be happy to hear that all of the above are closed source, and thus will not run on x86 unless Apple ports it.
A deep unwavering belief is a sure sign you're missing something...
I'm curious what kind of update/package system OS X uses...I have searched and not found word one about it. I assume since it is UNIX, it can use whatever current standards (RPM?) there are but this seems like a feature Steve Jobs would be hot to get his hands into.
Bugs in an installation media don't really bother me. God knows I'd have to be insane to leave any version of Windows the way it comes on CD (My most recent NT4 CDs are still just SP1!). So then why not push out the OS X CD on the due date and then throw out nightly "recommended updates" until its working the way it should?
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
Does MacOS X have a DVD driver at all? Can you access the drive? Maybe someone will write a third-party player.
If using Linux (and participating in the community) for 5+ years now has taught me anything about OS development, it's that there is always more to do, whether it's adding support for new technologies, improving SMP, debugging, etc. Regardless of the bugs currently present in OSX, I still consider it to be a huge step forward for Apple, just as I considered the 2.4 kernel (bugs and all) to be a huge step forward for the Linux community.
Besides, I'd rather see Apple release OSX 1.01 two weeks from now, than wait 6 months for the first "service pack", eh?
He who joyfully marches in rank and file has already earned my contempt. - "Big Al" Einstein