translates to the problems of trying to run all the third-party code being, which are harder if you don't just get to recompile, being "easily" solved.
You know, dude, that's a lot easier to read if you write it as
translates to the problems of trying to run all the third-party code being "easily" solved; those are harder if you don't just get to recompile,
Maybe you are a genius but I've personally written some code that didn't port between machines because of subtle byteorder problems.
Networking code in OS X either tends to come from various BSDs (which run on processors of both byte orders and, if they run predominantly on any byte order, predominantly run on little-endian machines) or is written by people with sufficient clue not to have byte order problems.
And, having worked at companies whose networking code works on both byte orders, I can testify that it doesn't require a "genius" to get it right (although, having fixed some annoying byte-order issues in Ethereal dissectors, I guess it requires more than "hey, it worked on my PC running {Linux,Windows}", the former of which all too often is, I suspect, the "smoke test" for free software).
Maybe app writers have invented their own protocols and implemented them sloppily, so maybe those would break on a hypothetical little-endian OS X box, but app writers whose code also runs on Windows might at least stand a chance of getting it right.
Apple is the first letter in AIM. Is there any reason they couldn't license the architecture to Intel?
The fact that the architecture is primarily the invention of the second letter in "AIM", so, if anybody gets to license the architecture, it's probably IBM? I don't know whether power.org or IBM or... "owns" the various flavors of POWER-based architectures, but I suspect Apple can't unilaterally grant somebody else a license if it requires a license.
In addition, CNET's main answer to the insane technical issues that this would involve is, "Steve Jobs said it would work."
No, they said "And Jobs has said Mac OS X could easily run on x86 chips." Perhaps they're deeply confused (computer journalists deeply confused? What a shock!) and think Jobs meant that "OS X could easily run on x86 chips", at the technical level (none of the issues there are particularly "insane" - look at the pile of processors on which Linux distributions and various BSDs run, and look at Solaris running on SPARC and x86), translates to the problems of trying to run all the third-party code being, which are harder if you don't just get to recompile, being "easily" solved.
To which wire protocols are you referring? (Hint: the answer is probably not "AppleTalk File Protocol", as netatalk works just fine, as far as I know, on x86 boxes. It's not "SMB", as there are plenty of Mac and SPARC boxes and... running Samba and, in the case of Macs and various BSD and Linux boxes, running various smbfs clients. It's not "NFS", as that's worked for ages on big-endian 68k/SPARC/etc. machines and little-endian x86/Alpha/etc. machines. And it's definitely not Ethernet, or IPv4, or IPv6, or TCP, or UDP, as those have worked between big-endian and little-endian machines for a long time. Hell, some of those have worked between 36-bit machines with 7-bit or 9-bit bytes and Boring Old 8-Bit Byte Machines.)
The on-disk formats might have a problem, but even those aren't necessarily insuperable, although that might require that applications be changed not to assume that files are in the "native" byte order.)
If OSX's has big threading disadvantages because of it's similarity to BSD4
It's not. OS X's threading model is not at all similar to FreeBSD 4.x's all-in-userland threading; the authors of the article were deeply confused on that point.
Another thing is I've used the Mach api and it shows different Mach thread ids for the Posix threads I create with PTHREAD_SCOPE_SYSTEM so I'm a little mystified as to why they claim only one Mach thread is being used.
Perhaps because their claim is not based on fact, but based on, apparently, a complete misunderstanding of what "POSIX threads (pthreads) are layered on top of Mach threads" (to quote the Apple technote whence they got that threads architecture diagram) means? (Hint to the authors: it does not mean "all the pthreads in a process are implemented in userland inside a single schedulable entity, so only one can be running at a time".)
If your application is having its performance destroyed by a 2-5x multiplier in thread creation time, this application is not written very well.
And if your benchmark is measuring how long it takes to do a fork or a fork/exec pair, rather than how long it takes to do a pthread_create(), your benchmark isn't particularly appropriate as a measurement of thread creation time if "thread" means "pthread" as appears to be the case on the previous page of the Anandtech article.
And if the application being tested is using processes rather than pthreads, your Anandtech article shouldn't go on about pthreads (much less doing so in a way that says OS X uses "slower user-level threads" rather than "fast kernel threads" when the Apple tech note from which they took their diagram says "POSIX threads (pthreads) are layered on top of Mach threads", i.e. for each POSIX thread there is a Mach kernel thread).
("You" here of course meaning "the people writing the article", not "the person I'm replying to".)
I know this is meant to be a joke, but there already is a Canadian layout. It is different from the US layout, because it has accent keys and some other nicities. It's called the Canadian Multi-lingual Standard, or CSA (Canadian Standards Association) keyboard.
And it's not new in Tiger; it's in Panther, or, at least, a layout with the Canadian flag and "CSA" below it is.
We'll lend you ours if you want to see what English actually looks like.
If somebody wants to know what English actually looks like, they'll have to try an English dictionary, wherein the word for the round rubber things on automobile wheels is spelled "tyre" rather than "tire".
But, still, the language you speak up there is closer to English than is the language we speak down here, at least in the way it's spelled^Wspelt....
You might want to get network traces of the attempt to connect from the Tiger machine, and from the Panther machine, and tell Apple to open a bug and add those network traces to the bug report. (If you do the trace with tcpdump, use the flag "-s 0", as well as using "-w" with the name of the file to which to send it.)
In our office we have four machines: A Debian Sarge Box, two Win XP boxes and a current Al Powerbook (running tiger). The tiger running machine can connect to both the WinXP boxes fine, but the Debian box, which under 10.3 was used every day, no longer talks to the Powerbook.
No longer talks to the PowerBook with the Debian box being the SMB server, or no longer talks to the PowerBook with the PowerBook as the SMB server (e.g., using Linux smbfs or cifsfs)?
If the Debian box is the server, do you have encrypted passwords enabled? If not, try enabling them (which, apparently, also makes it easier to connect to the server from W98 and later, and NT4SP3 and later, according to some Microsoft knowledge base items, as they made those OSes not, by default, connect to servers that don't support encrypted passwords, requiring you to tweak a flag in the registry to support it).
eventhough CIFS/SMB is often a transport for carryiung DCE/RPC on older windows boxens, moderns ones transport DCE/RPC over raw TCP
Actually, I suspect Windows NT has always done DCE RPC over raw TCP (and probably raw UDP), and I think for SMB-related services they might still do DCE RPC over SMB by default (or perhaps do DCE RPC only over SMB - do they make SRVSVC available over raw TCP, and, if so, do newer versions of the Windows SMB client code use that to enumerate shares or do they still do that via DCE RPC over the SMB connection to the server?).
WARNING: Enabling this will allow unencrypted (plain text) passwords to be sent across the network when authenticating to an SMB server that requests this option. This can lessen the overall security of an environment and should only be done after careful consideration of the consequences of plain text passwords in your specific environment.
As I understand it, the stuff that broke networking on a lot of applications are fundamental changes in Tiger's APIs that can't be fixed without going back to the old (Panther) way.
And some of those changes might be...
The good news is that one of the big things about Tiger is that Apple has supposedly reached a point where they're done making changes to the APIs that break things.
...the result of the introduction of the "sustainable" kernel interfaces. It sounds as if that might be part of what the Ars Technica article is referring to - interfaces that kernel extensions can use and that won't change in future releases in ways that break things, even if the implementation of those interfaces changes.
Slashdot Mirror
You know, dude, that's a lot easier to read if you write it as
Which Darwin project is it that has the Airport Extreme driver? :-)
Besides, it's not as if apps talk to the raw hardware a lot; they generally go through drivers, supplied by Apple in the case of Apple hardware.
You mean like "implement a 99 44/100%-compatible version of x86-64"?
Networking code in OS X either tends to come from various BSDs (which run on processors of both byte orders and, if they run predominantly on any byte order, predominantly run on little-endian machines) or is written by people with sufficient clue not to have byte order problems.
And, having worked at companies whose networking code works on both byte orders, I can testify that it doesn't require a "genius" to get it right (although, having fixed some annoying byte-order issues in Ethereal dissectors, I guess it requires more than "hey, it worked on my PC running {Linux,Windows}", the former of which all too often is, I suspect, the "smoke test" for free software).
Maybe app writers have invented their own protocols and implemented them sloppily, so maybe those would break on a hypothetical little-endian OS X box, but app writers whose code also runs on Windows might at least stand a chance of getting it right.
The fact that the architecture is primarily the invention of the second letter in "AIM", so, if anybody gets to license the architecture, it's probably IBM? I don't know whether power.org or IBM or... "owns" the various flavors of POWER-based architectures, but I suspect Apple can't unilaterally grant somebody else a license if it requires a license.
OK, so what's ASOT's secret (other than an office in an important part of 1 Infinite Loop :-))?
No, they said "And Jobs has said Mac OS X could easily run on x86 chips." Perhaps they're deeply confused (computer journalists deeply confused? What a shock!) and think Jobs meant that "OS X could easily run on x86 chips", at the technical level (none of the issues there are particularly "insane" - look at the pile of processors on which Linux distributions and various BSDs run, and look at Solaris running on SPARC and x86), translates to the problems of trying to run all the third-party code being, which are harder if you don't just get to recompile, being "easily" solved.
To which wire protocols are you referring? (Hint: the answer is probably not "AppleTalk File Protocol", as netatalk works just fine, as far as I know, on x86 boxes. It's not "SMB", as there are plenty of Mac and SPARC boxes and... running Samba and, in the case of Macs and various BSD and Linux boxes, running various smbfs clients. It's not "NFS", as that's worked for ages on big-endian 68k/SPARC/etc. machines and little-endian x86/Alpha/etc. machines. And it's definitely not Ethernet, or IPv4, or IPv6, or TCP, or UDP, as those have worked between big-endian and little-endian machines for a long time. Hell, some of those have worked between 36-bit machines with 7-bit or 9-bit bytes and Boring Old 8-Bit Byte Machines.)
The on-disk formats might have a problem, but even those aren't necessarily insuperable, although that might require that applications be changed not to assume that files are in the "native" byte order.)
It's not. OS X's threading model is not at all similar to FreeBSD 4.x's all-in-userland threading; the authors of the article were deeply confused on that point.
Perhaps because their claim is not based on fact, but based on, apparently, a complete misunderstanding of what "POSIX threads (pthreads) are layered on top of Mach threads" (to quote the Apple technote whence they got that threads architecture diagram) means? (Hint to the authors: it does not mean "all the pthreads in a process are implemented in userland inside a single schedulable entity, so only one can be running at a time".)
And if your benchmark is measuring how long it takes to do a fork or a fork/exec pair, rather than how long it takes to do a pthread_create(), your benchmark isn't particularly appropriate as a measurement of thread creation time if "thread" means "pthread" as appears to be the case on the previous page of the Anandtech article.
And if the application being tested is using processes rather than pthreads, your Anandtech article shouldn't go on about pthreads (much less doing so in a way that says OS X uses "slower user-level threads" rather than "fast kernel threads" when the Apple tech note from which they took their diagram says "POSIX threads (pthreads) are layered on top of Mach threads", i.e. for each POSIX thread there is a Mach kernel thread).
("You" here of course meaning "the people writing the article", not "the person I'm replying to".)
...and that they make non-x86 processors.
I don't - the Sharks are a bit closer to Cupertino than are the Mighty Ducks.
And it's not new in Tiger; it's in Panther, or, at least, a layout with the Canadian flag and "CSA" below it is.
If somebody wants to know what English actually looks like, they'll have to try an English dictionary, wherein the word for the round rubber things on automobile wheels is spelled "tyre" rather than "tire".
But, still, the language you speak up there is closer to English than is the language we speak down here, at least in the way it's spelled^Wspelt....
Is Samba on the Debian box configured to support encrypted passwords?
If not, either enable encrypted passwords (as per another reply - note that Microsoft changed Windows in Windows 98 and in NT 4.0 SP3 to, by default, reject attempts to connect to servers that don't support encrypted passwords), or configure OS X's SMB client to allow connections to servers that don't support encrypted passwords.
You might want to get network traces of the attempt to connect from the Tiger machine, and from the Panther machine, and tell Apple to open a bug and add those network traces to the bug report. (If you do the trace with tcpdump, use the flag "-s 0", as well as using "-w" with the name of the file to which to send it.)
It's documented in the man page on my Panther box:
No longer talks to the PowerBook with the Debian box being the SMB server, or no longer talks to the PowerBook with the PowerBook as the SMB server (e.g., using Linux smbfs or cifsfs)?
If the Debian box is the server, do you have encrypted passwords enabled? If not, try enabling them (which, apparently, also makes it easier to connect to the server from W98 and later, and NT4SP3 and later, according to some Microsoft knowledge base items, as they made those OSes not, by default, connect to servers that don't support encrypted passwords, requiring you to tweak a flag in the registry to support it).
Actually, I suspect Windows NT has always done DCE RPC over raw TCP (and probably raw UDP), and I think for SMB-related services they might still do DCE RPC over SMB by default (or perhaps do DCE RPC only over SMB - do they make SRVSVC available over raw TCP, and, if so, do newer versions of the Windows SMB client code use that to enumerate shares or do they still do that via DCE RPC over the SMB connection to the server?).
Encrypted session, or packet signing?
Recent versions of the FreeBSD smbfs (client VFS) do packet signing, so that might have been reverse-engineered, at least on the client side.
If you have to turn packet signing off on the server to connect from Tiger, presumably Tiger hasn't picked that up.
Note that Microsoft changed the "Windows OT" (95,98,Me) line in W98 and changed the "Windows NT" (NT 3.x, NT 4.0, W2K, WXP, WServer2K3) line in NT 4.0 SP3 so that, by default, they refuse to connect to servers that don't do encrypted passwords. There's a Registry entry you have to change to enable that - but they warn you that this means you're sending your password over the wire in a form that anybody capturing network traffic can see:
SMB server, yes.
SMB client, no. The SMB client was originally based on the FreeBSD smbfs, but has had a lot of additional work done.
And some of those changes might be...
...the result of the introduction of the "sustainable" kernel interfaces. It sounds as if that might be part of what the Ars Technica article is referring to - interfaces that kernel extensions can use and that won't change in future releases in ways that break things, even if the implementation of those interfaces changes.
I think he means he installed it on Cats.