Well, you seemed to be complaining that Tiger wasn't going to fully use your G5. I was pointing out how it does so. You can do 64-bit math, and you can do 64-bit addressing if you really want to (but you won't). Plus you can use all the other good stuff the G5 provides (such as faster speeds than the G4).
Of course, it's possible that someone might want to use 64-bit addressing even on a machine with less than 4GB, for example if one wanted to mmap() lots of files simultaneously. They wouldn't all be allocated physical pages of RAM at the same time, but it would work. Although a bit silly.:-)
Don't forget, the G5 has a significant lead over the G4 in terms of clock speed, in addition to a much better bus. (The G4, even if it could be made to run faster, doesn't have nearly enough bandwidth on its bus to feed instructions and data to the CPU.) So there are very significant advantages to running a G5 instead of a G4.
Dual core is easy to take advantage of.. just be sure to run more than one application simultaneously (which is always the case anyway in Mac OS X.. there are lots of background processes running at all times). The kernel's scheduler will take care of distributing processes between the different cores, keeping them busy. No programs have to be modified at all. (Although an individual program will run much faster if it is multithreaded, as then that single program will be able to use more than one processor core at the same time. Single threaded programs won't see any change, except that there will be less competition for CPU time as other processes can run on the other cores instead.)
In that case they'll probably have some coupon you have to mail in to get the CD-ROM version. This is probably just a way to save money.
This way they only have to press one disc (or possibly two.. one for the OS and one for Xcode, as they tend to be upgraded independently of each other) instead of 4 or 5. Then they only have to incur the extra expense for the minority of users who need the CD-ROM version.
Apple's system requirements page says nothing about requiring DVD drives. I'm sure it will be available on CD-ROM.
The developer seeds were delivered on DVD (and as DVD disk images on the web site) which is probably the source of the confusion. While it was pretty safe to assume that developers would have DVD drives, they can't make the same assumption about consumers (yet).
No haxie needed. The developer documentation for Dashboard includes a secret defaults key which enables exactly this behavior. It's still under NDA, so I can't tell you what it is, but look for it to appear on macosxhints.com as soon as Tiger is released.:-)
I got as far as running some XCode wizard (the screensaver one I think) and couldn't quite see how to do stuff in C++.
Mac OS X screensavers use the Cocoa API so you need to use Objective C, not C++. No, it's not what you're used to, but it's a nice language which is well-suited to user interface code.
If you're serious about Mac OS X development and want to write applications which blend in well with the Mac environment (necessary if you expect Mac users to actually want to use your applications) then you must learn how Mac applications are supposed to look and behave and figure out how to apply the Human Interface Guidelines to your application. (Note that the HIG is not always 100% accurate.. there are places where you should deviate from it slightly in order to match what Apple's apps do.) This is important, as if you do anything unMaclike then your application will be bashed as a bad Windows port (even if you wrote it from scratch) and no Mac users will touch it.
You have two ways to go in terms of APIs. Cocoa and Carbon. Cocoa is a refined version of NeXT's OpenStep. Carbon is a cleaned up version of the old Classic Mac OS API (but with a huge number of changes.. it is much improved.) Carbon is straight C code, and the concepts involved are more similar to Windows or X11 than Cocoa's design. But it's big and complicated, and would take a long time to learn. Also, there's a lot more stuff that you have to do in Carbon to make your application behave properly.
Cocoa gives you most of the behavior for free. You'll write less code, and you'll probably end up with a more Mac-like application. (It's entirely possible to write a a well-behaved Carbon app, but you'll have a lot more to learn in order to do it right, as fewer things are done for you automatically.)
With Cocoa you'll have to learn Objective C. This is not a big deal. If you know C, then you can learn the handful of additions which comprise Objective C in less than an hour. It's a very simple language.
Theoretically you can program Cocoa apps in Java, but I do not suggest that you attempt this. Java does not really fit into the Cocoa model very well (it's not nearly dynamic enough) and was shoehorned in as a way to attract developers who refused to learn ObjC. This was a mistake on Apple's part, and they seem to have realized it... they no longer promote the use of Java in Cocoa.
I strongly recommend that you spend some time with Hillegass's book on Cocoa. Objective C an elegant language, and is certainly the fastest way to develop Mac applications.
If you are a diehard C++ fan, then you may be better off with Carbon, but there will probably be a bigger learning curve as the Carbon libraries are more complex. (Carbon has a long complicated history, from its Pascal roots and old Classic Mac OS constructs (resource forks, FSspecs, Gworlds, etc.) and repeated changes in design (GetNextEvent() replaced by WaitNextEvent() and then Carbon Events, QuickDraw replaced by Color QuickDraw and now by Quartz 2D) so it takes quite a while to figure it all out.
I'd give ObjC and Cocoa a chance first. You can always use Objective-C++ to combine an ObjC user interface with a C++ backend, if you need to port old code. Be sure to check out MacSTL as it provides some nifty stuff to treat some Core Foundation and Foundation objects in an STL manner.
As for tools... well, the Xcode IDE and all the GNU tools (gcc, gdb, etc.) come with Mac OS X, so you shouldn't need to buy anything.
So basically, the full potential of the G5 sitting in the consumer iMac and maybe the Power Macintosh won't be realized for quite some time. Damn, not even pro apps like FCP or Shake is going used it soon. That is a real disappointment because what's the point of having a 64-bit processor if it is not being used in the lifetime of the computer. I sure hope dual-core processors offer something better than this.
Please note that "64-bit" encompasses two completely different things:
64-bit integer registers and arithmetic operations on those registers
64-bit pointers
Note that you can already use 64-bit registers and do 64-bit math. This is more of a compiler issue than an operating system issue. (The only change needed to the kernel is to save the full contents of the registers on context switching, rather than only the low 32 bits.)
What would 64-bit pointers give you if you could use them?
ability to address more than 4 GB of RAM from within a single application (how many applications need that much RAM?)
larger code size, resulting in greater memory usage
slower performance, because less code can fit in the L1/L2 caches
slower performance in low memory situations because you're more likely to have to page out more often.
How many apps actually need to address more than 4GB of RAM at once? Usually they're only doing that if they are dealing with big files. A process using 32-bit pointers can do this using mmap() and if used correctly the kernel can load the whole file into RAM (if possible) and just adjust virtual memory tables so that the same chunk of 32-bit address space points at different parts of the file as needed. The app just has to make the right mmap() call to cause the kernel to shuffle around the virtual memory mappings to change which physical page is mapped onto which virtual page in that process's virtual memory.
If you do need 64-bit addressing for some reason (although it's extremely rare for it to be actually necessary, nearly everything can just mmap() files instead), then fork off a separate process and let it do whatever needs to be done with that huge amount of RAM. Use your favorite form of IPC or shared memory to talk to that process.
What does Tiger give us that's not already in Panther? Well, all apps will see some performance improvement as various system libraries now use 64-bit operations for arithmetic where appropriate. Processes using 64-bit pointers now have some important libraries available, most notably libsystem (Apple's combined libc and libm) which was not available for processes using 64-bit pointers in Panther. Not all libraries are available in 64-bit versions (Carbon and Cocoa, for example) but there's no good reason for them to be. There's no good reason for it. Apps run slower when using 64-bit addressing on current systems, so only those rare processes which really need the extra addressing space should be using it, and user interface code certainly doesn't fall into that category.
Apple's information on 64-bit computing in Tiger is available here.
So you see, the full capabilities of your 64-bit CPU are being used. 64-bit math is up to the application writer to use the appropriate compiler options (and in Tiger the system libraries will also use 64-bit math internally) whereas 64-bit addressing is already used by the kernel (even in Panther) to handle virtual memory, allowing the use of more than 4 GB of RAM (although most processes will use 32-bit addressing and will thus be limited to only 4GB each).
With a dual G5 it only takes less than 2 hours to index 150GB, using the recent builds of Tiger. Early builds were significantly slower, but it's fine now. Probably even faster in the shipping version (rumored to be a later build than any made available to ADC members so far).
10.0 was buggy as hell, missing features and nobody really used it for production. 10.1 and 10.2 were massive bugfixes and feature adds. Hard-core Mac fans will dispute this, no doubt.
I don't think many will dispute it. It's generally accepted in the Mac community that the reason 10.1 was given out as a free upgrade to 10.0 was because 10.0 was not a finished product.
Maybe we'll see some OS X ads after Tiger ships. But I wouldn't count on it. I'm sure we'll see some Power Mac ads if/when they release those boxes with dual core versions of the PPC970.
I wish they'd sell all of that to US cable companies. I'd pay $20/month to get BBC1-4 and news.
BBC America is nice, but there's only so much you can fit into one channel, especially after making time for all of the advertising. (Like any typical American TV channel, it's about 25% advertising.)
My cable company (Adelphia.. yuck) offers several channels from other countries (at around $10/month each).. I'd expect that they would be willing to carry a BBC package. But my guess is that BBC America would object, as the real BBC might steal viewers away.
My only complaint about the GameCube controller is the Z button. It's very difficult for me to use.
The L & R shoulder buttons took some getting used to, but they're OK.
The rest of the controller is great, especially the A & B buttons.
I still prefer the PS2 DualShock 2 controller overall, as all of its buttons are very usable (well, start/select are tricky to reach sometimes, but that's true of most controllers, including the GC start button). My only problem with the PS2 controller is that my thumbs tend to slide off the analog sticks at times, although it seems that as that this improve somewhat as the surface of the sticks wear down some. The symmetry of the DualShock is quite attractive, as well.
Yeah, the use of a 65816 in the SNES definitely makes it look like Nintendo at least considered the possibility of NES compatibility. (The same way Apple used the 65816 in the Apple IIgs for compatibility with the 8-bit Apple II models.)
On the other hand, the fact that the video registers, pad input registers, etc. are at different addresses on the SNES and NES suggests that perhaps they weren't going for compatibility. Perhaps they just wanted to make life easy for developers who were used to writing NES games. Giving them similar registers and using a CPU compatible with the 6502 instruction set would definitely make life easier for developers.
You did notice the date of the supposed preorder, right? That was an April Fools joke. EGM always does an April Fools joke, and it looks like this year's was pretty effective.:-)
ugh. you ran ProDOS 16? Wow, that sucked. It was just ProDOS 8 with a few 16 bit wrappers for a few functions. Oh, and multiple prefixes instead of one. When was useless.
Luckily System 5.0.2 (the first really usable GS/OS.. System 4 was not any good) was out by the time I got my GS (a ROM 3) and it was pretty usable. System 6.0.1 kicked ass if you had a hard disk to boot it from. Very similar to early versions of System 7 on the Mac, except that you could only run one app at a time. (Although there was a third-party hack to fix that.)
With any luck, BBC America will decide to show it. While I wouldn't mind having it on PBS, I'd rather have it on BBC America so I don't have to worry about whether or not any of my local stations pick it up. (Although I'm pretty sure KCET would, as they showed it for at least a decade when I was growing up.)
If anyone else wants to see BBC America show Dr. Who, go fill out this form on their site and let them know that you want to see it!
Earlier in the season it was revealed that Dr. Soong (great-grandparent of the one who made Data & Lore) had raised some leftover embryos of the genetically modified humans who caused the trouble back in the Eugenics Wars. There was some interaction with the Klingons, and the Klingons decided that in order to compete with genetically-modified humans (who were as strong and agressive as Klingons) they needed to make genetically-modified Klingons. But rather than starting from scratch, they used DNA from the dead bodies of some of the genetically modified humans to develop a virus which would enhance Klingons. The virus had a number of unfortunate side effects, such as killing the recipient, and causing a human-like appearnace by removing the cranial ridges. (The second effect was probably considered worse by most of the recipients.)
The Klingons kidnapped Dr. Phlox to help them find a cure for the virus, which he manages to do in the nick of time (of course) but it is only mostly effective.. the virus still removes the cranial ridges of the Klingons. Oh, and it changes their DNA such that their kids won't have cranial ridges either.
So there you have it. The lack of prosthetic makeup on the original series Klingons is connected with Khan. Wacky, ain't it?
we usually buy their deal of the week (or whatever it's called now) which nearly always includes a rebate, which as you mention is limited to 5. Yeah, we could skip the rebate, but the whole point here is to save as much money as possible, and the way to do that is to have each person order 5.:-)
I work for a school, but we always buy from Dell's small business site rather than their education site because of the huge difference in pricing. The only annoying part is that you can't order more than 5 machines at a time from the small business division.
Slashdot Mirror
Well, you seemed to be complaining that Tiger wasn't going to fully use your G5. I was pointing out how it does so. You can do 64-bit math, and you can do 64-bit addressing if you really want to (but you won't). Plus you can use all the other good stuff the G5 provides (such as faster speeds than the G4).
:-)
.. just be sure to run more than one application simultaneously (which is always the case anyway in Mac OS X .. there are lots of background processes running at all times). The kernel's scheduler will take care of distributing processes between the different cores, keeping them busy. No programs have to be modified at all. (Although an individual program will run much faster if it is multithreaded, as then that single program will be able to use more than one processor core at the same time. Single threaded programs won't see any change, except that there will be less competition for CPU time as other processes can run on the other cores instead.)
Of course, it's possible that someone might want to use 64-bit addressing even on a machine with less than 4GB, for example if one wanted to mmap() lots of files simultaneously. They wouldn't all be allocated physical pages of RAM at the same time, but it would work. Although a bit silly.
Don't forget, the G5 has a significant lead over the G4 in terms of clock speed, in addition to a much better bus. (The G4, even if it could be made to run faster, doesn't have nearly enough bandwidth on its bus to feed instructions and data to the CPU.) So there are very significant advantages to running a G5 instead of a G4.
Dual core is easy to take advantage of
In that case they'll probably have some coupon you have to mail in to get the CD-ROM version. This is probably just a way to save money.
.. one for the OS and one for Xcode, as they tend to be upgraded independently of each other) instead of 4 or 5. Then they only have to incur the extra expense for the minority of users who need the CD-ROM version.
This way they only have to press one disc (or possibly two
Apple's system requirements page says nothing about requiring DVD drives. I'm sure it will be available on CD-ROM.
The developer seeds were delivered on DVD (and as DVD disk images on the web site) which is probably the source of the confusion. While it was pretty safe to assume that developers would have DVD drives, they can't make the same assumption about consumers (yet).
No haxie needed. The developer documentation for Dashboard includes a secret defaults key which enables exactly this behavior. It's still under NDA, so I can't tell you what it is, but look for it to appear on macosxhints.com as soon as Tiger is released. :-)
Mac OS X screensavers use the Cocoa API so you need to use Objective C, not C++. No, it's not what you're used to, but it's a nice language which is well-suited to user interface code.
If you're serious about Mac OS X development and want to write applications which blend in well with the Mac environment (necessary if you expect Mac users to actually want to use your applications) then you must learn how Mac applications are supposed to look and behave and figure out how to apply the Human Interface Guidelines to your application. (Note that the HIG is not always 100% accurate .. there are places where you should deviate from it slightly in order to match what Apple's apps do.) This is important, as if you do anything unMaclike then your application will be bashed as a bad Windows port (even if you wrote it from scratch) and no Mac users will touch it.
.. it is much improved.) Carbon is straight C code, and the concepts involved are more similar to Windows or X11 than Cocoa's design. But it's big and complicated, and would take a long time to learn. Also, there's a lot more stuff that you have to do in Carbon to make your application behave properly.
... they no longer promote the use of Java in Cocoa.
... well, the Xcode IDE and all the GNU tools (gcc, gdb, etc.) come with Mac OS X, so you shouldn't need to buy anything.
You have two ways to go in terms of APIs. Cocoa and Carbon. Cocoa is a refined version of NeXT's OpenStep. Carbon is a cleaned up version of the old Classic Mac OS API (but with a huge number of changes
Cocoa gives you most of the behavior for free. You'll write less code, and you'll probably end up with a more Mac-like application. (It's entirely possible to write a a well-behaved Carbon app, but you'll have a lot more to learn in order to do it right, as fewer things are done for you automatically.)
With Cocoa you'll have to learn Objective C. This is not a big deal. If you know C, then you can learn the handful of additions which comprise Objective C in less than an hour. It's a very simple language.
Theoretically you can program Cocoa apps in Java, but I do not suggest that you attempt this. Java does not really fit into the Cocoa model very well (it's not nearly dynamic enough) and was shoehorned in as a way to attract developers who refused to learn ObjC. This was a mistake on Apple's part, and they seem to have realized it
I strongly recommend that you spend some time with Hillegass's book on Cocoa. Objective C an elegant language, and is certainly the fastest way to develop Mac applications.
If you are a diehard C++ fan, then you may be better off with Carbon, but there will probably be a bigger learning curve as the Carbon libraries are more complex. (Carbon has a long complicated history, from its Pascal roots and old Classic Mac OS constructs (resource forks, FSspecs, Gworlds, etc.) and repeated changes in design (GetNextEvent() replaced by WaitNextEvent() and then Carbon Events, QuickDraw replaced by Color QuickDraw and now by Quartz 2D) so it takes quite a while to figure it all out.
I'd give ObjC and Cocoa a chance first. You can always use Objective-C++ to combine an ObjC user interface with a C++ backend, if you need to port old code. Be sure to check out MacSTL as it provides some nifty stuff to treat some Core Foundation and Foundation objects in an STL manner.
As for tools
Please note that "64-bit" encompasses two completely different things:
Note that you can already use 64-bit registers and do 64-bit math. This is more of a compiler issue than an operating system issue. (The only change needed to the kernel is to save the full contents of the registers on context switching, rather than only the low 32 bits.)
What would 64-bit pointers give you if you could use them?
How many apps actually need to address more than 4GB of RAM at once? Usually they're only doing that if they are dealing with big files. A process using 32-bit pointers can do this using mmap() and if used correctly the kernel can load the whole file into RAM (if possible) and just adjust virtual memory tables so that the same chunk of 32-bit address space points at different parts of the file as needed. The app just has to make the right mmap() call to cause the kernel to shuffle around the virtual memory mappings to change which physical page is mapped onto which virtual page in that process's virtual memory.
If you do need 64-bit addressing for some reason (although it's extremely rare for it to be actually necessary, nearly everything can just mmap() files instead), then fork off a separate process and let it do whatever needs to be done with that huge amount of RAM. Use your favorite form of IPC or shared memory to talk to that process.
What does Tiger give us that's not already in Panther? Well, all apps will see some performance improvement as various system libraries now use 64-bit operations for arithmetic where appropriate. Processes using 64-bit pointers now have some important libraries available, most notably libsystem (Apple's combined libc and libm) which was not available for processes using 64-bit pointers in Panther. Not all libraries are available in 64-bit versions (Carbon and Cocoa, for example) but there's no good reason for them to be. There's no good reason for it. Apps run slower when using 64-bit addressing on current systems, so only those rare processes which really need the extra addressing space should be using it, and user interface code certainly doesn't fall into that category.
Apple's information on 64-bit computing in Tiger is available here.
So you see, the full capabilities of your 64-bit CPU are being used. 64-bit math is up to the application writer to use the appropriate compiler options (and in Tiger the system libraries will also use 64-bit math internally) whereas 64-bit addressing is already used by the kernel (even in Panther) to handle virtual memory, allowing the use of more than 4 GB of RAM (although most processes will use 32-bit addressing and will thus be limited to only 4GB each).
With a dual G5 it only takes less than 2 hours to index 150GB, using the recent builds of Tiger. Early builds were significantly slower, but it's fine now. Probably even faster in the shipping version (rumored to be a later build than any made available to ADC members so far).
I don't think many will dispute it. It's generally accepted in the Mac community that the reason 10.1 was given out as a free upgrade to 10.0 was because 10.0 was not a finished product.
Maybe we'll see some OS X ads after Tiger ships. But I wouldn't count on it. I'm sure we'll see some Power Mac ads if/when they release those boxes with dual core versions of the PPC970.
Huh? What are you talking about?
Motorola is a US corporation, traded on the NYSE (ticker symbol MOT). Its headquarters are in Schaumburg, Illinois. How does that make it German?
I wish they'd sell all of that to US cable companies. I'd pay $20/month to get BBC1-4 and news.
.. yuck) offers several channels from other countries (at around $10/month each) .. I'd expect that they would be willing to carry a BBC package. But my guess is that BBC America would object, as the real BBC might steal viewers away.
BBC America is nice, but there's only so much you can fit into one channel, especially after making time for all of the advertising. (Like any typical American TV channel, it's about 25% advertising.)
My cable company (Adelphia
My only complaint about the GameCube controller is the Z button. It's very difficult for me to use.
The L & R shoulder buttons took some getting used to, but they're OK.
The rest of the controller is great, especially the A & B buttons.
I still prefer the PS2 DualShock 2 controller overall, as all of its buttons are very usable (well, start/select are tricky to reach sometimes, but that's true of most controllers, including the GC start button). My only problem with the PS2 controller is that my thumbs tend to slide off the analog sticks at times, although it seems that as that this improve somewhat as the surface of the sticks wear down some. The symmetry of the DualShock is quite attractive, as well.
Yeah, the use of a 65816 in the SNES definitely makes it look like Nintendo at least considered the possibility of NES compatibility. (The same way Apple used the 65816 in the Apple IIgs for compatibility with the 8-bit Apple II models.)
On the other hand, the fact that the video registers, pad input registers, etc. are at different addresses on the SNES and NES suggests that perhaps they weren't going for compatibility. Perhaps they just wanted to make life easy for developers who were used to writing NES games. Giving them similar registers and using a CPU compatible with the 6502 instruction set would definitely make life easier for developers.
You did notice the date of the supposed preorder, right? That was an April Fools joke. EGM always does an April Fools joke, and it looks like this year's was pretty effective. :-)
ugh. you ran ProDOS 16? Wow, that sucked. It was just ProDOS 8 with a few 16 bit wrappers for a few functions. Oh, and multiple prefixes instead of one. When was useless.
.. System 4 was not any good) was out by the time I got my GS (a ROM 3) and it was pretty usable. System 6.0.1 kicked ass if you had a hard disk to boot it from. Very similar to early versions of System 7 on the Mac, except that you could only run one app at a time. (Although there was a third-party hack to fix that.)
Luckily System 5.0.2 (the first really usable GS/OS
With any luck, BBC America will decide to show it. While I wouldn't mind having it on PBS, I'd rather have it on BBC America so I don't have to worry about whether or not any of my local stations pick it up. (Although I'm pretty sure KCET would, as they showed it for at least a decade when I was growing up.)
If anyone else wants to see BBC America show Dr. Who, go fill out this form on their site and let them know that you want to see it!
Lord of the G-Strings was much better than Spiderbabe, in my opinion. But neither one compares to Play-Mate of the Apes when it comes to Misty Mundae sillyness.
It was a two-parter:
SPOILER WARNING
Earlier in the season it was revealed that Dr. Soong (great-grandparent of the one who made Data & Lore) had raised some leftover embryos of the genetically modified humans who caused the trouble back in the Eugenics Wars. There was some interaction with the Klingons, and the Klingons decided that in order to compete with genetically-modified humans (who were as strong and agressive as Klingons) they needed to make genetically-modified Klingons. But rather than starting from scratch, they used DNA from the dead bodies of some of the genetically modified humans to develop a virus which would enhance Klingons. The virus had a number of unfortunate side effects, such as killing the recipient, and causing a human-like appearnace by removing the cranial ridges. (The second effect was probably considered worse by most of the recipients.)
The Klingons kidnapped Dr. Phlox to help them find a cure for the virus, which he manages to do in the nick of time (of course) but it is only mostly effective .. the virus still removes the cranial ridges of the Klingons. Oh, and it changes their DNA such that their kids won't have cranial ridges either.
So there you have it. The lack of prosthetic makeup on the original series Klingons is connected with Khan. Wacky, ain't it?
Huh? This is Canada now?
Yeah, and then find out the hard way that 90% of humans don't implement the protocols according to the spec.
we usually buy their deal of the week (or whatever it's called now) which nearly always includes a rebate, which as you mention is limited to 5. Yeah, we could skip the rebate, but the whole point here is to save as much money as possible, and the way to do that is to have each person order 5. :-)
I work for a school, but we always buy from Dell's small business site rather than their education site because of the huge difference in pricing. The only annoying part is that you can't order more than 5 machines at a time from the small business division.
According to the apple2history.org page on the //c the "AppleMouse IIc" plugged into the joystick port.
Nope. The //c had a built-in keyboard (like all other 8-bit Apple II models)
Apple Desktop Bus was first introduced on the Apple IIGS, followed a few months later by the Macintosh SE.