They're not forcing you to do anything. If you want features that you did not pay for, you must buy a new one. But there's nothing stopping you from using the features you already paid for, and presumably thought were worth spending the money in the first place.
Although, I'll concede that Apple's sending mixed messages by proving *some* new features on old models, like the recent iPod mini update. But that's just a mixed message, not a broken promise to the masses that own other models that didn't receive such updates.
When you bought the hardware, it came with a feature list. The only requirement the manufacturer has is to make sure those features work as claimed. And no where on that feature list did they even mention the possibility that you would get more features as they released new products.
They have not done a single thing that prevents you from using any of the capabilities that you *bought*, I don't see where they're doing anything wrong.
Considering their complaint about Linux, valid or not, is its security, I don't see how this play deviates at all. The point of this compatibility later is to allow these possibly unsafe *applications* to run on a safe *operating system* by isolating their system calls, making them non-intrusive to the system's operation. Hence the product name, Padded Cell.
Although, that would really imply an app ca't even easily hurt itself, which is hardly the case. Padded Cell just has a nicer ring than Solitary Confinement.
In addition to aerospace, they made some amazing breakthroughs in submarine design as well, which cost them an unbelievable fortune.
The US certainly had the quiet sub well before they did, but by the time the Soviets brought a quiet sub out to play, it was leaps and bounds better than ours. Thankfully they were never able to afford to build too many of them.
But we know that only through archaelogical evidence.
I believe the parent's point was that this is the first case where an account of the contact itself has been preserved to the current day. Even if only through oral tradition.
I don't know much about BAe's product line, other than various military-application sensors and power supplies we've bought from them for US DoD projects.
Like Honeywell, though, I think their foundry services were started for producing parts to military requirements (namely, temperature and packaging constraints). At that point, given how low the yield is in that market, it was probably very worth their while to do other custom foundry work for defense customers, including rad-hard ASICs for god only knows who.
There are multiple implementations of rad-hard flash memory that are used regularly in space. Usually the charge pumps are removed, with external voltage sources used instead to reduce Total Ionizing Dose problems. The other major source of upsets are in Latch-Up, the behavior of which are very implementation-dependent. Some designs are practically immune to single event latch-ups, some are very susceptable.
We've been using flash in space for a while now, with little trouble. Actually, with lower error rates than SRAM (pre-correction, if ECC).
As for rad-hard flash devices, they're often purchased from BAE or Honeywell, who purchase the technology rights from the bigguns and do their own low production rate fabbing.
There just isn't much business for rad-hard devices, and the big producers don't find it worth their time and money, usually.
The Dept of State started seriously cracking the ITAR whip early last year, which probably has something to do with the lack of engineer leaks.
Aside from ITAR issues, there are also typically classified techniques and features in these devices, too. Usually focusing on robust, long-travel communication links, but often on other subsystems as well.
And even the people the Dod gets to design and manufacture their products use third party software, like vxWorks in most every application.
If a company like NASA does not already have a RTOS of their own creation, they've basically got three options:
a) Write one from scratch with their existing, unexperienced (in that field) programming staff b) Write one from scratch with the help of experts hired away from a company that already has a tried and true RTOS c) Obtain one from a company that already has a tried and true RTOS
Seems to me like option c is "faster, better, cheaper." In the good sense of the phrase.
Well, I think the reason for one cpu versus multiples has been explained well enough.... As for the proprietary OS, while vxWorks is not open source, companies using it CAN and have purchased the source code. We do it constantly for military space applications, for reason of fine-tuning, fault-tolerance modifications, and, obviously, for debugging purposes. I would imagine NASA does the same for probes the send a hundreds of millions of miles away from the nearest repair depot.
Just want to add that the info on the non-protected portions of the morphware.org website is generally quite out of date. The technologies and techniques used by the individual teams and the joint efforts have matured considerably.
This processor isn't intended for running general purpose code. Its primary design is for highly streamed code, such as front-end processing for a radar or infrared sensor. It'll host an on-chip OS whose main purpose is to bus data on and off the chip, and handle resource allocation. But 90%+ of those resources are to be dedicated to number crunching in a deterministic fashion, allowing for high parallelism.
The "network" is merely a dynamic switching layer between onchip components.
What's maybe not clear from the information in these links is that this chip is not designed for general purpose computing. It's part of DARPA's Polymorphus Computing Architecture plan, which is to make a processor than can be blazingly fast on threaded code AND streaming code, and can handle switching between both with speed.
These processors will be used in harsh conditions (space, high-G sensor systems, etc.), and require low power and small packaging. The primary selector model for the competition is SWEPT (Size, Weight, Efficiency, Power, and Time).
The UT TRIPS chip is one of 8 architectures competing in the PCA bid. I'm on a cometing team (Raytheon, supporting USC's MONARCH), so I'm highly biased, but when you get down to it, TRIPS is really the least revolutionary of the designs.
And on that note, Apple has been going around asking large engineering houses if they'd be willing to test MacOSX versions of their prefered CAD software if betas became available.
Unfortuantely, the group that was approached within my company declined (who uses exclusively Pro/E), but it does seem to demonstrate Apple's interest in this arena.
I know that from the PowerPC 603 core onward, there was no support for non-native isntruction sets. I'm rather hesitant to believe otherwise abotu earlier chips, too. I always thought that the early PoweRPC MacOS support for 68K code was entirely software-based. Maybe I'm wrong, though. Any idea what chips ahd the M68K core?
As someone who works almost exclusively in PowerPC assembly, I notice a very large software development market that relies heavily on assembly programming that no one has mentioned. In embedded development, the developer works much closer to the hardware than in other markets.... While embedded operating systems provide the abstraction to allow application programming, almost every new piece of hardware needs porting work. The bootrom is obviously best written in assembly, as are many of the low-level functions the OS requires.
In the related field of Built-In Test software (Self-Test, Operational Ready Tests, On-Board Diagnostics, whatever you want to call them), there is also a high dependency on knowing exactly what the processor (and bridges) are doing and what their exact timing is. So that is another area that demands assembly knowledge. Especially if you're writing tests for the processor itself.
Not to mention, anyone working on compilers or operating systems in general will need the assembly and architectural knowledge.
The proof comes not form the end result. If that's all you're observing, you have of idea how close you came to choosing another target.
But you're not accounting the huge amount of data being dumped by for the EKV and the target missile. By using this information, you can confirm how early and with what level of confidence the EKV disregarded the decoy and cose the proper target.
What I find amusing in all this complaining that National Missile Defense isn't achievable, people keep citing these last four tests of the EKV for their proof. Never mind that the two times the tests failed, it was because the old-tech rockets had failures. Every time the kill vehicle was properly separated from is rocket, it has successfully idenified and tracked its targets.
Admittedly, the system can't work if the delivery rockets keep breaking, but the hard stuff that everyone says can't be done, has worked flawlessly in every test so far.
People like this can cause a FUD snowball picking up people who know even less than he does, unfortunately.
The fault behind his premis is that no where does he acknowledge that in order to install your altered version of the OS, you need to be root. Or bypass the BIOS security and boot from an alternative device.
If a would-be hacker can establish super-user access to install his/her modified kernel, a serious security flaw is present. One that IS best correct in an open-source model. Such flaws will always exist, but sure as hell shouldn't be trivial.
If said hacker could bypass BIOS security, that is a non-OS issue, completely unrelated to open or closed source models. If you want to take this into consideration, any "hacker" could easily bypass the currently installed OS and install their own, be it NT, Linux, or MS-DOS 2.11.
Slashdot Mirror
Trimaran, originally developed for the Itanium, has also proven to be an extremely capable compiler for parallel processors.
They're not forcing you to do anything. If you want features that you did not pay for, you must buy a new one. But there's nothing stopping you from using the features you already paid for, and presumably thought were worth spending the money in the first place.
Although, I'll concede that Apple's sending mixed messages by proving *some* new features on old models, like the recent iPod mini update. But that's just a mixed message, not a broken promise to the masses that own other models that didn't receive such updates.
When you bought the hardware, it came with a feature list. The only requirement the manufacturer has is to make sure those features work as claimed. And no where on that feature list did they even mention the possibility that you would get more features as they released new products.
They have not done a single thing that prevents you from using any of the capabilities that you *bought*, I don't see where they're doing anything wrong.
Considering their complaint about Linux, valid or not, is its security, I don't see how this play deviates at all. The point of this compatibility later is to allow these possibly unsafe *applications* to run on a safe *operating system* by isolating their system calls, making them non-intrusive to the system's operation. Hence the product name, Padded Cell.
Although, that would really imply an app ca't even easily hurt itself, which is hardly the case. Padded Cell just has a nicer ring than Solitary Confinement.
In addition to aerospace, they made some amazing breakthroughs in submarine design as well, which cost them an unbelievable fortune.
The US certainly had the quiet sub well before they did, but by the time the Soviets brought a quiet sub out to play, it was leaps and bounds better than ours. Thankfully they were never able to afford to build too many of them.
But we know that only through archaelogical evidence.
I believe the parent's point was that this is the first case where an account of the contact itself has been preserved to the current day. Even if only through oral tradition.
I don't know much about BAe's product line, other than various military-application sensors and power supplies we've bought from them for US DoD projects.
Like Honeywell, though, I think their foundry services were started for producing parts to military requirements (namely, temperature and packaging constraints). At that point, given how low the yield is in that market, it was probably very worth their while to do other custom foundry work for defense customers, including rad-hard ASICs for god only knows who.
There are multiple implementations of rad-hard flash memory that are used regularly in space. Usually the charge pumps are removed, with external voltage sources used instead to reduce Total Ionizing Dose problems. The other major source of upsets are in Latch-Up, the behavior of which are very implementation-dependent. Some designs are practically immune to single event latch-ups, some are very susceptable.
We've been using flash in space for a while now, with little trouble. Actually, with lower error rates than SRAM (pre-correction, if ECC).
As for rad-hard flash devices, they're often purchased from BAE or Honeywell, who purchase the technology rights from the bigguns and do their own low production rate fabbing.
There just isn't much business for rad-hard devices, and the big producers don't find it worth their time and money, usually.
The Dept of State started seriously cracking the ITAR whip early last year, which probably has something to do with the lack of engineer leaks.
Aside from ITAR issues, there are also typically classified techniques and features in these devices, too. Usually focusing on robust, long-travel communication links, but often on other subsystems as well.
And even the people the Dod gets to design and manufacture their products use third party software, like vxWorks in most every application.
If a company like NASA does not already have a RTOS of their own creation, they've basically got three options:
a) Write one from scratch with their existing, unexperienced (in that field) programming staff
b) Write one from scratch with the help of experts hired away from a company that already has a tried and true RTOS
c) Obtain one from a company that already has a tried and true RTOS
Seems to me like option c is "faster, better, cheaper." In the good sense of the phrase.
Well, I think the reason for one cpu versus multiples has been explained well enough.... As for the proprietary OS, while vxWorks is not open source, companies using it CAN and have purchased the source code. We do it constantly for military space applications, for reason of fine-tuning, fault-tolerance modifications, and, obviously, for debugging purposes. I would imagine NASA does the same for probes the send a hundreds of millions of miles away from the nearest repair depot.
I guess this is the point where I get to put my foot in my mouth. I think I'll be hiding my nametag at the forum next week.
Out of curiosity, what's the resource utilization like in single-threaded mode? Is it possible to keep all/most the ALUs busy?
I'm going to go hide in embarassment now...
Just want to add that the info on the non-protected portions of the morphware.org website is generally quite out of date. The technologies and techniques used by the individual teams and the joint efforts have matured considerably.
This processor isn't intended for running general purpose code. Its primary design is for highly streamed code, such as front-end processing for a radar or infrared sensor. It'll host an on-chip OS whose main purpose is to bus data on and off the chip, and handle resource allocation. But 90%+ of those resources are to be dedicated to number crunching in a deterministic fashion, allowing for high parallelism.
The "network" is merely a dynamic switching layer between onchip components.
What's maybe not clear from the information in these links is that this chip is not designed for general purpose computing. It's part of DARPA's Polymorphus Computing Architecture plan, which is to make a processor than can be blazingly fast on threaded code AND streaming code, and can handle switching between both with speed.
These processors will be used in harsh conditions (space, high-G sensor systems, etc.), and require low power and small packaging. The primary selector model for the competition is SWEPT (Size, Weight, Efficiency, Power, and Time).
The UT TRIPS chip is one of 8 architectures competing in the PCA bid. I'm on a cometing team (Raytheon, supporting USC's MONARCH), so I'm highly biased, but when you get down to it, TRIPS is really the least revolutionary of the designs.
And on that note, Apple has been going around asking large engineering houses if they'd be willing to test MacOSX versions of their prefered CAD software if betas became available.
Unfortuantely, the group that was approached within my company declined (who uses exclusively Pro/E), but it does seem to demonstrate Apple's interest in this arena.
Okay, I can forgive all the other typical non-tech-savvy errors, but what's this about QNX being the only commercial microkernel OS?
What's Mac OS X, chopped liver?
I would imagine the code *is* read sequentially. The flash image would be decompressed/decrypted in a single copy to RAM, where it would execute from.
I know that from the PowerPC 603 core onward, there was no support for non-native isntruction sets. I'm rather hesitant to believe otherwise abotu earlier chips, too. I always thought that the early PoweRPC MacOS support for 68K code was entirely software-based. Maybe I'm wrong, though. Any idea what chips ahd the M68K core?
As someone who works almost exclusively in PowerPC assembly, I notice a very large software development market that relies heavily on assembly programming that no one has mentioned. In embedded development, the developer works much closer to the hardware than in other markets.... While embedded operating systems provide the abstraction to allow application programming, almost every new piece of hardware needs porting work. The bootrom is obviously best written in assembly, as are many of the low-level functions the OS requires.
In the related field of Built-In Test software (Self-Test, Operational Ready Tests, On-Board Diagnostics, whatever you want to call them), there is also a high dependency on knowing exactly what the processor (and bridges) are doing and what their exact timing is. So that is another area that demands assembly knowledge. Especially if you're writing tests for the processor itself.
Not to mention, anyone working on compilers or operating systems in general will need the assembly and architectural knowledge.
The proof comes not form the end result. If that's all you're observing, you have of idea how close you came to choosing another target.
But you're not accounting the huge amount of data being dumped by for the EKV and the target missile. By using this information, you can confirm how early and with what level of confidence the EKV disregarded the decoy and cose the proper target.
What I find amusing in all this complaining that National Missile Defense isn't achievable, people keep citing these last four tests of the EKV for their proof. Never mind that the two times the tests failed, it was because the old-tech rockets had failures. Every time the kill vehicle was properly separated from is rocket, it has successfully idenified and tracked its targets.
Admittedly, the system can't work if the delivery rockets keep breaking, but the hard stuff that everyone says can't be done, has worked flawlessly in every test so far.
People like this can cause a FUD snowball picking up people who know even less than he does, unfortunately.
The fault behind his premis is that no where does he acknowledge that in order to install your altered version of the OS, you need to be root. Or bypass the BIOS security and boot from an alternative device.
If a would-be hacker can establish super-user access to install his/her modified kernel, a serious security flaw is present. One that IS best correct in an open-source model. Such flaws will always exist, but sure as hell shouldn't be trivial.
If said hacker could bypass BIOS security, that is a non-OS issue, completely unrelated to open or closed source models. If you want to take this into consideration, any "hacker" could easily bypass the currently installed OS and install their own, be it NT, Linux, or MS-DOS 2.11.