Linux developers will never allow UDI because it is a stable driver ABI. OpenBSD developers will probably not allow UDI because it supports binary drivers, which they don't want. Probably the only major OSes that would potentially benefit from UDI are OS X and Solaris.
I tend to prefer the object-capability approach, but SELinux is another valid example of the techniques that have been invented over the last 40 years to prevent malicious software from causing harm.
Yeah, the US government has really neglected to use its authority over ICANN (except in the "OMG we can't say XXX" case), but at least in theory there is some oversight.
An autonomous ICANN is even more dangerous than what we have today. We can easily predict that the autonomous ICANN would basically do whatever the registies want: granting them perpetual, unregulated monopolies with the ability to raise prices and otherwise screw customers at will. Internet users would have no say at all.
With hardware assist (VT or AMD-V), trap-and-emulate virtualization is slower than using binary translation, but not unbearably slow. There was a paper recently from VMware about this topic.
Economics has shown that price discrimination works. If somebody is willing to pay $50 for Rise of Legends and I'm willing to pay $30, then the publisher should sell it to us at those prices. But they can't have different prices at the same time. By dropping the price steadily over time, the publisher should be able to earn more total money, and people who value games less can still get them at reasonable prices. So the fact that publishers lower their prices over time doesn't necessarily mean they're stupid or they think games "go bad" or whatever.
There is a difference. First, the dual-die process takes more power. Second, it costs more.
Putting the same number of transistors on one die takes as much power as putting them on two dice. (Unless there is some law of semiconductors that I haven't heard of.) Also, yield is lower (thus cost is higher) on a larger die than on two smaller dice.
Don't you work for AMD? I guess your attitude is not a suprise.
Your points are interesting, but that's not what Google is talking about. They're just proposing that the cable from the power supply to the motherboard inside a PC or server should only carry 12V. The power supply is still internal, and each device still has a separate supply.
No company likes the prospect of having to open up their product because some 'tard put in GPL code without their knowledge.
This myth has been debunked over and over by legal experts. If you accidentally include GPL code, then you can fix it by taking out the code; you don't have to GPL your whole program. Who's spreading ignorance now?
Yeah, I guess you could say that never buying Cisco equipment in the first place is a way of avoiding their fees. But if you already have (or need) Ciscos, OFR won't help you.
Stateless autoconfiguration is cool, but I don't think it's much of an improvement over DHCP. Neighbor discovery is just improved ARP. Honestly, NAT isn't really necessary today given that almost 40% of the IPv4 address space is unallocated.
IMO there is no first mover advantage for IPv6. Besides more addresses, most of the other good features of IPv6 have been backported to IPv4. So the only benefit is more addresses, and you only get that benefit after IPv4 addresses have run out. So switching to IPv6 before IPv4 addresses run out just ends up costing more (since router prices fall over time, the earlier you switch the more it costs).
The article doesn't mention that there is a new NSF-funded effort in the USA called the Global Environment for Network Innovations that will enable research on protocols beyond IPv6.
Without support for ATSC... this device won't receive any signal, encrypted or not, within the next few years.
The OSD doesn't have any tuner at all (analog or digital), so its tuner can never become obsolete. In a few years there will still be plenty of devices with S-video outputs.
That could potentially be fixed with a softmod up the road, though.
Er, no.
CableCard is indeed a big problem, but it looks like it may kill off most of the CE industry, not just Neuros.
I'd guess the OSD hardware is much less powerful than iTV, and the software is much less polished. But Neuros is probably banking on price and openness.
This box is an asymmetric multiprocessor with one ARM and one TI DSP, so code has to be partitioned properly to run fast enough. The TI DSP has no free development tools (AFAIK), so most hackers will not be able to work on codecs or anything else in the "data path". Also AFAIK the codecs are not open source anyway. But I can imagine lots of cool uses for this if the complexity can be managed.
But in cable boxes, Microsoft's market share is near zero. The hardware is all made by Cisco/Scienfic Atlanta and Motorola/General Instrument, and I'd guess that they also have their own software stacks.
Slashdot Mirror
Linux developers will never allow UDI because it is a stable driver ABI. OpenBSD developers will probably not allow UDI because it supports binary drivers, which they don't want. Probably the only major OSes that would potentially benefit from UDI are OS X and Solaris.
I tend to prefer the object-capability approach, but SELinux is another valid example of the techniques that have been invented over the last 40 years to prevent malicious software from causing harm.
Yeah, the US government has really neglected to use its authority over ICANN (except in the "OMG we can't say XXX" case), but at least in theory there is some oversight.
An autonomous ICANN is even more dangerous than what we have today. We can easily predict that the autonomous ICANN would basically do whatever the registies want: granting them perpetual, unregulated monopolies with the ability to raise prices and otherwise screw customers at will. Internet users would have no say at all.
Microsoft funded Xen and then copied the design almost exactly for their Viridian hypervisor.
With hardware assist (VT or AMD-V), trap-and-emulate virtualization is slower than using binary translation, but not unbearably slow. There was a paper recently from VMware about this topic.
Economics has shown that price discrimination works. If somebody is willing to pay $50 for Rise of Legends and I'm willing to pay $30, then the publisher should sell it to us at those prices. But they can't have different prices at the same time. By dropping the price steadily over time, the publisher should be able to earn more total money, and people who value games less can still get them at reasonable prices. So the fact that publishers lower their prices over time doesn't necessarily mean they're stupid or they think games "go bad" or whatever.
You write your own code; that's what proprietary software developers are supposed to do.
There is a difference. First, the dual-die process takes more power. Second, it costs more.
Putting the same number of transistors on one die takes as much power as putting them on two dice. (Unless there is some law of semiconductors that I haven't heard of.) Also, yield is lower (thus cost is higher) on a larger die than on two smaller dice.
Don't you work for AMD? I guess your attitude is not a suprise.
Google is proposing 12V between the server's internal power supply and the motherboard. Everything outside the server would still be 208V.
Your points are interesting, but that's not what Google is talking about. They're just proposing that the cable from the power supply to the motherboard inside a PC or server should only carry 12V. The power supply is still internal, and each device still has a separate supply.
No company likes the prospect of having to open up their product because some 'tard put in GPL code without their knowledge.
This myth has been debunked over and over by legal experts. If you accidentally include GPL code, then you can fix it by taking out the code; you don't have to GPL your whole program. Who's spreading ignorance now?
Yeah, I guess you could say that never buying Cisco equipment in the first place is a way of avoiding their fees. But if you already have (or need) Ciscos, OFR won't help you.
Stateless autoconfiguration is cool, but I don't think it's much of an improvement over DHCP. Neighbor discovery is just improved ARP. Honestly, NAT isn't really necessary today given that almost 40% of the IPv4 address space is unallocated.
IMO there is no first mover advantage for IPv6. Besides more addresses, most of the other good features of IPv6 have been backported to IPv4. So the only benefit is more addresses, and you only get that benefit after IPv4 addresses have run out. So switching to IPv6 before IPv4 addresses run out just ends up costing more (since router prices fall over time, the earlier you switch the more it costs).
The article doesn't mention that there is a new NSF-funded effort in the USA called the Global Environment for Network Innovations that will enable research on protocols beyond IPv6.
Almost all motherboards are ATX. BTX never really got off the ground.
Without support for ATSC ... this device won't receive any signal, encrypted or not, within the next few years.
The OSD doesn't have any tuner at all (analog or digital), so its tuner can never become obsolete. In a few years there will still be plenty of devices with S-video outputs.
That could potentially be fixed with a softmod up the road, though.
Er, no.
CableCard is indeed a big problem, but it looks like it may kill off most of the CE industry, not just Neuros.
I'd guess the OSD hardware is much less powerful than iTV, and the software is much less polished. But Neuros is probably banking on price and openness.
This box is an asymmetric multiprocessor with one ARM and one TI DSP, so code has to be partitioned properly to run fast enough. The TI DSP has no free development tools (AFAIK), so most hackers will not be able to work on codecs or anything else in the "data path". Also AFAIK the codecs are not open source anyway. But I can imagine lots of cool uses for this if the complexity can be managed.
But in cable boxes, Microsoft's market share is near zero. The hardware is all made by Cisco/Scienfic Atlanta and Motorola/General Instrument, and I'd guess that they also have their own software stacks.
The 520 uses POWER5, not PowerPC 970.
Lost in the noise is the fact that the multi-core Cells are IBM's answer to Sun's chip multiprocessor (CMP) -- i.e., Niagara and Rock.
Nope; Cell and Niagara are optimized for totally different uses.
This article only has about one sentence of new information, and it's second-hand at that. What did the FCC commissioner actually say?
I'm sure you will be able to play your home videos in MP4 format and probably recorded shows from EyeTV, but DVD-ripping software still isn't legal.
Why do we need two, brand new, incompatible protocols to push data to browsers?