I think the main reason the bus on current Macs is so slow, is simply that the Motorola's PPC's can't handle higher clocked FSB's, not because Apple can't design them. If you look at the PPC specs on Motorola's site, you'll see that they don't even mention 167MHz as a possible FSB speed (which Apple uses nevertheless in the high-end PowerMacs), the PPC 7450 supposedly only supports up to 133MHz.
I really don't understand it. On bnoth my G4 400 and my iBook 800, the menus appear instantly (at least the second time and onwards, the first time there is indeed sometimes a small delay, but it's by no means even near a full second).
I can see how someone might not consider it "noticable" if they are used to the general unresponsiveness of OS X's GUI. However, I just walked around here and tried it on a half dozen different machine (Beige G3/233, iMac DV/500, PowerBook 667 Rev B, G4/500, Dual 1GHz Xserve, 700MHz iBook) and they _all_ had a delay of about a second before displaying the menu
Make sure you ctrl-click or right-click on the icons. If you click normally, then there is indeed a delay of about one second.
it was effectively equivalent to what Java does, with bytecode being interpreted on the fly
That's also emulation. Whether you emulate only a processor (aka instruction set architecture) or a complete system with peripherals etc is irrelevant, it's all emulation.
The fact that you have a 64 bit processor doesn't mean that all instructions become twice as big. For example, the 64bit PowerPC's instructions are all 32 bit, just like those of the 32bit PowerPC's. That's also the reason why 64bit PPC's don't take a hit when executing 32bit code: their (user level) instruction set is exactly the same as those of the 32bit PPC's, they just have some extra instructions for 64bit-specific operations (mainly load/store and shift operations).
In case you're wondering about constants: the PPC only supports loads of 16bit immediate values (both in the lower and upper 16bits of the lower 32bits of a register), so to load a 64bit value you may have to perform up to 5 operations (two loads, a shift and two more loads). So a PPC requires up to 64bits for a 32bit immediate load and up to 160bits to load a 64bit value (unless you store such a value in a memory location that can be addressed in a faster way). These are worst cases however, and in a lot of cases 1 or maybe two instructions is enough.
The main downside of 64bit code is that all pointers become 64bit, so all pointer loads and stores indeed require twice as much storage and bandwidth.
Actually, the only change in the 0.2.1 release is that the default install also installs the config package I was talking about. This config package indeed includes a.xinitrc which executes quartz-wm. If you don't install the config package, you simply get no.xinitrc (or you keep your existing.xinitrc if you already had one), which results in X starting twm.
In fact, getting rid of message passing doesn't give you anything from both worlds, it gives you a monolithic kernel, plain and simple.
Fortunately, that's not true. I would suggest you to read this and this message posted quite a while ago on the darwin-development mailing list (use archives as both login and password).
It's called sarcasm. I guess if you don't like what anyone has to say, you just call it a troll so that you don't have to deal with it.
I did reply to your post and I did address the "points" that you made. I suppose this was more sarcasm I didn't get...
In other words, a microkernel can't be brought down by one single part.
The great thing about microkernels is that a flaw in the TCP/IP stack won't result in an exploit or a DoS on the kernel. So Apple took a microkernel, then removed all the features that make a microkernel a good thing.
I talked exactly about this in the last paragraph of my original post. Maybe you should spend more time actually reading the post and less time thinking up "sarcastic"responses.
Actually the fact that they are running BSD + Mach [the XNU components] in the same address space is a speed optimization to reduce context switching for every message from BSD to Mach. This isn't a cause of slowness but a reduction.
I never claimed this slowed things down, in fact I said:
It's quite possible that the Darwin kernel is slower than that of the other BSD's, but that won't be due to its message passing microarchitecture. The reason is that the Darwin kernel runs in one address space (even both the Mach and BSD personalities run the same address space).
Now that I read that again, I see how you could interpret it different from what I meant. I wanted to say that although maybe the Darwin kernel is slower than other BSD kernels, message passing [in the kernel] won't be the cause of that, since the whole kernel now runs in one address space (even the Mach and BSD personalities, so even for communication between those two you don't need messages).
The message passing stuff still exists and is still useful [while it may not be used in the kernel space... I haven't verified this yet.]
Yes, I meant they removed it for in-kernel communication. It's indeed possible that it's still used here and there for in-kernel stuff, but the whole communication architecture of the kernel doesn't completely rely on it anymore as in the original Mach. I agree this wasn't really clear from my original message.
oohoo!!! Why didn't I think of that??? Just rip out message passing!
I know you're just trolling, but for other peolpe that might be interested: in the original Mach kernel, every subsystem of the kernel talks to the rest by using message passing (which is obviously quite slow, but otoh allows you to keep every subsystem in its own address space). Apple changed this so that every subsystem lies in the same address space, so they don't have to use the slow message passing interface, but can use function calls instead to let different parts of the kernel communicate.
Obviously, the message passing interface is still there and e.g. can still be used to have kernel space code communicate with userland code.
Although I agree that Darwin-x86 is only really useful if you want to do Darwin development or use it as a netinfo server, you are wrong about the microkernel piece. It's quite possible that the Darwin kernel is slower than that of the other BSD's, but that won't be due to its message passing microarchitecture. The reason is that the Darwin kernel runs in one address space (even both the Mach and BSD personalities run the same address space).
Apple didn't just pick up the Mach kernel and used it, they improved it a lot and one of the things they did was to rip out all that message passing stuff, while still retaining the modular design of the kernel. The result is that they more or less get the best of both worlds: a modular design with the speed of a monolithic kernel. Of course they did lose the ability of a true microkernel where the whole kernel doesn't crash if one of its modules does.
Backside cache does not increase the speed of a hard drive at all. Backside cache sits between main memory and the cpu, not between the HD and main memory. You're right it does a lot for the overall system speed (since the processor has to wait less for new data to arrive from main memory), but it doesn't make the hard drive any faster (e.g. duplicating a file or swapping won't be sped up significantly).
I've got an iBook 12"/800MHz and it runs OS X quite well (it's quite a bit faster than my old G4/400 desktop). It's true that the HD of the iBook isn't the fastest (I haven't really benchmarked it, but it seems like it's limited to something lik 20MB/sec read and 8-10MB/sec write speed), but that's not really due to the 4200 rpm speed: the Powerbooks also have 4200 rpm drives, but they're quite a bit faster (also faster that the previous generation's Powerbook drives, some of which did run at 5400 rpm). The reason is that the more expensive notebook drives have a higher data density, so they don't have to rotate as fast to get decent transfer speeds. Access time will still be slightly higher of course.
Regarding the heat issue: I've read in a comment on macnn.com that maybe it's only the stock combo-drive models that may have a heat issue. The reason would be the hard drive: the 40GB version in those models is supposedly slightly taller than the 60GB version in the superdrive model, thus restricting airflow and increasing heat build-up.
It mounts fine here. If it has a weird name after downloading (something like nph-.hqx), rename it to X11.dmg and try again. If it is really called X11.dmg, try dragging it over Stuffit Expander to see whether it's maybe still encoded.
Apart from the arguments of the other people that replied already, there's also the issue that Apple doesn't own the rights to all technologies used in Mac OS 9 (e.g. all powstscript-related stuff).
I'm just going to correct a few factual mistakes in your communist-capitalist ramblings (it seems to me that you're simply very scared to be found out as someone who possibly might stand behind some communist ideals, even though I agree the parent was overdoing it):
If Apple's hardware was competitive, they could compete without having to force hardware upgrades to run Jaguar
Jaguar is actually faster and leaner than all previous Mac OS X versions and runs on all hardware configurations supported by Mac OS X 10.1 and earlier. If you're thinking of Quartz Extreme (which requires an AGP Radeon+/Geforce2MX+ with 16+MB of VRAM to work):
Jaguar runs fine without it (and is still faster than Mac OS X 10.1.5 graphics-wise)
the reason it's not supported on lower-end graphics cards is because they don't have the hardware necessary to support its implementation (they have to support textures with a size tht's not a power of 2)
Complaining about Quartz Extreme is the same as complaining about Altivec optimizations (since they don't help for G3's). It's just an extra fgeature that takes advantage of the extra hardware you have and which is otherwise just sitting idle.
Not making Quicktime for Linux is communist
Not making Quicktime for Linux is having not enough resources to put into such an enormous undertaking. What enormous undertaking you ask? Well, Quicktime for Windows is not just a couple of audio and video codecs and some glue code, but a port of half the Mac OS toolbox to win32 (so they could keep the Quicktime source more or less the same for both platforms).
I've read a couple of times in the past on the mac-games-dev list hosted at Apple, that developers considering to port their (small-scale) game from Mac to Windows were encouraged by other developers to simply require QTfW, since then they wouldn't have to change their code that much (nor really learn the win32 API in-depth).
So you see, porting Quicktime to Linux would mean porting that age-old toolbox stuff over to Linux. And no, they haven't already don't a *nix port for Mac OS X, since there they use Carbon (which is based on the old toolbox API). Given that the ROI would be quite small (who's gonna upgrade to Quicktime Pro for $29,95? What Linux pro-video app creators for Linux will go into a Quicktime-pro bundling deal with Apple?), I think they don't do it simply because it doesn't make any business sense.
File format lock-in (like Quicktime) is communist, because it's a barrier to competition.
As must have been mentioned already thousands of times on slashdot, the Quicktime fileformat is completely open. It's the codecs that are proprietary and whose unavailability causes so much grief (although the latest versions of vlc and mplayer can play pretty much everything you can throw at them, making this less of an issue)
Taking from BSD and giving nothing (or nearly nothing) back is communist
They indeed (afaik at least) haven't given much back too Free/Open/NetBSD, but used a whole bunch of apps and libraries supported by those distributions. But why would that be? Maybe because they also didn't change anything to those apps and libraries? The changes that they did do, have been submitted back and those that were rejected are still available via Darwin cvs.
I mean, what should they do according to you? Give all BSD distro's a penny per line of source code that they used? Do you think that's what those distro's want? I doubt it. In general, what an open source project wants is that its stuff gets used, improved/bug fixed if necessary and that they get recognition for it. I don't see where Apple failed.
Apart from that, there's of course the obligatory mention of Apple's work on gcc (which is used by pretty much every open source OS out there, including the BSD's), resulting in (on average) 30% faster code generation for the PowerPC in version 3.x, altivec intrinsics and obj-c++ support. Yes, they were required to make their changes to gcc public since it's GPL, but
they were never forced to use gcc (they could've also take MrC, which still generates much better code than gcc)
they were also never forced to actively submit patches to the FSF, rework them when they're rejected and submit them again etc
There's of course also all the open source projects that they started and maintain themselves, such as the Darwin Streaming server (which not only streams Quicktime files, but also mp3 and mp4's), OpenPlay, Rendezvous,... and improvements to/support for other open frameworks such as cups and khtml.
It's of course obvious that Apple doesn't do all those things simply because it loves open source and wants to support us hackers. It does those things because it makes sense for them (in case of choosing gcc instead of MrC, that's because MrC's C++ support was quite mediocre; with the submitting of patches it's because otherwise they have to remerge all their patches with every new release, while now the FSF maintainers make sure that the accepted patches are maintained).
All the ranting about Apple being communist, capitalist and/or corporatist aside, I think it's clear that Apple currently tries to do as much things as possible in such a way that it's both good for itself and the open source community. Yes, when there are big trade-offs, it's the open source camp that "loses" (but that's logical, Apple is still a company and if it doesn't make such decisions, there will simply be no Apple anymore in a couple of years).
Well, that's enough ranting in an old thread for today <g>
NetSprockets is indeed deprecated/abandoned, but OpenPlay is not (it's the successor). CDSA is Intel's (yes, that Intel) security specification of which Apple made an implementation (which is much better than the reference implementation that Intel provides, from what I've heard) and then open sourced it.
No, for the same reason that 2^40 + 2^128 != 2^168. You're not combining the keys, you're just using them after eachother. In the end, the 40 bits DES encryption doesn't even really matter, since the 128 AES key dwarfs its complexity (like in efficiency analysis, O(n) + O(n^2) = O(n^2)).
Slashdot Mirror
I think the main reason the bus on current Macs is so slow, is simply that the Motorola's PPC's can't handle higher clocked FSB's, not because Apple can't design them. If you look at the PPC specs on Motorola's site, you'll see that they don't even mention 167MHz as a possible FSB speed (which Apple uses nevertheless in the high-end PowerMacs), the PPC 7450 supposedly only supports up to 133MHz.
I really don't understand it. On bnoth my G4 400 and my iBook 800, the menus appear instantly (at least the second time and onwards, the first time there is indeed sometimes a small delay, but it's by no means even near a full second).
This may be possible in some cases, but not all. For example, the rc5 algorithm specifically operates on 32bit quantities.
Power != PowerPC. There is also a PowerPC 64bit ISA and that one is the same as the 32bit PPC ISA + some 64bit extensions.
In case you're wondering about constants: the PPC only supports loads of 16bit immediate values (both in the lower and upper 16bits of the lower 32bits of a register), so to load a 64bit value you may have to perform up to 5 operations (two loads, a shift and two more loads). So a PPC requires up to 64bits for a 32bit immediate load and up to 160bits to load a 64bit value (unless you store such a value in a memory location that can be addressed in a faster way). These are worst cases however, and in a lot of cases 1 or maybe two instructions is enough.
The main downside of 64bit code is that all pointers become 64bit, so all pointer loads and stores indeed require twice as much storage and bandwidth.
Actually, the only change in the 0.2.1 release is that the default install also installs the config package I was talking about. This config package indeed includes a .xinitrc which executes quartz-wm. If you don't install the config package, you simply get no .xinitrc (or you keep your existing .xinitrc if you already had one), which results in X starting twm.
Obviously, the message passing interface is still there and e.g. can still be used to have kernel space code communicate with userland code.
Apple didn't just pick up the Mach kernel and used it, they improved it a lot and one of the things they did was to rip out all that message passing stuff, while still retaining the modular design of the kernel. The result is that they more or less get the best of both worlds: a modular design with the speed of a monolithic kernel. Of course they did lose the ability of a true microkernel where the whole kernel doesn't crash if one of its modules does.
lsbom MacOSX10.2.4.pkg/Contents/Archive.bom
Backside cache does not increase the speed of a hard drive at all. Backside cache sits between main memory and the cpu, not between the HD and main memory. You're right it does a lot for the overall system speed (since the processor has to wait less for new data to arrive from main memory), but it doesn't make the hard drive any faster (e.g. duplicating a file or swapping won't be sped up significantly).
I've got an iBook 12"/800MHz and it runs OS X quite well (it's quite a bit faster than my old G4/400 desktop). It's true that the HD of the iBook isn't the fastest (I haven't really benchmarked it, but it seems like it's limited to something lik 20MB/sec read and 8-10MB/sec write speed), but that's not really due to the 4200 rpm speed: the Powerbooks also have 4200 rpm drives, but they're quite a bit faster (also faster that the previous generation's Powerbook drives, some of which did run at 5400 rpm). The reason is that the more expensive notebook drives have a higher data density, so they don't have to rotate as fast to get decent transfer speeds. Access time will still be slightly higher of course.
Open up the installer again, do a custom install and install the config package.
Regarding the heat issue: I've read in a comment on macnn.com that maybe it's only the stock combo-drive models that may have a heat issue. The reason would be the hard drive: the 40GB version in those models is supposedly slightly taller than the 60GB version in the superdrive model, thus restricting airflow and increasing heat build-up.
It mounts fine here. If it has a weird name after downloading (something like nph-.hqx), rename it to X11.dmg and try again. If it is really called X11.dmg, try dragging it over Stuffit Expander to see whether it's maybe still encoded.
Apart from the arguments of the other people that replied already, there's also the issue that Apple doesn't own the rights to all technologies used in Mac OS 9 (e.g. all powstscript-related stuff).
- Jaguar runs fine without it (and is still faster than Mac OS X 10.1.5 graphics-wise)
- the reason it's not supported on lower-end graphics cards is because they don't have the hardware necessary to support its implementation (they have to support textures with a size tht's not a power of 2)
Complaining about Quartz Extreme is the same as complaining about Altivec optimizations (since they don't help for G3's). It's just an extra fgeature that takes advantage of the extra hardware you have and which is otherwise just sitting idle. Not making Quicktime for Linux is having not enough resources to put into such an enormous undertaking. What enormous undertaking you ask? Well, Quicktime for Windows is not just a couple of audio and video codecs and some glue code, but a port of half the Mac OS toolbox to win32 (so they could keep the Quicktime source more or less the same for both platforms).I've read a couple of times in the past on the mac-games-dev list hosted at Apple, that developers considering to port their (small-scale) game from Mac to Windows were encouraged by other developers to simply require QTfW, since then they wouldn't have to change their code that much (nor really learn the win32 API in-depth).
So you see, porting Quicktime to Linux would mean porting that age-old toolbox stuff over to Linux. And no, they haven't already don't a *nix port for Mac OS X, since there they use Carbon (which is based on the old toolbox API). Given that the ROI would be quite small (who's gonna upgrade to Quicktime Pro for $29,95? What Linux pro-video app creators for Linux will go into a Quicktime-pro bundling deal with Apple?), I think they don't do it simply because it doesn't make any business sense.
As must have been mentioned already thousands of times on slashdot, the Quicktime fileformat is completely open. It's the codecs that are proprietary and whose unavailability causes so much grief (although the latest versions of vlc and mplayer can play pretty much everything you can throw at them, making this less of an issue) They indeed (afaik at least) haven't given much back too Free/Open/NetBSD, but used a whole bunch of apps and libraries supported by those distributions. But why would that be? Maybe because they also didn't change anything to those apps and libraries? The changes that they did do, have been submitted back and those that were rejected are still available via Darwin cvs.I mean, what should they do according to you? Give all BSD distro's a penny per line of source code that they used? Do you think that's what those distro's want? I doubt it. In general, what an open source project wants is that its stuff gets used, improved/bug fixed if necessary and that they get recognition for it. I don't see where Apple failed.
Apart from that, there's of course the obligatory mention of Apple's work on gcc (which is used by pretty much every open source OS out there, including the BSD's), resulting in (on average) 30% faster code generation for the PowerPC in version 3.x, altivec intrinsics and obj-c++ support. Yes, they were required to make their changes to gcc public since it's GPL, but
- they were never forced to use gcc (they could've also take MrC, which still generates much better code than gcc)
- they were also never forced to actively submit patches to the FSF, rework them when they're rejected and submit them again etc
There's of course also all the open source projects that they started and maintain themselves, such as the Darwin Streaming server (which not only streams Quicktime files, but also mp3 and mp4's), OpenPlay, Rendezvous,It's of course obvious that Apple doesn't do all those things simply because it loves open source and wants to support us hackers. It does those things because it makes sense for them (in case of choosing gcc instead of MrC, that's because MrC's C++ support was quite mediocre; with the submitting of patches it's because otherwise they have to remerge all their patches with every new release, while now the FSF maintainers make sure that the accepted patches are maintained).
All the ranting about Apple being communist, capitalist and/or corporatist aside, I think it's clear that Apple currently tries to do as much things as possible in such a way that it's both good for itself and the open source community. Yes, when there are big trade-offs, it's the open source camp that "loses" (but that's logical, Apple is still a company and if it doesn't make such decisions, there will simply be no Apple anymore in a couple of years).
Well, that's enough ranting in an old thread for today <g>
NetSprockets is indeed deprecated/abandoned, but OpenPlay is not (it's the successor). CDSA is Intel's (yes, that Intel) security specification of which Apple made an implementation (which is much better than the reference implementation that Intel provides, from what I've heard) and then open sourced it.
No, for the same reason that 2^40 + 2^128 != 2^168. You're not combining the keys, you're just using them after eachother. In the end, the 40 bits DES encryption doesn't even really matter, since the 128 AES key dwarfs its complexity (like in efficiency analysis, O(n) + O(n^2) = O(n^2)).