I really don't want to have an implant in my head for people to "keylog" or pop up spam, et al.
However, this could really benefit medical science by giving the physically disabled a means to work computers more easily. Not only that but this technology can be used in medical science. One could control a prosthesis or other equipment with much greater control. Accident victims and soldiers who have lost limbs may even be able to regain near 100% function, even with something as intricate as a working hand. People with debilitating diseases or conditions, Stephen Hawking comes to mind, would be able to enjoy much more independence with the right equipment being driven by their still very capable mind.
While the potential for abuse exists and must be guarded against, I see the potential benefits making this technology worth pursuing.
At a time when cash flow is low, being able to walk away from the immediate cost of pursuing the lawsuits really helps AMD out. They no longer have to pay all the lawyers who were pursuing this case. They can use the difference to shore up profits or even invest in developing new product.
I'm sure they could have gotten a lot more with a final settlement but at what cost? Now (most) everything is settled and they can shift their focus back to trying to catch up to Intel.
They say they want a better source for CO2 than the sea water...
If only there were some source for CO2 that was readily available. One which is rich in CO2, *breathe* or even had a surplus. *breathe* We could even help to reduce the quantity of CO2 in this source that might have too much due to pollution... *breathe*
Wouldn't it be cool if there was a source as plentiful as the air we breathe...
Back in the 60's we were competing against the "Ruskies" and NASA had a much bigger budget (when adjusted for inflation). They threw money at the engineering teams and told them to make it happen.
These days, NASA is operating on a fraction of what it once had.
FYI, most, if not all aircraft avionics are based on ARINC-653 time-and-space partitioned hard real-time operating systems, and typically implemented with hardcore languages like Ada. When lives are on the line, you ask for nothing less.
Once the FAA dropped the mandate for Ada in avionics systems, many new projects at the company I used to work for were developed in C and C++. Quite frankly, it was difficult to find people who wanted to develop software in Ada. And after working in it myself for several years, I was very happy to make the switch myself. Don't get me wrong, Ada is a fine language but there are a few universal truths about safety critical development that are quite simply inescapable.
A good process with well thought out coding standards allows good programmers to write quality code in any language.
Poor programmers can write bad code in any language.
I've seen some pretty bad programmers write simply dreadful Ada code. Which is really unfortunate. But it underscores the issue that no matter how great the language may be on paper, it's the programmers who ultimately determine the quality of the software written. And when it comes to recruiting developers, it's a lot easier (and cheaper) to find people willing to work on C/C++ than it is to find Ada developers.
A bit of FUD here I think - unless I read TFA wrong, the entire thing is under investigation and no one is saying anything for at least a month. The autopilot apparently sensed the need for more thrust and warned the pilots of this. It might be premature to say that a software problem is the likely cause of failure...
Another possible explanation for this failure is that the plane ran out of fuel. An experienced pilot I know who has flown that China-Heathrow route explained how planes flying out various airports in China are held to lower altitude (20-24K feet) for longer periods of time. This causes them to burn more fuel, sometimes leaving insufficient reserves to make it all the way to Heathrow without stopping to top the tanks off.
While I have no direct evidence to support this theory, it is plausible that the plane simply ran out of fuel a few miles short of the runway.
These OSes typically are not custom designed. (although a few in older aircraft are) There are a few commercial rtoses that are commonly used, they are specially marketed to the avionics industry as conforming the DO-178B standard. The most common would probably be Integrity-178B sold by Green Hills Software and VxWorks 653 Platform sold by Wind River.
When the avionics for the 777 were first developed, operating systems like Integrity-178B and VxWorks 653 just didn't exist. I worked for one of the subcontractors that supplied avionics for the 777 (and other planes) back in the 90's. Before specs like ARINC 653 came about (653-1 was only approved in 2003 mind you), there was no commercial RTOS that we could certify to DO-178B standards. We had in-house developed environments that were ported from platform to platform. Now, we took an active role in getting the 653 standard ratified and worked with the RTOS developers to bring their environments on board. But at the time the avionics for the 777 were developed, none of that existed.
So while pretty much all current development projects all use 653 compliant RTOS', it wasn't so long ago that the engineers were developing their operating systems by hand.
I hear a lot of people saying this and I can only assume you have absolutely no idea how a CPU is made. Do you have any idea how many advances in materials science are required for every new generation of microprocessor? Can you even begin to conceive the complexity of building something so small that quantum interactions are a major design concern? Actually, I can. Since I work as a designer for a major silicon company and I know a lot about what goes into the latest and greatest processors.
Realistically, we've done a great deal of refinement but it's only just been incremental steps for a long time. There's nothing fundamentally different between how we make chips today and how they've been made for years. Sure, we use different materials and our processes are much more refined than they ever were before. But what fundamental change have we made in the way we make chips? Do we not lay them down layer by layer on the wafer? So what if the wafer is bigger or if the density has increased or if we use different chemicals to deal with different issues as we keep getting smaller? It's still fundamentally the same process we've been doing for decades.
The same thing applies to the cores themselves. Sure, they have on board cache and they prefetch instructions based on predictive algorithms where they didn't before. Each "core" has multiple RISC cores that execute the microcode and the scheduler can run operations out of order. We've brought the floating point processor on die. We've added instructions. We've added new bus topologies. But how is any of that considered "breakthrough"? It's just a refinement of what we already had. It's added silicon to speed things up by minimizing our bottlenecks and exploiting methods to improve efficiency. But what fundamental change has been made since the 8086 or even the 8080? Really, not much. Just repetitive refinement. No real "breakthrough" has been introduced by either of the major players in the x86 world.
Innovation on CPUs doesn't necessarily have to consist of obvious "breakthroughs". CPU performance has increased exponentially over those last 20 years due to incremental, evolutionary improvements. Opteron wasn't exactly a "breakthrough" either: it just extended Intel's long-in-the-tooth instruction set to 64-bits, providing backwards compatibility to 32-bit applications. Its success wasn't because of any huge breakthrough, but because that's what customers were demanding; customers didn't want the Itanium and its unproven performance which required huge changes in compilers and how software was written. I agree. Even with the competition AMD offered, we still haven't seen much in the way of any real "breakthrough" in desktop CPU design. The design of modern x86 chips is certainly much more complex what with the predictive branching, out-of-order execution, etc. But really, how is that any kind of a "breakthrough"? It's not much more than piling on more transistors to make better use of a design that's been around for decades. At their core (pun intended) the modern x86 chips don't qualify as any kind of "breakthrough". The only thing competition did for desktop PCs is to save us from the Itanium and make the chips run faster and cooler than they did before.
Yes, that and as has been alluded to in other posts here, bio-tech research is so much more complicated than processor design. Also, the repercussions of making mistakes in silicon design have virtually no impact when compared to what happens when your drug is found to cause a serious side effect in even a minuscule fraction of the people who take it.
It really is an apples/oranges comparison. The industries have basically nothing in common.
The only reason Intel has had any motivation to come up with any real breakthroughs in the last 20 years is AMD eating their lunch with the Opetron. All they had in 2003 was the Itanium and we all know how big of a turd that was.
This is exactly what's happening.
As a matter of fact, some of the "single core" chips AMD (and Intel for that matter) sells are dual core wafers where one of the cores doesn't work.
Now that the native 4 core chips are being sold, you'll see the factory defects as triple core, or even dual or single core depending on how many cores actually work.
Same thing happens with speed ratings. Minor variances and flaws in manufacturing affect the maximum clock speed of any given core. They're tested in the factory and dropped into speed bins. The ones that can clock the highest are sold for the highest price. The ones that don't make the cut are sold for less money at lower speed ratings rather than being thrown away.
If you were running a chip company and you could sell some of your defects as downgraded parts or throw them away, which would you do?
I'd say you've got it entirely backwards. It's been my experience that those who make themselves irreplaceable in any one pigeon hole make themselves unpromotable. The specialists get stuck doing the same thing forever until the technology evolves and they're left behind with no usable job skills.
I've been developing software for 15 years. I've been in several industries doing many different things from real time safety critical embedded software to device drivers to building GUI interfaces and databases. And yes, I got my start doing IT while I was in college. I managed to dance around the office politics and change jobs at appropriate times and have landed in a very good situation, becoming a lead architect on a software project even though that wasn't why they hired me just 6 months ago. I'm the generalist with a diverse background, including IT, that the author talks about. I'm having great success making some very significant contributions because I learned a long time ago how to learn. I got here, knew what I had to grasp about the project to come up to speed quickly and what I could figure out later. And now I'm the lead planning our next big upgrade because I can do it. I've already directed one small upgrade since I arrived.
You seem happy entrenching yourself so I say more power to you. But my experience says this guy hit the nail on the head.
Standard def is 480i = 640x480 pixels but only half every "pass". 640x480/2 = 153,600 pixels.
Top of the line HD is 1080p = 1920x1080 pixels with all of them every pass. 1920x1080 = 2,073,600 pixels.
2,073,600/153,600 = 13.5 times as many pixels. Factor in the compression and then add the overhead and 9:1 disk usage isn't all that unreasonable.
Slashdot Mirror
I really don't want to have an implant in my head for people to "keylog" or pop up spam, et al. However, this could really benefit medical science by giving the physically disabled a means to work computers more easily. Not only that but this technology can be used in medical science. One could control a prosthesis or other equipment with much greater control. Accident victims and soldiers who have lost limbs may even be able to regain near 100% function, even with something as intricate as a working hand. People with debilitating diseases or conditions, Stephen Hawking comes to mind, would be able to enjoy much more independence with the right equipment being driven by their still very capable mind. While the potential for abuse exists and must be guarded against, I see the potential benefits making this technology worth pursuing.
At a time when cash flow is low, being able to walk away from the immediate cost of pursuing the lawsuits really helps AMD out. They no longer have to pay all the lawyers who were pursuing this case. They can use the difference to shore up profits or even invest in developing new product. I'm sure they could have gotten a lot more with a final settlement but at what cost? Now (most) everything is settled and they can shift their focus back to trying to catch up to Intel.
They say they want a better source for CO2 than the sea water...
If only there were some source for CO2 that was readily available. One which is rich in CO2, *breathe* or even had a surplus. *breathe* We could even help to reduce the quantity of CO2 in this source that might have too much due to pollution... *breathe*
Wouldn't it be cool if there was a source as plentiful as the air we breathe...
Back in the 60's we were competing against the "Ruskies" and NASA had a much bigger budget (when adjusted for inflation). They threw money at the engineering teams and told them to make it happen. These days, NASA is operating on a fraction of what it once had.
Once the FAA dropped the mandate for Ada in avionics systems, many new projects at the company I used to work for were developed in C and C++. Quite frankly, it was difficult to find people who wanted to develop software in Ada. And after working in it myself for several years, I was very happy to make the switch myself. Don't get me wrong, Ada is a fine language but there are a few universal truths about safety critical development that are quite simply inescapable.
I've seen some pretty bad programmers write simply dreadful Ada code. Which is really unfortunate. But it underscores the issue that no matter how great the language may be on paper, it's the programmers who ultimately determine the quality of the software written. And when it comes to recruiting developers, it's a lot easier (and cheaper) to find people willing to work on C/C++ than it is to find Ada developers.
Another possible explanation for this failure is that the plane ran out of fuel. An experienced pilot I know who has flown that China-Heathrow route explained how planes flying out various airports in China are held to lower altitude (20-24K feet) for longer periods of time. This causes them to burn more fuel, sometimes leaving insufficient reserves to make it all the way to Heathrow without stopping to top the tanks off.
While I have no direct evidence to support this theory, it is plausible that the plane simply ran out of fuel a few miles short of the runway.
When the avionics for the 777 were first developed, operating systems like Integrity-178B and VxWorks 653 just didn't exist. I worked for one of the subcontractors that supplied avionics for the 777 (and other planes) back in the 90's. Before specs like ARINC 653 came about (653-1 was only approved in 2003 mind you), there was no commercial RTOS that we could certify to DO-178B standards. We had in-house developed environments that were ported from platform to platform. Now, we took an active role in getting the 653 standard ratified and worked with the RTOS developers to bring their environments on board. But at the time the avionics for the 777 were developed, none of that existed.
So while pretty much all current development projects all use 653 compliant RTOS', it wasn't so long ago that the engineers were developing their operating systems by hand.
Yes, that and as has been alluded to in other posts here, bio-tech research is so much more complicated than processor design. Also, the repercussions of making mistakes in silicon design have virtually no impact when compared to what happens when your drug is found to cause a serious side effect in even a minuscule fraction of the people who take it. It really is an apples/oranges comparison. The industries have basically nothing in common.
No. I'm saying that Intel wasn't even bothering to come up with any breakthroughs until another company started to give them some real competition.
The only reason Intel has had any motivation to come up with any real breakthroughs in the last 20 years is AMD eating their lunch with the Opetron. All they had in 2003 was the Itanium and we all know how big of a turd that was.
This is exactly what's happening. As a matter of fact, some of the "single core" chips AMD (and Intel for that matter) sells are dual core wafers where one of the cores doesn't work. Now that the native 4 core chips are being sold, you'll see the factory defects as triple core, or even dual or single core depending on how many cores actually work. Same thing happens with speed ratings. Minor variances and flaws in manufacturing affect the maximum clock speed of any given core. They're tested in the factory and dropped into speed bins. The ones that can clock the highest are sold for the highest price. The ones that don't make the cut are sold for less money at lower speed ratings rather than being thrown away. If you were running a chip company and you could sell some of your defects as downgraded parts or throw them away, which would you do?
I'd say you've got it entirely backwards. It's been my experience that those who make themselves irreplaceable in any one pigeon hole make themselves unpromotable. The specialists get stuck doing the same thing forever until the technology evolves and they're left behind with no usable job skills. I've been developing software for 15 years. I've been in several industries doing many different things from real time safety critical embedded software to device drivers to building GUI interfaces and databases. And yes, I got my start doing IT while I was in college. I managed to dance around the office politics and change jobs at appropriate times and have landed in a very good situation, becoming a lead architect on a software project even though that wasn't why they hired me just 6 months ago. I'm the generalist with a diverse background, including IT, that the author talks about. I'm having great success making some very significant contributions because I learned a long time ago how to learn. I got here, knew what I had to grasp about the project to come up to speed quickly and what I could figure out later. And now I'm the lead planning our next big upgrade because I can do it. I've already directed one small upgrade since I arrived. You seem happy entrenching yourself so I say more power to you. But my experience says this guy hit the nail on the head.
Standard def is 480i = 640x480 pixels but only half every "pass". 640x480/2 = 153,600 pixels. Top of the line HD is 1080p = 1920x1080 pixels with all of them every pass. 1920x1080 = 2,073,600 pixels. 2,073,600/153,600 = 13.5 times as many pixels. Factor in the compression and then add the overhead and 9:1 disk usage isn't all that unreasonable.