"The repeated nature of the same classes of bugs throughout the source tree, also showed us that most programmers learn to code by (bad) examples. A solid systems's approach should not be based on "but it works". Yet, time and time again, we see that for most people this is the case. They don't care about good software, only about "good enough" software."
See also: the "HTML" on the supposed "geek web site" called Slashdot. (as well as, to be fair, the rest of the web.)
What bloat are you talking about? Do you think software that uses RAM unwisely or contains sloppy algorithms necessarily takes up more space on disk? Mac OS X makes extensive use of dynamic linking and shared libraries. I hardly think it qualifies as "bloated" in terms of disk space usage.
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Interesting ports on (x.x.x.x):
(The 1522 ports scanned but not shown below are in state: closed)
Port State Service
67/tcp filtered bootps
111/tcp open sunrpc
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
513/tcp open login
514/tcp open shell
760/tcp open krbupdate
763/tcp open cycleserv
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
[The AppleMenu] is NOT obvious it's a menu, it is NOT obvious how to add things to it and quite frankly a clear majority of users (both Mac and Windows) I know just put alias' on their desktops.
I mostly agree with that. And those users can continue to just ignore it (it's one tiny icon, after all.)
But there's no reason that a UI element that duplicates the functional merits of the Apple menu (as outlined in the article) also needs to duplicate its faults: the obscure icon, the non-obvious customization, etc.
He also left out one of the most relevent piece of ease of use info about Mac OS X. Drag and Drop installation of Applications.
That was covered in many of the earlier articles in the series.
Well, there is some truth to Darwn being monolithic. It's essentially Mach with a BSD system sever. Why you'd do that, I have no clue, since one of the benifets of a microkernel is that severs are independant. With Mach/BSD, you have to problem of system complexity due to the monolithic design, and you have the problem's with overhead that Mach brings with it. Silly really.
The BSD subsystem is in the same address space as Mach, but all of Mach's interfaces are preserved. This is much faster than a user-level BSD subsystem, and it does not sacrifice the modularity of Mach's native interfaces.
Re: "Also, I don't really see why an XML based registry is any easier to use than a binary registry." It's not an ease of use issue (although XML files at least provide the option of editing by hand with a simple text editor), it's about leveraging existing open standards instead of dealing with multiple reinventions of the wheel.
Re: "Windows has API calls to manipulate the registry"
...and Mac OS X has APIs to manipulate XML property lists. There's nothing about XML files that make them any less applicable to high-level API access than binary data files.
Re: "The registry is considered a persistant information storage for an app."
Unfortunately, unlike the classic Mac OS "Desktop Database," it cannot be perfectly recreated based on the contents of the drive. In other words, delete the registry and you're hosed. Delete the desktop database in classic Mac OS and it just rebuilds itself the next time you start up.
(A variant of the desktop database is present in Mac OS X DP3)
Now that a think about it, the Ars Technica article defines three generations of display software: the second generation being most current GUIs with still relatively pixel-based drawing, and the third being Quartz that is largely vector-based with some added capabilities. With this system, Berlin is definitely at least fourth generation with instead of drawing to pixels like the second generation or drawing to vectors like the third generation, Berlin draws to much more abstract drawing primitives on top GGI.
Unless I'm missing a major feature of Berlin, I'd still classify it as 3rd generation. The three generations are a very broad classifications system and there's a large range withing each generation. They can be summarized as: simple screen element addressing (1st), resolution-dependent primitives (2nd), and resolution-independence (3rd). The 4th generation I had in mind is 3D (even if it's still displayed on a 2D screen).
Very few display layers fall neatly and completely into those categories, but it's still possible to find a "best fit." For example, classic QuickDraw can handle resolution-independent typefaces, but it's still clearly 2nd generation overall.
It's not a comprehensive classification system by any means, but I though it helped make the article more accessible to non-technical readers. An unfortunate side-effect is the steady stream of readers who seem to come away with the belief that the Mac OS X GUI is "made of vectors." It's not. It's made of bitmaps. A completely vector-based GUI is certainly possible with Quartz, but that's not what's Apple has chosen to create.
Besides, I didn't see any mention of "vector-based graphics" on the Graphics page of Apple's stuff on MacOS X; "vector-based graphics" may have been Ars Technica's term - as suggested above, I'm not sure I'd use it, and that may be why Apple doesn't appear to be using it there, either.
"Vector" was not the best choice of words, perhaps, but it is common shorthand for what are also known as "resolution independent" graphics. That is, graphics that are not defined in terms of individal screen elements (pixels) but rather by a parameterized description of paths and fills. Image formats of this type (EPS, Adobe Illustrator files, etc.) are often referred to as "vector images," thus my use of the term.
Try not to think "vector" as in "magnitude and direction," but rather think more along the lines of "component vectors" that define a more complex path. Not much better, maybe, but it's not always easy to nail down "common usage."
The author of the article in ars technica is obviously quite clueless concerning the things he is prais^H^H^H^H^Hwriting about.
...and you obviously didn't read the article. Nowhere does it mention vector-based icons or window widgets, let alone praise them. Why? Because none were demonstrated during the MWSF keynote, and there's no indication that they'll be present in Mac OS X.
The article claims that keeping track of shapes as objects in the server is some breakthrough development.
Actually, the article says that 3rd generation display layers have been around for over a decade.
The rest of us have had that kind of graphics canvases in our toolkits for years (with Tcl/Tk and GNOME being only fairly recent examples).
See above.
The reason why they aren't used for everything is because it's not always either efficient or convenient to do so.
NEXTSTEP ran acceptably on a 40MHz 68030 with its 3rd generation display layer. I'd say efficiency is not a big issue if the system is implemented well.
The use of transparency in the UI isn't new either, not even in a commercial product.
You're right. Even classic Mac OS has used transparency during certain operations for some time (icon dragging, file name areas on the desktop, etc.) I'm not sure where in the article you read that the use of transparency in Aqua is a totally new development.
The article claims that keeping track of shapes as objects in the server is some breakthrough development.
Actually, the article says that 3rd generation display layers have been around for over a decade.
The rest of us have had that kind of graphics canvases in our toolkits for years (with Tcl/Tk and GNOME being only fairly recent examples).
See above.
The reason why they aren't used for everything is because it's not always either efficient or convenient to do so.
NEXTSTEP ran acceptably on a 40MHz 68030 with its 3rd generation display layer. I'd say efficiency is not an issue if the system is implemented well.
The use of transparency in the UI isn't new either, not even in a commercial product.
You're right. Even classic Mac OS has used transparency during certain operations for some time (icon dragging, file name areas on the desktop, etc.) I'm not sure where in the article you read that the use of transparency in Aqua is a totally new development.
That being said I have read that it also has a hidden file to keep track of some of the resource stuff. Particullarly the file types and creators. That being said I don't know if Mac OS X will use HFS+ (which supports resource forks) or UFS (which doesn't) I believe all the current build support HFS+ but use UFS as a default and may or may not be able to boot off HFS+.
Mac OS X DP2 installs on (and boots from) HFS+ by default. Carbon (and, of course, classic) applications that have resource forks must be stored on HFS+ volumes rather than UFS. HFS+ will be the default volume format for Mac OS X unless something drastic changes between now and release.
Since the kernel is based on BSD, will OS/X use a relatively standard Unix filesystem? In the past MacOS had that wacky system of a "data fork" and a "resource fork". Does anyone know how that will be bolted into a Unix environment?
The kernel is based on Mach, not BSD.
There's some information on the filesystem issues in an earlier Ars article. Check it out (Skip to the section on "meta-information" if you're in a hurry.)
Will someone please buy these guys a programming book of some kind? Checking return values? Using Perl's quoting operators? Avoiding namespace pollution? Hello? Anyone home? Gah!
It's reasonable to assume that they're using "icns" resources (which have been in Mac OS since 8.5), which come in predefined sizes from 16x16 to 128x128, and from 1-bit to 32-bit (with an 8-bit mask). The scaling probably just handles the "in between" sizes: 128...(scaled)...64...(scaled)...32...etc.
When will the HTML on Slashdot actually be valid? You know, matched tags, quoted attributes, little things like that. It's totally sad that a "geek" web site like Slashdot has such horrible HTML.
(The whole Perl code quality issue has been raised by others, so I'll leave that mess alone for now.)
Slashdot Mirror
See also: the "HTML" on the supposed "geek web site" called Slashdot. (as well as, to be fair, the rest of the web.)
What bloat are you talking about? Do you think software that uses RAM unwisely or contains sloppy algorithms necessarily takes up more space on disk? Mac OS X makes extensive use of dynamic linking and shared libraries. I hardly think it qualifies as "bloated" in terms of disk space usage.
Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Interesting ports on (x.x.x.x):
(The 1522 ports scanned but not shown below are in state: closed)
Port State Service
67/tcp filtered bootps
111/tcp open sunrpc
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
513/tcp open login
514/tcp open shell
760/tcp open krbupdate
763/tcp open cycleserv
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
I mostly agree with that. And those users can continue to just ignore it (it's one tiny icon, after all.)
But there's no reason that a UI element that duplicates the functional merits of the Apple menu (as outlined in the article) also needs to duplicate its faults: the obscure icon, the non-obvious customization, etc.
That was covered in many of the earlier articles in the series.
The BSD subsystem is in the same address space as Mach, but all of Mach's interfaces are preserved. This is much faster than a user-level BSD subsystem, and it does not sacrifice the modularity of Mach's native interfaces.
More information is available here.
(Slashdot needs to allow post editing to correct typos.)
This link may provide some answers (check out question 3).
Not only was the Newton OS implemented according to this paradigm, I believe it even used the exact same word to describe its filing system: soup!
;-)
(Insert your own Soup-Nazi/Jobs/Newton joke here
Re: "Also, I don't really see why an XML based registry is any easier to use than a binary registry." It's not an ease of use issue (although XML files at least provide the option of editing by hand with a simple text editor), it's about leveraging existing open standards instead of dealing with multiple reinventions of the wheel.
Re: "Windows has API calls to manipulate the registry"
...and Mac OS X has APIs to manipulate XML property lists. There's nothing about XML files that make them any less applicable to high-level API access than binary data files.
Re: "The registry is considered a persistant information storage for an app."
Unfortunately, unlike the classic Mac OS "Desktop Database," it cannot be perfectly recreated based on the contents of the drive. In other words, delete the registry and you're hosed. Delete the desktop database in classic Mac OS and it just rebuilds itself the next time you start up.
(A variant of the desktop database is present in Mac OS X DP3)
What? You mean you're supposed to check return values?!? But I thought "Slash" 0.9 code was the product of hardcore "geeks"! Oh, I'm so disillusioned!
Unless I'm missing a major feature of Berlin, I'd still classify it as 3rd generation. The three generations are a very broad classifications system and there's a large range withing each generation. They can be summarized as: simple screen element addressing (1st), resolution-dependent primitives (2nd), and resolution-independence (3rd). The 4th generation I had in mind is 3D (even if it's still displayed on a 2D screen).
Very few display layers fall neatly and completely into those categories, but it's still possible to find a "best fit." For example, classic QuickDraw can handle resolution-independent typefaces, but it's still clearly 2nd generation overall.
It's not a comprehensive classification system by any means, but I though it helped make the article more accessible to non-technical readers. An unfortunate side-effect is the steady stream of readers who seem to come away with the belief that the Mac OS X GUI is "made of vectors." It's not. It's made of bitmaps. A completely vector-based GUI is certainly possible with Quartz, but that's not what's Apple has chosen to create.
"Vector" was not the best choice of words, perhaps, but it is common shorthand for what are also known as "resolution independent" graphics. That is, graphics that are not defined in terms of individal screen elements (pixels) but rather by a parameterized description of paths and fills. Image formats of this type (EPS, Adobe Illustrator files, etc.) are often referred to as "vector images," thus my use of the term.
Try not to think "vector" as in "magnitude and direction," but rather think more along the lines of "component vectors" that define a more complex path. Not much better, maybe, but it's not always easy to nail down "common usage."
...and you obviously didn't read the article. Nowhere does it mention vector-based icons or window widgets, let alone praise them. Why? Because none were demonstrated during the MWSF keynote, and there's no indication that they'll be present in Mac OS X.
Whoops, I meant to type 68040 there.
Actually, the article says that 3rd generation display layers have been around for over a decade.
See above.
NEXTSTEP ran acceptably on a 40MHz 68030 with its 3rd generation display layer. I'd say efficiency is not a big issue if the system is implemented well.
You're right. Even classic Mac OS has used transparency during certain operations for some time (icon dragging, file name areas on the desktop, etc.) I'm not sure where in the article you read that the use of transparency in Aqua is a totally new development.
Actually, the article says that 3rd generation display layers have been around for over a decade.
See above.
NEXTSTEP ran acceptably on a 40MHz 68030 with its 3rd generation display layer. I'd say efficiency is not an issue if the system is implemented well.
You're right. Even classic Mac OS has used transparency during certain operations for some time (icon dragging, file name areas on the desktop, etc.) I'm not sure where in the article you read that the use of transparency in Aqua is a totally new development.
Mac OS X DP2 installs on (and boots from) HFS+ by default. Carbon (and, of course, classic) applications that have resource forks must be stored on HFS+ volumes rather than UFS. HFS+ will be the default volume format for Mac OS X unless something drastic changes between now and release.
The kernel is based on Mach, not BSD.
There's some information on the filesystem issues in an earlier Ars article. Check it out (Skip to the section on "meta-information" if you're in a hurry.)
...and they also provide 3rd generation display layers. This is mentioned in the article. Did you read it?
"They" don't claim any such thing. "Third generation" means just that: "third." Not "totally new" or "never been seen before."
He talks about the QT4 player, Mac OS X, and GUIs in general. Listen in.
Will someone please buy these guys a programming book of some kind? Checking return values? Using Perl's quoting operators? Avoiding namespace pollution? Hello? Anyone home? Gah!
It's reasonable to assume that they're using "icns" resources (which have been in Mac OS since 8.5), which come in predefined sizes from 16x16 to 128x128, and from 1-bit to 32-bit (with an 8-bit mask). The scaling probably just handles the "in between" sizes: 128...(scaled)...64...(scaled)...32...etc.
When will the HTML on Slashdot actually be valid? You know, matched tags, quoted attributes, little things like that. It's totally sad that a "geek" web site like Slashdot has such horrible HTML.
(The whole Perl code quality issue has been raised by others, so I'll leave that mess alone for now.)
G 41D89A (and that's from memory, heh :-)