The architecture will be x86, or x86-64. This is not in debate anymore. The developer transition boxes are Pentium 4, and that's what the compiler targets. x86. It might not be the same exact chip, but it will be the same instruction set, otherwise you'd have a worthless lot of recently-ported software when all is said and done.
It will NOT ship with Wine. That would be suicide for Apple, because it would kill Mac development dead, turning the Mac into a not-quite-as-good-as-windows win32 box.
Well, there will be some of us who will actually want legal versions of our software. For those people, we will have to buy an actual Mac to get the Mac OS.
This is actually how I deal with a lot of spam. I stopped carrying my cell phone/stopped talking to people (at school) on AIM/email and just started relying on the fact that I leave my door open when I'm there when I got to college. It's a lot nicer way to live.
Well, when you're talking about "QT" to a Mac developer, [s]he's gonna think QuickTime. Mac people do use quicktime, a lot, so that's not really new.
Now, if you're talking about QuickTransit, that's what Rosetta is. Now, we don't know that for sure, it's not set in stone (hah! stone, get it?), but we're pretty damned sure Rosetta is QuickTransit for x86.
Maybe this is a misconception, but I thought that at some point the ancient x86 instruction set and registers were "set aside" in favor of a more modern RISC-style processor core, and the old x86 stuff is supported as a kind of pass-through layer on top of that. I understand that's the case with AMD's Athlon, anyhow.
This has been correct for everything since the Pentium Pro. CISC is a bad way to do a CPU, and everyone knows it. You can think of the x86 layer as a sort of machine code compression that actually increases how much code you can keep in cache at one point. A byte of x86 goes a lot farther than a byte of PPC.
Geez, I almost did my usual "No, silly, Mac OS X won't run on x86..." post. It's pretty much reflex at this point.
(of course, it probably won't run Mac OS X/Intel, which will most likely require some sort of special hardware, be it a custom firmware or chipset, to run, just to ensure that you're using an actual Mac)
If I'm not mistaken (which I may be, from your message, you probably know more about this than this lowly engineering student;-) ), the memory technique most commonly used in CPU registers is a static, active transistor logic type. Pretty much just flip-flops. Dynamic RAM is useful because it's cheap, and when you're talking about the 4 bytes or so of RAM in registers, it's not really all that important.
In addition, dynamic RAM needs refresh logic, and it's a little bit complex, so it'd be just plain silly to have all that logic for the minimal number of bits required for registers.
The file format and internal data structure has nothing to do with how the data is presented to the graphics layer of the operating system. Photoshop supports 32bpp/channel, but when that image is displayed, the value is rounded to 8bpp/channel.
From the Cinepaint web-page: "Although you can't display a 16-bit image (48-bit RGB) on your monitor in full color, the higher quality can be visible when printed to film."
And while X11 will support more than 8bpp, it will NOT support more than 8bpp/channel. Yes, the CRT could display more than that, however the sticking point is the display layer. You can't give GDI or Quartz three 16 bit numbers for a point on the display, and I'm pretty damn sure you can't give X11 that either. You might be able to write some horrible hack that bypasses the graphics layer, but Film Gimp (now Cinepaint) doesn't do this.
As does IBM. It'd be mighty hard to sell a chip without documentation on it... From a hardware point of view, the Mac is pretty much a standard piece of PowerPC kit, with Open Firmware and a mostly standard motherboard (standard in the PPC world, PReP). The Mac isn't the black box it used to be. Linux runs quite well on it, and it's pretty easily (well, relatively) emulated with PearPC.
Those extra two bits are used to linearize the output. Windows nor the Mac (X11 might be able to through some huge hack) can actually display more than 8bits/channel RGB. The software on the computer can't tell the graphics card a 10bpp/channel pixel, so there's no way it could "make a difference", aside from making a linear gradient actually linear. The display can't show any more than 256 shades of grey.
DICOM (medical imaging) systems have used 12 bit images for years, but it's only to give more latitude. There aren't displays that can use it outside of VERY specialized (i.e. research) fields. If it made a difference, they'd do it. These are $20k displays. They're still 8bpp at the application level.
Google "iScroll2". It lets you right click on the powerbook by reporting a right click when you press the button with a finger on the trackpad. Quite nice.
MS didn't update VPC to take advantage of the G5. They updated it to run, period. VPC used to work based on the trick that the PPC could swap byte orders at run time. This was added in the big fork when the PowerPC forked from IBM's POWER chip 10 years ago.
When it forked again 2 years ago with the G5 (PPC970), they added Altivec, but not the endian-switch-hitterness. Therefore, the G5 wouldn't run VirtualPC.
Microsoft updated the software to work on the G5. They did this because it's a product, and they wanted to sell it. It's an expensive product, targeted at high-end users (who use G5s), and it sells windows licenses. They don't really care if you're running it on a real x86 chip somewhere or if you're using VPC. Either way, they still get your money for Windows.
Exactly, and like all consoles, the profit is in the software. Microsoft wants you to buy as many XBox games as possible, so if the XBox360 can play them, it would be to their advantage to say so to keep people in the stores for XBox 1 games.
The only reason that they might not say so is if there's a chance they can't get it to work.
Fine, give me a way to backup my ~half a terabyte or so without selling my car first, and I'll do it.
Seriously, in the day and age when I can get a 400gbyte drive for like $200, why the hell can't I back it up to anything but another 400gbyte drive? (which is what I have to do... actually, what I do is back up my 80gig drive to a 500gig drive, and hope and pray the 500gig drive doesn't crap out)
No, reverse engineering for compatibility is defined as legal by the DMCA. There's an exception for it, for exactly the examples you've cited (document formats). As long as there's no copyright violation involved, I'd say they're on pretty firm ground, legally.
Yeah, a portable device with a lot of battery power, wireless, two screens and a touchscreen input running a general purpose operating system that's relatively inexpensive and that many of us already have couldn't possibly be practical...
I'd never want my GameBoy to replace my palmpilot...
OpenVMS is not open source. It's simply what DEC called VMS in its later years, to signify an open-system, not an open source base. In other words, it supported open standards such as POSIX and Unix compatability, as well as TCP/IP networking, instead of the proprietary systems it used to support.
There is a project by the name of FreeVMS, but it's not anywhere close to being done, and it's pretty much stagnant now.
You are quite correct in your description of atmospheric flight (I should have turned off my physicist mode and went back into engineer... just goes to show you that when you're studying for a phys midterm, everything goes in physics terms. Double-slit experiments with bagels and the like...), and I can more than understand the pains of 3 hour chem classes, as I too just got out of a far-too-long chem lab. (I'm a satisfied customer of Harvey Mudd College)
For the flight regime of orbital flight (and yes, it's still a flight regime, as counter-intuitive as that might seem) you're going so far into the hypersonic region that the shape of your spacecraft doesn't much matter, and the system can accurately be modeled as a collection of particles hitting your spacecraft head-on every once in a while. The shape doesn't much matter (for LEO, objects are given a Cd of 2 [that figure always stikes me as absolutely fascinating]) so you can't really get any lift out of the system. All that happens is that orbital energy goes away, and you sink until you're so low that you hit entry interface, and barring a whole hella lot of thrust, you're coming down. (doesn't much matter to the sat guys at that point, you just stop modeling things)
Actually, you are wrong on both counts. I probably should have given more backing for my statements (btw, I'm not some random guy, I'm a physics major at a respected university, so I know a little something about dynamics...)
Anyhow, to address your "hammer and feather" argument, this is indeed correct for a pure vacuum, however, such a thing does not exist in low earth orbit. Yes, the gas pressure is very, very low, however it is still there. If you take two identical objects in all respects but mass, with any measurable atmosphere, the heavier one will fall faster. Yes, the gravitational force is proportional to mass (causing objects to fall at the same acceleration in a PURE vacuum), however air drag is not related to mass, so the air drag term will become less significant with a greater gravitational force. Total f=ma, and all that. See this for more details about station keeping in LEO.
The ISS uses the Soyuz to re-boost its orbit periodically. No, it doesn't need to be firing all the time, but yes, LEO satellites need a propulsion system to counteract their drag. Airplanes do not fall out of the sky if the engines stop. They fall out of the sky when the drag force scrubs away all the kinetic energy, and the wing stalls. Likewise, an orbital object doesn't fall out of the sky right away. It takes time for the orbit to decay.
Would the decreased rate of orbital decay with the attached orbiter be a significant concern for survival over those couple of weeks it takes to mount the rescue mission? Nah, not really, the station isn't in danger of deorbiting itself that fast. Would it be significant for launching the rescue shuttle to actually launch into the correct orbit? Hell yeah.
Slashdot Mirror
Intel boxes shipped with USB before the iMac shipped, but it wasn't popular at all. The iMac made USB a success, but it didn't introduce it.
The architecture will be x86, or x86-64. This is not in debate anymore. The developer transition boxes are Pentium 4, and that's what the compiler targets. x86. It might not be the same exact chip, but it will be the same instruction set, otherwise you'd have a worthless lot of recently-ported software when all is said and done.
It will NOT ship with Wine. That would be suicide for Apple, because it would kill Mac development dead, turning the Mac into a not-quite-as-good-as-windows win32 box.
Well, there will be some of us who will actually want legal versions of our software. For those people, we will have to buy an actual Mac to get the Mac OS.
Wow! So...many...acronyms... (and I should have got that one, I've written code for it, too!)
OS X Intel doesn't use OpenFirmware. OpenFirmware is gone from the Mac. Apple has said so in no uncertain terms.
This is actually how I deal with a lot of spam. I stopped carrying my cell phone/stopped talking to people (at school) on AIM/email and just started relying on the fact that I leave my door open when I'm there when I got to college. It's a lot nicer way to live.
Well, when you're talking about "QT" to a Mac developer, [s]he's gonna think QuickTime. Mac people do use quicktime, a lot, so that's not really new.
Now, if you're talking about QuickTransit, that's what Rosetta is. Now, we don't know that for sure, it's not set in stone (hah! stone, get it?), but we're pretty damned sure Rosetta is QuickTransit for x86.
Maybe this is a misconception, but I thought that at some point the ancient x86 instruction set and registers were "set aside" in favor of a more modern RISC-style processor core, and the old x86 stuff is supported as a kind of pass-through layer on top of that. I understand that's the case with AMD's Athlon, anyhow.
This has been correct for everything since the Pentium Pro. CISC is a bad way to do a CPU, and everyone knows it. You can think of the x86 layer as a sort of machine code compression that actually increases how much code you can keep in cache at one point. A byte of x86 goes a lot farther than a byte of PPC.
Geez, I almost did my usual "No, silly, Mac OS X won't run on x86..." post. It's pretty much reflex at this point.
(of course, it probably won't run Mac OS X/Intel, which will most likely require some sort of special hardware, be it a custom firmware or chipset, to run, just to ensure that you're using an actual Mac)
If I'm not mistaken (which I may be, from your message, you probably know more about this than this lowly engineering student;-) ), the memory technique most commonly used in CPU registers is a static, active transistor logic type. Pretty much just flip-flops. Dynamic RAM is useful because it's cheap, and when you're talking about the 4 bytes or so of RAM in registers, it's not really all that important.
In addition, dynamic RAM needs refresh logic, and it's a little bit complex, so it'd be just plain silly to have all that logic for the minimal number of bits required for registers.
The file format and internal data structure has nothing to do with how the data is presented to the graphics layer of the operating system. Photoshop supports 32bpp/channel, but when that image is displayed, the value is rounded to 8bpp/channel.
From the Cinepaint web-page: "Although you can't display a 16-bit image (48-bit RGB) on your monitor in full color, the higher quality can be visible when printed to film."
And while X11 will support more than 8bpp, it will NOT support more than 8bpp/channel. Yes, the CRT could display more than that, however the sticking point is the display layer. You can't give GDI or Quartz three 16 bit numbers for a point on the display, and I'm pretty damn sure you can't give X11 that either. You might be able to write some horrible hack that bypasses the graphics layer, but Film Gimp (now Cinepaint) doesn't do this.
As does IBM. It'd be mighty hard to sell a chip without documentation on it... From a hardware point of view, the Mac is pretty much a standard piece of PowerPC kit, with Open Firmware and a mostly standard motherboard (standard in the PPC world, PReP). The Mac isn't the black box it used to be. Linux runs quite well on it, and it's pretty easily (well, relatively) emulated with PearPC.
p roducts/PowerPC_970_and_970FX_Microprocessors
http://www-306.ibm.com/chips/techlib/techlib.nsf/
Those extra two bits are used to linearize the output. Windows nor the Mac (X11 might be able to through some huge hack) can actually display more than 8bits/channel RGB. The software on the computer can't tell the graphics card a 10bpp/channel pixel, so there's no way it could "make a difference", aside from making a linear gradient actually linear. The display can't show any more than 256 shades of grey.
DICOM (medical imaging) systems have used 12 bit images for years, but it's only to give more latitude. There aren't displays that can use it outside of VERY specialized (i.e. research) fields. If it made a difference, they'd do it. These are $20k displays. They're still 8bpp at the application level.
Google "iScroll2". It lets you right click on the powerbook by reporting a right click when you press the button with a finger on the trackpad. Quite nice.
BeOS fans, powers of blind devotion to a non-existant company, activate!
MS didn't update VPC to take advantage of the G5. They updated it to run, period. VPC used to work based on the trick that the PPC could swap byte orders at run time. This was added in the big fork when the PowerPC forked from IBM's POWER chip 10 years ago.
When it forked again 2 years ago with the G5 (PPC970), they added Altivec, but not the endian-switch-hitterness. Therefore, the G5 wouldn't run VirtualPC.
Microsoft updated the software to work on the G5. They did this because it's a product, and they wanted to sell it. It's an expensive product, targeted at high-end users (who use G5s), and it sells windows licenses. They don't really care if you're running it on a real x86 chip somewhere or if you're using VPC. Either way, they still get your money for Windows.
Exactly, and like all consoles, the profit is in the software. Microsoft wants you to buy as many XBox games as possible, so if the XBox360 can play them, it would be to their advantage to say so to keep people in the stores for XBox 1 games.
The only reason that they might not say so is if there's a chance they can't get it to work.
Fine, give me a way to backup my ~half a terabyte or so without selling my car first, and I'll do it.
Seriously, in the day and age when I can get a 400gbyte drive for like $200, why the hell can't I back it up to anything but another 400gbyte drive? (which is what I have to do... actually, what I do is back up my 80gig drive to a 500gig drive, and hope and pray the 500gig drive doesn't crap out)
No, reverse engineering for compatibility is defined as legal by the DMCA. There's an exception for it, for exactly the examples you've cited (document formats). As long as there's no copyright violation involved, I'd say they're on pretty firm ground, legally.
Must not have tried very many...
luna:~/Workspace twb$ javac vader.java
vader.java:1: 'class' or 'interface' expected
if( in_array( 'Darth Vader', $movie ) ){
^
vader.java:1: unclosed character literal
if( in_array( 'Darth Vader', $movie ) ){
^
vader.java:1: unclosed character literal
if( in_array( 'Darth Vader', $movie ) ){
^
3 errors
luna:~/Workspace twb$ cc vader.c
vader.c:1: error: parse error before "if"
vader.c:1:15: warning: character constant too long for its type
luna:~/Workspace twb$ perl vader.pl
Undefined subroutine &main::in_array called at vader.pl line 1.
luna:~/Workspace twb$ ruby vader.ruby
vader.ruby:1: syntax error
vader.ruby:3: syntax error
}else{
^
Yeah, a portable device with a lot of battery power, wireless, two screens and a touchscreen input running a general purpose operating system that's relatively inexpensive and that many of us already have couldn't possibly be practical...
I'd never want my GameBoy to replace my palmpilot...
OpenVMS is not open source. It's simply what DEC called VMS in its later years, to signify an open-system, not an open source base. In other words, it supported open standards such as POSIX and Unix compatability, as well as TCP/IP networking, instead of the proprietary systems it used to support.
There is a project by the name of FreeVMS, but it's not anywhere close to being done, and it's pretty much stagnant now.
You are quite correct in your description of atmospheric flight (I should have turned off my physicist mode and went back into engineer... just goes to show you that when you're studying for a phys midterm, everything goes in physics terms. Double-slit experiments with bagels and the like...), and I can more than understand the pains of 3 hour chem classes, as I too just got out of a far-too-long chem lab. (I'm a satisfied customer of Harvey Mudd College)
For the flight regime of orbital flight (and yes, it's still a flight regime, as counter-intuitive as that might seem) you're going so far into the hypersonic region that the shape of your spacecraft doesn't much matter, and the system can accurately be modeled as a collection of particles hitting your spacecraft head-on every once in a while. The shape doesn't much matter (for LEO, objects are given a Cd of 2 [that figure always stikes me as absolutely fascinating]) so you can't really get any lift out of the system. All that happens is that orbital energy goes away, and you sink until you're so low that you hit entry interface, and barring a whole hella lot of thrust, you're coming down. (doesn't much matter to the sat guys at that point, you just stop modeling things)
Actually, you are wrong on both counts. I probably should have given more backing for my statements (btw, I'm not some random guy, I'm a physics major at a respected university, so I know a little something about dynamics...)
Anyhow, to address your "hammer and feather" argument, this is indeed correct for a pure vacuum, however, such a thing does not exist in low earth orbit. Yes, the gas pressure is very, very low, however it is still there. If you take two identical objects in all respects but mass, with any measurable atmosphere, the heavier one will fall faster. Yes, the gravitational force is proportional to mass (causing objects to fall at the same acceleration in a PURE vacuum), however air drag is not related to mass, so the air drag term will become less significant with a greater gravitational force. Total f=ma, and all that. See this for more details about station keeping in LEO.
The ISS uses the Soyuz to re-boost its orbit periodically. No, it doesn't need to be firing all the time, but yes, LEO satellites need a propulsion system to counteract their drag. Airplanes do not fall out of the sky if the engines stop. They fall out of the sky when the drag force scrubs away all the kinetic energy, and the wing stalls. Likewise, an orbital object doesn't fall out of the sky right away. It takes time for the orbit to decay.
Would the decreased rate of orbital decay with the attached orbiter be a significant concern for survival over those couple of weeks it takes to mount the rescue mission? Nah, not really, the station isn't in danger of deorbiting itself that fast. Would it be significant for launching the rescue shuttle to actually launch into the correct orbit? Hell yeah.