"If you act without reasonable care, and this causes losses, you may be responsible for them."
In other words, if your authentication info gets stolen by a virus that's in the wild, and would have been blocked by up-to-date antivirus software, you're responsible for what happens as a result.
This does not appear to be intended to make the customer's software a scapegoat, just to hold people responsible for failure to take reasonable steps to protect their accounts. It is still very much in the bank's interest to improve account security measures, as most losses will not be clearly attributable to a cause that would allow this provision to be invoked.
Parallel SCSI is very, very dead, but it's being killed off by SAS, not SATA. SAS is also killing off Fibre Channel disk drives, as it makes more sense these days to use SAS within the RAID array, and then use Fibre Channel to connect to the hosts.
I don't know what they're smoking that makes them think infiniband will replace all of this, but I want some. Infiniband is great for clusters, but putting it inside a laptop is idiotic.
Firewire is certainly more niche than USB, but in its niche, it's very good. That may be why the FCC has mandated that hi-def digital cable providers in the United States provide firewire-equipped cable boxes to any customers that ask for them. If you're doing media capture, it's really an excellent interface. If you want to plug in general purpose peripherals, USB is usually a better fit.
Patents are usually bought for the purpose of licensing them, not litigating them. This patent is clearly being hyped as a litigation threat, to terrify all the big tech companies into buying it to protect themselves. If it was really such a goldmine, they'd be able to get investors.
The bravado here may seem surprising, but there's a good reason why the tone of these claims is so different from the tone of typical patent trolling. A typical patent troll will generally be vague about the applicability of a patent, except when discussing a case that's already been filed. Naming a dozen rather different specific technologies gives a defendant lots of ammunition to argue that the technique is obvious, due to the ubiquity admitted by the plaintiff, or to demonstrate prior art in the common technological heritage of all of them.
These claims are simply intended to drive up the value of the patent at auction, by making the big players terrified of letting anyone else get ahold of it. Were it really so valuable, the holder would litigate it themselves. The fact that they're unloading it for some sure money now is a strong indication of how weak they feel it would be in court.
What I was referring to (lazily) was tagged quality of service. Instead of claiming to give me 8 Mb/s that they can't even approach at any sustained rate, just give me a certain small amount of high-priority burst bandwidth per month, and let me, or my applications, or my OS, or my hardware appliances decide what to tag. Beyond that, I'll use anything I can for my bittorrent sessions, and nobody's high-priority traffic will suffer.
Of course, they'll never do this, because they'd have to admit just how little bandwidth they can really guarantee to anything short of a T-1.
So shape everything. The alleged "flaw" in TCP that bittorrent exploits is a behavior enforced by the local host's IP stack, which the ISP blindly trusts to responsibly throttle everything. With a little IP stack tuning you can make a single socket exploit this same blind trust just as well as P2P apps do with dozens of sockets.
ISPs should never trust clients to responsibly throttle everything. The problem is that if they want to throttle us irrespective of our content, then they're going to hurt their performance on bandwidth tests, and then they'll have to admit that they have far, far less bandwidth than they're advertising.
Weighted TCP is a great idea. That doesn't change the fact that net neutrality is a good thing, or that traffic shaping is a better fix for network congestion than forging RST packets.
The author of this article is clearly exploiting the novelty of a technological idea to promote his slightly related political agenda, and that's deplorable.
IE8 is using ActiveX *internally* because it can't natively render the html OBJECT. Invoking ActiveX triggers XSS checks. The bottom line is that they technically pass the test, but many web designers will do things that really should work, but won't in IE8. It's not because MS is cheating, just that they haven't fully implemented this feature, and they're erring on the side of caution with their partial implementation. Regardless of standards compliance, they'll need to fix this before IE8 is released.
I won't disagree with the assertion that the internet is a game-changer when it comes to criminal investigations, but the idea that we should castrate it for this reason is ridiculous. The dinosaur who raised this complaint is clearly a digital immigrant. Most of his generation lacks the level of familiarity necessary to effectively investigate crimes involving the internet. The problem goes beyond a simple matter of training. A good investigator needs an intuitive understanding of how people interact with their world, including the internet, more than they need an intimate understanding of protocols.
The next generation of investigators will be digital natives. They'll have grown up with the web, email, blogs, message boards, IM, flickr, youtube, social networking, and the like. They won't all have CCNAs, but they'll have a sufficient understanding of how people use the internet to know when to bring in forensic experts.
The transition will be difficult. The digital immigrants with extensive investigative experience and the digital natives who are novices in their profession will have to cooperate and exchange their knowledge and wisdom, and in the meantime, some criminals will slip through the cracks. That's the price of progress.
If I had mod points, I'd mod this insightful, not funny. There are a lot of HPC projects that were planning to use Barcelona, that were held back by the TLB bug. I'm sure anything approaching this magnitude already had a contract with AMD that includes guaranteed delivery dates and penalties, either directly or through the OEM. If you don't have a signed contract with AMD or with someone who has one with AMD, you're going to have to wait in line.
I skimmed the complaint, and was reminded of some bragging Intel did about improved dependency disambiguation in the Core microarchitecture that allowed them to expand from 3 pipelines to 4 pipelines and shorten the pipelines substantially, which gave a major performance boost over the Netburst microarchitecture. That could explain why this is going to court only now. The discussion probably didn't become adversarial until Intel started selling allegedly-infringing processors to the public, even though they were working on such designs in 2001.
Actually, if you want to test your surveillance of an enemy's communications networks, deliberately disrupting their communications can be a very worthwhile experiment.
It's notable that Iran is now supposedly cut off entirely. If the Iranian government has any secret communications links, it'll be much easier to tell when they're using them.
As pure and clean as microkernels may be, they're an engineering nightmare for large, general-purpose operating systems. There are lots of microkernel implementations out there, many of them very successful in certain niche applications, but none of them have taken off for general-purpose use the way monolithic kernels have. A general-purpose operating system has to make a lot of design compromises, and the modular-monolithic design most modern OSes use is a practical implementation of the concepts of microkernel design that have proved useful in the real world, while sticking to monolithic methods where they're working fine or the cost of redesigning them is prohibitive.
Linux keeps getting more microkernel-like over time. More and more kernel functions are being moved into userspace helpers. More kernel work is being pushed into workqueues or executed asynchronously in separate threads. In the realtime kernel, even hardware interrupt handlers are prioritized, scheduled threads. We have filesystems and character drivers in userspace. Linux already has most of the basic infrastructure you'd need to implement a true microkernel, and developers are taking advantage of this gradually, using the sort of iterative development method that drives academic purists nuts, but works very well.
In contrast, the design of Windows Vista took a sharp turn from its predecessors, moving a huge amount of functionality out into userspace. The result is much less susceptible to BSODs, but it was also way behind schedule, released missing major intended features (WinFS?), it's slow, and users hate it so much that they're asking OEMs to install XP instead. Sure, Vista may be more interesting technologically, but if you actually want to use your computer to do something useful, it sucks compared to XP.
Keep doing research, Andy. We'll keep writing kernels that are portable from cell phones to mainframes.
No matter how many terabits of data you can cram through a cable per second, there will always be a need for low-latency. A planet-wide star topology network, without the many levels of hierarchy we have today, would have latency that would be completely unacceptable for a great many applications. As long as our communication is subject to the speed of light, we will have LANs.
In my anecdotal experience, desktop Linux is driving Mac sales. Whenever I point a frustrated Windows user towards Linux, they never go back to Windows. Some of them stick with Linux, and some of them buy Macs, but all of them learn that it's not really all that hard to switch. Those that end up as Mac users will have no difficulty switching back to Linux if Apple stops being worth the price premium to them.
Oops, I was vague. My results were with UDP NFS, which is much simpler to tune. As you noted in your reply, it's possible to tune iSCSI to similar performance levels, but doing so without sacrificing latency is rather difficult. My point was that simpler protocols (like FCoE) make it much easier to get the most out of the hardware.
For what it's worth, the NFS server in my testing was using Fibre Channel storage.
Slashdot Mirror
"If you act without reasonable care, and this causes losses, you may be responsible for them."
In other words, if your authentication info gets stolen by a virus that's in the wild, and would have been blocked by up-to-date antivirus software, you're responsible for what happens as a result.
This does not appear to be intended to make the customer's software a scapegoat, just to hold people responsible for failure to take reasonable steps to protect their accounts. It is still very much in the bank's interest to improve account security measures, as most losses will not be clearly attributable to a cause that would allow this provision to be invoked.
If by "pretty cool hardware" you mean "pen and paper" then yes.
Parallel SCSI is very, very dead, but it's being killed off by SAS, not SATA. SAS is also killing off Fibre Channel disk drives, as it makes more sense these days to use SAS within the RAID array, and then use Fibre Channel to connect to the hosts.
I don't know what they're smoking that makes them think infiniband will replace all of this, but I want some. Infiniband is great for clusters, but putting it inside a laptop is idiotic.
Firewire is certainly more niche than USB, but in its niche, it's very good. That may be why the FCC has mandated that hi-def digital cable providers in the United States provide firewire-equipped cable boxes to any customers that ask for them. If you're doing media capture, it's really an excellent interface. If you want to plug in general purpose peripherals, USB is usually a better fit.
Patents are usually bought for the purpose of licensing them, not litigating them. This patent is clearly being hyped as a litigation threat, to terrify all the big tech companies into buying it to protect themselves. If it was really such a goldmine, they'd be able to get investors.
The bravado here may seem surprising, but there's a good reason why the tone of these claims is so different from the tone of typical patent trolling. A typical patent troll will generally be vague about the applicability of a patent, except when discussing a case that's already been filed. Naming a dozen rather different specific technologies gives a defendant lots of ammunition to argue that the technique is obvious, due to the ubiquity admitted by the plaintiff, or to demonstrate prior art in the common technological heritage of all of them.
These claims are simply intended to drive up the value of the patent at auction, by making the big players terrified of letting anyone else get ahold of it. Were it really so valuable, the holder would litigate it themselves. The fact that they're unloading it for some sure money now is a strong indication of how weak they feel it would be in court.
You're right, I was being extremely vague.
What I was referring to (lazily) was tagged quality of service. Instead of claiming to give me 8 Mb/s that they can't even approach at any sustained rate, just give me a certain small amount of high-priority burst bandwidth per month, and let me, or my applications, or my OS, or my hardware appliances decide what to tag. Beyond that, I'll use anything I can for my bittorrent sessions, and nobody's high-priority traffic will suffer.
Of course, they'll never do this, because they'd have to admit just how little bandwidth they can really guarantee to anything short of a T-1.
So shape everything. The alleged "flaw" in TCP that bittorrent exploits is a behavior enforced by the local host's IP stack, which the ISP blindly trusts to responsibly throttle everything. With a little IP stack tuning you can make a single socket exploit this same blind trust just as well as P2P apps do with dozens of sockets.
ISPs should never trust clients to responsibly throttle everything. The problem is that if they want to throttle us irrespective of our content, then they're going to hurt their performance on bandwidth tests, and then they'll have to admit that they have far, far less bandwidth than they're advertising.
Weighted TCP is a great idea. That doesn't change the fact that net neutrality is a good thing, or that traffic shaping is a better fix for network congestion than forging RST packets.
The author of this article is clearly exploiting the novelty of a technological idea to promote his slightly related political agenda, and that's deplorable.
IE8 is using ActiveX *internally* because it can't natively render the html OBJECT. Invoking ActiveX triggers XSS checks. The bottom line is that they technically pass the test, but many web designers will do things that really should work, but won't in IE8. It's not because MS is cheating, just that they haven't fully implemented this feature, and they're erring on the side of caution with their partial implementation. Regardless of standards compliance, they'll need to fix this before IE8 is released.
I saw prior art for this in Apocalypse Now. You just don't lead them as much.
...on how good she is in bed.
I won't disagree with the assertion that the internet is a game-changer when it comes to criminal investigations, but the idea that we should castrate it for this reason is ridiculous. The dinosaur who raised this complaint is clearly a digital immigrant. Most of his generation lacks the level of familiarity necessary to effectively investigate crimes involving the internet. The problem goes beyond a simple matter of training. A good investigator needs an intuitive understanding of how people interact with their world, including the internet, more than they need an intimate understanding of protocols.
The next generation of investigators will be digital natives. They'll have grown up with the web, email, blogs, message boards, IM, flickr, youtube, social networking, and the like. They won't all have CCNAs, but they'll have a sufficient understanding of how people use the internet to know when to bring in forensic experts.
The transition will be difficult. The digital immigrants with extensive investigative experience and the digital natives who are novices in their profession will have to cooperate and exchange their knowledge and wisdom, and in the meantime, some criminals will slip through the cracks. That's the price of progress.
If I had mod points, I'd mod this insightful, not funny. There are a lot of HPC projects that were planning to use Barcelona, that were held back by the TLB bug. I'm sure anything approaching this magnitude already had a contract with AMD that includes guaranteed delivery dates and penalties, either directly or through the OEM. If you don't have a signed contract with AMD or with someone who has one with AMD, you're going to have to wait in line.
I skimmed the complaint, and was reminded of some bragging Intel did about improved dependency disambiguation in the Core microarchitecture that allowed them to expand from 3 pipelines to 4 pipelines and shorten the pipelines substantially, which gave a major performance boost over the Netburst microarchitecture. That could explain why this is going to court only now. The discussion probably didn't become adversarial until Intel started selling allegedly-infringing processors to the public, even though they were working on such designs in 2001.
Actually, if you want to test your surveillance of an enemy's communications networks, deliberately disrupting their communications can be a very worthwhile experiment.
It's notable that Iran is now supposedly cut off entirely. If the Iranian government has any secret communications links, it'll be much easier to tell when they're using them.
As pure and clean as microkernels may be, they're an engineering nightmare for large, general-purpose operating systems. There are lots of microkernel implementations out there, many of them very successful in certain niche applications, but none of them have taken off for general-purpose use the way monolithic kernels have. A general-purpose operating system has to make a lot of design compromises, and the modular-monolithic design most modern OSes use is a practical implementation of the concepts of microkernel design that have proved useful in the real world, while sticking to monolithic methods where they're working fine or the cost of redesigning them is prohibitive.
Linux keeps getting more microkernel-like over time. More and more kernel functions are being moved into userspace helpers. More kernel work is being pushed into workqueues or executed asynchronously in separate threads. In the realtime kernel, even hardware interrupt handlers are prioritized, scheduled threads. We have filesystems and character drivers in userspace. Linux already has most of the basic infrastructure you'd need to implement a true microkernel, and developers are taking advantage of this gradually, using the sort of iterative development method that drives academic purists nuts, but works very well.
In contrast, the design of Windows Vista took a sharp turn from its predecessors, moving a huge amount of functionality out into userspace. The result is much less susceptible to BSODs, but it was also way behind schedule, released missing major intended features (WinFS?), it's slow, and users hate it so much that they're asking OEMs to install XP instead. Sure, Vista may be more interesting technologically, but if you actually want to use your computer to do something useful, it sucks compared to XP.
Keep doing research, Andy. We'll keep writing kernels that are portable from cell phones to mainframes.
No matter how many terabits of data you can cram through a cable per second, there will always be a need for low-latency. A planet-wide star topology network, without the many levels of hierarchy we have today, would have latency that would be completely unacceptable for a great many applications. As long as our communication is subject to the speed of light, we will have LANs.
It was me!
Prove me wrong.
Isn't he now no longer eligible for sourceforge hosting?
...just got a lot more interesting.
...someone fix the GIMP!
In my anecdotal experience, desktop Linux is driving Mac sales. Whenever I point a frustrated Windows user towards Linux, they never go back to Windows. Some of them stick with Linux, and some of them buy Macs, but all of them learn that it's not really all that hard to switch. Those that end up as Mac users will have no difficulty switching back to Linux if Apple stops being worth the price premium to them.
...a beowulf cluster of these.
Oops, I was vague. My results were with UDP NFS, which is much simpler to tune. As you noted in your reply, it's possible to tune iSCSI to similar performance levels, but doing so without sacrificing latency is rather difficult. My point was that simpler protocols (like FCoE) make it much easier to get the most out of the hardware.
For what it's worth, the NFS server in my testing was using Fibre Channel storage.