In the normal world, "x86-based systems" are "open" in the sense that anybody can build them
Umm, anyone can buy them from Intel or AMD and resell them.
"Them" here, of course, referring to Intel's x86-based systems, such as their blade servers, rather than to their chips, as "x86-based systems" refers not to x86 chips, but to systems based on those chips (as per the use of the words "based" and "systems").
Yes, one could do that, but one could also design and build one's own systems based on x86 chips, and a number of companies do that.
With PPC anyone can build them and sell them.
Yes, anyone could license PowerPC or Power Architecture or whatever IBM's calling the instruction set architecture these days, but I suspect most people building general-purpose computer systems based on PowerPC processors aren't building their own chips, so it's not clear that the fact that they could, in theory, do that is particularly relevant to the discussion that the original poster started.
Gee that's great, but we weren't talking about OS X systems, we were talking about PPC and x86.
Perhaps you were, but the original poster was talking about "Apple hardware", which isn't "PPC", it's systems one or two of the components of which are PowerPC processors and the other components of which are other chips, some custom from Apple and some from various vendors, and about "x86-based systems", which are't "x86", they're systems one or more of the components of which are x86 processors and the other components of which are other chips, custom or from various vendors.
Heh, x86 is proprietary and closed. Intel reverse engineered it.
Yeah, it must've taken them a lot of effort to reverse-engineer their own instruction set....
In Bizarro world "closed but popular" means "open" and "open, but not as popular" means "proprietary."
In the normal world, "x86-based systems" are "open" in the sense that anybody can build them (even if the x86 instruction set isn't explicitly licensed to anybody who wants it by the vendor), and Apple systems are "proprietary" in that there aren't multiple vendors of OS X-compatible systems. I suspect that by "there[sic] mostly proprietary hardware" the person to whom you're responding meant Apple's systems, not Motorola and IBM's microprocessors.
Just can't let somebody else have the last word, eh?
Better than than preemptively dismissing all last words as "semantics" when the person so dismissing all last words is also just debating the meaning of a particular term. If you don't like to be involved in debating something, don't get involved in those debates.
(You're wrong, by the way...)
"Wrong" about what?
Wrong that Apple lists Samba as part of Darwin? No, I'm right - see the link in my previous posting.
Wrong that Apple doesn't just repackage it? If so, are you saying that the OpenDirectory support in Samba was not developed at Apple? I wouldn't argue that they made a *huge* change (diffing the vanilla samba 3.0.5 source and the samba-59 source from Darwin doesn't show many changes), but that's not just repackaging.
I'm pretty sure you're plunging into semantics here.
As were you, when you asserted that Samba was "not part of Darwin".
But if you want to call software that the supplier of an operating system lists as part of their operating system, and that the supplier does more with than just repackage, not part of the operating system, I guess that just means that not everybody uses "part of" in the same fashion.
Samba is distributed along with Darwin. It's not part of Darwin.
What is the basis for that assertion? Apple appears, by including it on their page of Darwin projects (note: "project" just means "component"), to consider Samba to be part of Darwin.
No, there aren't, for licensing reasons. Linux is encumbered by the proprietary Gnu license, which Apple has rejected out of hand. There is no Gnu-licensed code in Darwin.
Most people will walk in to a store and see 75 shelves of PC software, and 2 shelves of Mac software. If OSX ran on x86, there's a much better chance that the PC software could run unported, unemulated on OSX.
If by "the PC software" you mean "software written for Windows" (and maybe DOS, if there's some DOS software still around), then there's not much chance that it'd run "unported, unemulated" on a hypothetical x86 OS X release, unless by "unemulated" you mean no emulation of the machine instruction set - OS X isn't going to run software that expects a Windows ABI without an emulator for the OS calls.
The X86-64 and to a lesser degree the IA-64 are "extensions" to the x86 ISA.
A much lesser degree, as in "the IA-64 'extension' to x86 is a completely separate instruction set which doesn't look anything like x86, unlike x86-64 which is clearly a descendant of x86".
The difference is, Apple "enforces" this user interface guideline by making it impossible for developers to rely on the existence of the right mouse button.
But, as Ctrl+button brings up context menus, they don't make it impossible for developers to rely on the availability of context menus. They do make it a bit more work to pop up a context menu, but that's a different matter.
Apple's point, their key design idea, is that contextual menus should always be optional. There should, ideally, never be a feature that's in the right-click menu that's not accessible other places.
Gee, that seems to be a Microsoft idea, too, although they don't say that context menu items should always be available as menu bar items:
Avoid using a shortcut menu as the only way for a user to access a particular operation. At the same time, the items on a shortcut menu need not be limited only to commands that are included in drop-down menus. For example, you can include frequently used commands typically found in a secondary window, such as a specific property setting.
ever provide a contextual menu command that is not also accessible through the menu bar. Commands with keyboard shortcuts should be noted in the menu bar menu but not in the contextual menu. Use submenus with caution and keep them to one level.
Since the user may not be aware of their presence, do not provide functions that are only accessible from popup menus unless you are confident that your target users will know how to use popup menus.
I don't think Apple wants to start making a Cocoa framework for Windows
And they especially wouldn't want to call it Yellow Box.
(I'm not sure whether it was ever released. The Wikipedia article on NeXT appears to be saying some beta releases might have been made before it disappeared.)
Because Mac OS X uses the netinfo database for a lot of config data, doing things like ifconfig by hand (even modifying the/etc/ files directly) can lead to inconsistent results.
By "use ifconfig" I meant "use ifconfig to report information about interfaces", not "use it to set interface information".
That's one of the places where OS X (and the NeXTStEP from which much of it comes) differs from other UN*Xes, although AIX might still outdo it in terms of "stuff gets configured differently here" (do you run similar risks doing this outside of SMIT?).
"Weird" is in the eye of the beholder. I find its ifconfig less weird than Linux's, for example,, but that's because I used BSD-derived versions of ifconfig, which is what most UN*Xes use.
I.e., for any given pair of UN*Xes X and Y, there's probably something in Y that users of X will find weird. You can substitute "Linux", "FreeBSD", "NetBSD", "OpenBSD", "DragonflyBSD", "Solaris", "AIX", "HP-UX", "OS X", etc. for "X" and "Y" - and you can probably even substitute particular Linux distributions for "X" *and* "Y" (e.g., "there's probably something in Slackware that users of Gentoo will find weird").
Personally, I think that if there's any purported flavor of UN*X that can't be substituted for "X" for any value of "Y" that corresponds to a flavor of UN*X other than the value being substituted for "X", that purported flavor of UN*X isn't actually a flavor of UN*X. I.e., an inherent part of being a UN*X is that it has to do something differently from all the other UN*Xes....:-)
Of course, you could be referring to the GUI rather than the UN*X layer, in which case the OS X GUI might be considered "more different" from the other major UN*X GUIs then those others are from each other - or maybe not; GNOME 2/GTK+ 2 seems to have lifted some of their feel from OS X, at least in recent versions (the GtkFileChooser looks a bit OS X-influenced).
I used to like Apple Mail but now I've gone off it, seeing as it is embedding unique identifying info into every email. Hope someone writes a patch to stop it doing that cause it sounds a lot like MS to me.
Note that neither Apple Mail nor the Microsoft apps were explicitly choosing to stick the MAC address of one of the network cards into {mail messages,documents} - they were sticking UUIDs into {mail messages,documents}, and the OS's routine for generating UUIDs was using the original DCE mechanism for generating UUIDs, which involves using a value expected to uniquely identify the machine at any given time (the MAC address) and time stamp information ("putting the 'U' into 'UUID'!").
And, yes, somebody wrote a patch to stop it doing that; the "somebody" is named "Apple Computer", and the patch can be found in something called they call "Security Update 2005-001", a/k/a "Apple's First 2005 Mac OS X Security Update", as it's called in the Slashdot article about said Security Update, as per Apple's document about that security update (search for "Component: Mail" in that article).
A GUI is, as far as I know, already available, although not from Apple. X.org's X server is available for Darwin, and XFree86 probably is as well, and KDE, GNOME, etc. and their corresponding toolkits probably work.
That's not the OS X GUI, however. That might not be released soon, if ever; only if Apple would be willing to act as a vendor of core GUI software for other people's hardware would that happen (and, even if that happens, that doesn't necessarily mean it'd be released as free software, as Apple might not be willing to act as a supplier of free-as-in-beer core GUI software for other people's hardware, although there might be ways of making it free-as-in-speech without being completely free-as-in-beer, e.g. releasing it under a dual license, GPL plus a license that lets non-GPLed software use the GUI libraries, with a version licensed under the second license requiring a license fee - that's a bit similar to the way Qt is licensed, although it's not the same, and I don't know whether it'd work).
Darwin is very rudimentary when compared to OS X.
Umm, yeah, that was sort of my point in the message to which you responded....
Not a bug a feature... to generate message Ids that are traceable back to originating machine...
Not a feature an idea that perhaps seemed OK at the time... to generate unique message IDs based on an existing type of unique identifier that happened, in the original format defined for it, to use an IEEE 802 MAC address, presumably because those are intended to be unique to a piece of hardware, so the rest of the UUID merely has to be a value that will never be used again on a system where that MAC address is used to generate UUIDs.
The current Internet-Draft for a URN namespace for UUIDs mentions another scheme to generate UUIDs in that format that don't use a hardware MAC address but that won't collide with UUIDs generated from MAC addresses for hardware (by turning on the bit that would be the multicast bit in an 802 MAC address).
On a side note, look at the possibilities, if two terrorists were having a conversation, Google could suggest cheap arms depots.
Exactly - Google Ads in the empty spaces in your phone conversations. (I think there was a company in Sweden, a few years ago, that offered free phone service with an ad when you picked up the phone to make a call.)
Of course, Google Ads aren't always relevant, given that words can be used in more than one context; you stand a good chance of getting an ad for a laxative full of fib{er,re} when you go to the Ethereal FAQ, courtesy of the list of supported protocols containing the phrase "Fibre Channel" - no guarantees you'll get an Herbal Fiberblend ad, but they do pop up quite often. (The fact that it's called "AIM Herbal Fiberblend" might help, given that AIM is also mentioned in that list.)
Slashdot Mirror
Or, to put it another way, if they don't do things this way, that's a bug, not a feature.
"Them" here, of course, referring to Intel's x86-based systems, such as their blade servers, rather than to their chips, as "x86-based systems" refers not to x86 chips, but to systems based on those chips (as per the use of the words "based" and "systems").
Yes, one could do that, but one could also design and build one's own systems based on x86 chips, and a number of companies do that.
Yes, anyone could license PowerPC or Power Architecture or whatever IBM's calling the instruction set architecture these days, but I suspect most people building general-purpose computer systems based on PowerPC processors aren't building their own chips, so it's not clear that the fact that they could, in theory, do that is particularly relevant to the discussion that the original poster started.
Perhaps you were, but the original poster was talking about "Apple hardware", which isn't "PPC", it's systems one or two of the components of which are PowerPC processors and the other components of which are other chips, some custom from Apple and some from various vendors, and about "x86-based systems", which are't "x86", they're systems one or more of the components of which are x86 processors and the other components of which are other chips, custom or from various vendors.
Yeah, it must've taken them a lot of effort to reverse-engineer their own instruction set....
In the normal world, "x86-based systems" are "open" in the sense that anybody can build them (even if the x86 instruction set isn't explicitly licensed to anybody who wants it by the vendor), and Apple systems are "proprietary" in that there aren't multiple vendors of OS X-compatible systems. I suspect that by "there[sic] mostly proprietary hardware" the person to whom you're responding meant Apple's systems, not Motorola and IBM's microprocessors.
Nope, it's Computer Hardware Understanding Development. I'm sure nobody at Apple had any thoughts of alluding to a movie about Cannibalistic Humanoid Underground Dwellers when naming CHUD, nope nope nope....
Better than than preemptively dismissing all last words as "semantics" when the person so dismissing all last words is also just debating the meaning of a particular term. If you don't like to be involved in debating something, don't get involved in those debates.
"Wrong" about what?
Wrong that Apple lists Samba as part of Darwin? No, I'm right - see the link in my previous posting.
Wrong that Apple doesn't just repackage it? If so, are you saying that the OpenDirectory support in Samba was not developed at Apple? I wouldn't argue that they made a *huge* change (diffing the vanilla samba 3.0.5 source and the samba-59 source from Darwin doesn't show many changes), but that's not just repackaging.
As were you, when you asserted that Samba was "not part of Darwin".
But if you want to call software that the supplier of an operating system lists as part of their operating system, and that the supplier does more with than just repackage, not part of the operating system, I guess that just means that not everybody uses "part of" in the same fashion.
What is the basis for that assertion? Apple appears, by including it on their page of Darwin projects (note: "project" just means "component"), to consider Samba to be part of Darwin.
There is GPLed code in Darwin; Samba is part of Darwin, for example.
There's no GNU-licensed code in the Darwin kernel, so, no, there's no Linux code in the Darwin kernel.
Well, if I regularly used Windows, I might see it every time I ran the QuickTime player or iTunes if I'd downloaded them.
Why does that link bring to mind the name Natalie Portman?
If by "the PC software" you mean "software written for Windows" (and maybe DOS, if there's some DOS software still around), then there's not much chance that it'd run "unported, unemulated" on a hypothetical x86 OS X release, unless by "unemulated" you mean no emulation of the machine instruction set - OS X isn't going to run software that expects a Windows ABI without an emulator for the OS calls.
A much lesser degree, as in "the IA-64 'extension' to x86 is a completely separate instruction set which doesn't look anything like x86, unlike x86-64 which is clearly a descendant of x86".
But, as Ctrl+button brings up context menus, they don't make it impossible for developers to rely on the availability of context menus. They do make it a bit more work to pop up a context menu, but that's a different matter.
Gee, that seems to be a Microsoft idea, too, although they don't say that context menu items should always be available as menu bar items:
as Apple does in the Apple Human Interface Guidelines:
The GNOME Human Interface Guidelines are somewhat less emphatic:
The KDE User Interface Guidelines don't have anything obvious on context/popup/shortcut menus.
And they especially wouldn't want to call it Yellow Box.
(I'm not sure whether it was ever released. The Wikipedia article on NeXT appears to be saying some beta releases might have been made before it disappeared.)
The game consoles ate 2005? That's sad - I was hoping it'd be a decent year.
But what's the deal with the "3" at the end of "ate"? Is that some sort of 'leet-speak or something?
By "use ifconfig" I meant "use ifconfig to report information about interfaces", not "use it to set interface information".
That's one of the places where OS X (and the NeXTStEP from which much of it comes) differs from other UN*Xes, although AIX might still outdo it in terms of "stuff gets configured differently here" (do you run similar risks doing this outside of SMIT?).
"Weird" is in the eye of the beholder. I find its ifconfig less weird than Linux's, for example,, but that's because I used BSD-derived versions of ifconfig, which is what most UN*Xes use.
I.e., for any given pair of UN*Xes X and Y, there's probably something in Y that users of X will find weird. You can substitute "Linux", "FreeBSD", "NetBSD", "OpenBSD", "DragonflyBSD", "Solaris", "AIX", "HP-UX", "OS X", etc. for "X" and "Y" - and you can probably even substitute particular Linux distributions for "X" *and* "Y" (e.g., "there's probably something in Slackware that users of Gentoo will find weird").
Personally, I think that if there's any purported flavor of UN*X that can't be substituted for "X" for any value of "Y" that corresponds to a flavor of UN*X other than the value being substituted for "X", that purported flavor of UN*X isn't actually a flavor of UN*X. I.e., an inherent part of being a UN*X is that it has to do something differently from all the other UN*Xes.... :-)
Of course, you could be referring to the GUI rather than the UN*X layer, in which case the OS X GUI might be considered "more different" from the other major UN*X GUIs then those others are from each other - or maybe not; GNOME 2/GTK+ 2 seems to have lifted some of their feel from OS X, at least in recent versions (the GtkFileChooser looks a bit OS X-influenced).
I guess they didn't bother doing the obvious Google search that reveals (as the word "timetable" in the directions suggests) that there are, indeed, ferries between Haugesund and Newcastle-upon-Tyne.
But I guess that'd mean the boys at The Reg couldn't write an article entitled "Is Microsoft preparing a flying car?".
Note that neither Apple Mail nor the Microsoft apps were explicitly choosing to stick the MAC address of one of the network cards into {mail messages,documents} - they were sticking UUIDs into {mail messages,documents}, and the OS's routine for generating UUIDs was using the original DCE mechanism for generating UUIDs, which involves using a value expected to uniquely identify the machine at any given time (the MAC address) and time stamp information ("putting the 'U' into 'UUID'!").
And, yes, somebody wrote a patch to stop it doing that; the "somebody" is named "Apple Computer", and the patch can be found in something called they call "Security Update 2005-001", a/k/a "Apple's First 2005 Mac OS X Security Update", as it's called in the Slashdot article about said Security Update, as per Apple's document about that security update (search for "Component: Mail" in that article).
A GUI, or the Mac OS X GUI?
A GUI is, as far as I know, already available, although not from Apple. X.org's X server is available for Darwin, and XFree86 probably is as well, and KDE, GNOME, etc. and their corresponding toolkits probably work.
That's not the OS X GUI, however. That might not be released soon, if ever; only if Apple would be willing to act as a vendor of core GUI software for other people's hardware would that happen (and, even if that happens, that doesn't necessarily mean it'd be released as free software, as Apple might not be willing to act as a supplier of free-as-in-beer core GUI software for other people's hardware, although there might be ways of making it free-as-in-speech without being completely free-as-in-beer, e.g. releasing it under a dual license, GPL plus a license that lets non-GPLed software use the GUI libraries, with a version licensed under the second license requiring a license fee - that's a bit similar to the way Qt is licensed, although it's not the same, and I don't know whether it'd work).
Umm, yeah, that was sort of my point in the message to which you responded....
Not a feature an idea that perhaps seemed OK at the time... to generate unique message IDs based on an existing type of unique identifier that happened, in the original format defined for it, to use an IEEE 802 MAC address, presumably because those are intended to be unique to a piece of hardware, so the rest of the UUID merely has to be a value that will never be used again on a system where that MAC address is used to generate UUIDs.
The current Internet-Draft for a URN namespace for UUIDs mentions another scheme to generate UUIDs in that format that don't use a hardware MAC address but that won't collide with UUIDs generated from MAC addresses for hardware (by turning on the bit that would be the multicast bit in an 802 MAC address).
And which component of Darwin includes, for example, the Finder?
Don't confuse "Darwin" with "OS X". The latter includes the former, but the former doesn't contain all of the latter.
Exactly - Google Ads in the empty spaces in your phone conversations. (I think there was a company in Sweden, a few years ago, that offered free phone service with an ad when you picked up the phone to make a call.)
Of course, Google Ads aren't always relevant, given that words can be used in more than one context; you stand a good chance of getting an ad for a laxative full of fib{er,re} when you go to the Ethereal FAQ, courtesy of the list of supported protocols containing the phrase "Fibre Channel" - no guarantees you'll get an Herbal Fiberblend ad, but they do pop up quite often. (The fact that it's called "AIM Herbal Fiberblend" might help, given that AIM is also mentioned in that list.)
Or, to fix the URL, that's GNUstep.