I don't see how else Intel could afford to keep developing new architectures.
Maybe Intel can, but sadly they aren't. AMD is responsible for the vast majority of x86 innovation over the last 4 years: high IPC cores, larger L1 caches, on-die memory controllers, high performance serial chip-to-chip interconnect, 64 bit extensions with more general purpose registers, no-exec page protection, etc.
You should have been told when you rented that there are penalties for returning late. Blockbuster is not being "greedy" by expecting you to conform to contract terms.
If you returned the movie on time, their charge is fraudulent (like Wired's). If you were late, suck it up and pay, or let them tarnish your credit.
You are not legally entitled to screw corporations just because they want to screw you.
I agree about the evilness of NAT, but there is a critical flaw in this argument:
"A million worms, trying 10 IPv6 addresses per second, won't find more than a tiny fraction of vulnerable machines in a year."
I believe your assumption is that current IPv4 nodes would become randomly addressed within the IPv6 space. Frankly, that is unlikely. Major ISPs and internal LANs will probably still assign contiguous addresses via DHCP, meaning to attack N active users you just target PREFIX:0 to PREFIX:N. Even if PREFIXes are assigned randomly, major ISPs will probably still place millions of nodes on the same PREFIX. Worms will evolve, and will not be significantly thwarted simply by switching to IPv6.
Fully randomized V6 addressing would help but I am unconvinced major networks will consistently deploy that even if it were MUSTed in the DHCPv6 RFC.
To justify my cynicism with a corollary: OpenBSD is the only major OS that randomizes TCP/UDP port autobind, even though the predictable Linux + Windows allocation from 1024+ assists many forms of evil.
AMD operates their own CPU fab in Dresden, Germany. AFAIK IBM has no direct role in the fabrication of the K8-based processors.
AMD and IBM do work together on developing fabrication technology. But frankly AMD is well beyond IBM in terms of its application. You can't ramp an x86 chip by 100MHz a year and expect to survive.
The whole industry had major problems with 90nm, 300mm wafers and SOI, but IBM slipped more than others. Please do not imply that IBM's gross failure to meet targets implies a similar weakness in AMD.
I've been trying to keep my cynicism under control while reading the opinion. But frankly the proposed tests for "inducement" are ludicrous, circumstantial, and horrifying to network software developers. Check out these gems:
1. "Grokster's name is apparently derived from Napster". So does a defendent need a four letter match to be guilty, or is three enough? Would they be innocent if they named it "Furry Bunny P2P"? "Retspan P2P"?
2. "It advertised its OpenNap program to Napster users". Meaning it's partial inducement to bootstrap new p2p protocols via earlier networks with a high amount of alleged infringing activity. Will Bram need to USPS bulk mail CDs for his next protocol?
3. "Neither company attempted to develop filtering tools". OK this is where it gets extremely bad. Unless p2p developers build ineffective countermeasures ON THEIR DIME to appease entertainment companies, they are criminally liable. Will p2p apps have to blacklist game theory papers because they contain a popular rapper's name in their text? No, but the alternative is now probable liability during lawsuit.
4. "the more the software is used, the more ads are sent out... their enterprise turns on high-volume use, which the record shows is infringing." Almost every commercial enterprise derives value from its popularity. This point implies liability based on use of an entire family of legitimate business models (including Google's).
All previous theories of contributory infringement were direct. For instance, if Grokster employees stood outside of movie theaters and record stores saying "Why Buy? Steal Popular Music And Movies From Copyright Owners using Grokster!", they would clearly be guilty.
What SCOTUS has done today is create a new theory of liability, based on arbitrary whim: name similarity, failure to adequately satisfy a corporate plaintiff's demands, etc.
There should be little doubt that this case will have a chilling effect on US p2p innovation. I am deeply saddened by this unreasoned and imprecise decision.:-(
In most cases optical media failures affect only a small fraction of saved information (DVDR dye flaking, etc).
Archiving repair information based on reed solomon codes, or similar, will significantly improve the chance of full restoration from partially failed media.
Check out PAR2, commonly used on binary USENET to repair partially corrupt or missing posts. It works great with unreliable media too. You can recover N bytes of original data using the remaining data and N bytes of PAR2 recovery info, regardless of which N bytes are corrupted or missing.
If you are worried about future availibility, also backup the PAR2 spec and portable C source.
That argument is absurd. If the hardware is capable of significant output on unpermitted frequencies, what's to stop a corrupted driver download, or bug in the official firmware, from doing that? Wireless cards are complex systems that are certainly prone to bugs.
What if a disgruntled employee leaks the docs? Will the company have its FCC certification immediately revoked? If so, why would management build hardware that exposes them to that risk?
What if someone reverse engineers their hardware and writes a fast-propagating worm that programs it to jam law enforcement frequencies? Or microwave users' balls?
If the FCC was truly anal about theoretical interference, it would not certify software transmitters at all.
Several chips from the previous 802.11b generation are heavily documented. Some of them allow sw to increase power output to >=250mW, which combined with a large directional antenna will exceed FCC allowable output. Wait... why aren't these companies being raided by the FCC and DHS?
Frankly "Blame the FCC, we're their bitch" is just a vendor cop out created by competetive paranoia, lawyer power trips, and corporate inflexibility.
They're trying to get the BSD nerds to f*ck off while they sell to the trillions of Windows users that don't mind a silicon-induced lock up twice a week.
Do not confuse authentication, confidentiality, and tracability.
authentication: third parties cannot alter your communication; the party you are talking to is who you expect.
confidentiality: third parties cannot read your communication
tracability: third parties cannot determine who you are and/or with whom you are communicating (i.e. they can't map to meatspace)
The most critical factor for dissidents is tracability.
While ssh provides authentication and encryption, it does NOT, on its own, decrease tracability. Most governments (and in the US, corporations) can easily trace a basic IP connection, even if they can't read or write the traffic on it. Just follow the wire.
Remember: who you talk to can be at least as sensitive as what you say.
1. There is actually no RFC or other detailed documentation for the BT protocol. The unofficial clients were all written based on the source code from the official client (and more recently, based on the source code of other unofficial clients). IMO Bram should create a formal RFC, but that is pretty unlikely (he's not interested and the IETF is probably too conservative to do p2p).
2. Sadly the python clients are the only ones usable on 64MB virtual private servers. Most of the unofficial clients are platform-specific (Win32, GTK+), or require a bloated JVM that has no chance of working in less than 128MB.
I find it tragic that noone has released a high quality POSIX C client. Maybe the OpenBSD guys will eventually get around to OpenBT?
Corrupting a BitTorrent transfer would require a preimage attack, where the attacker must determine new (malicious) data with a specific hash. For an ideal hash function, the preimage complexity is 2^(n-1). This research did NOT weaken the preimage complexity of SHA1, so does not affect BT, or HMAC users such as SSL/TLS and IPSec (ESP).
This research instead concerns the birthday attack, where an attacker must (merely) find any two messages with the same hash. For an ideal hash, the birthday complexity is 2^(n/2). This research has shown that SHA1 is far from ideal (colliding in 2^69 attempts instead of 2^80).
The MPAA is still much better off filing lawsuits than going after SHA1.
The patch may be quick. It will still take a long time to deploy.
Anyway you have to wonder about this kind of technical oversight. If you are implementing an NX heap, you obviously need to NX the WHOLE heap for it to be useful.
Basically it looks like Microsoft is incapable of secure development at the core OS layer. I find that absolutely mind boggling given their resources.
OK can you clarify how SELinux prevents spam bots? I understand you can block BSD socket connect() / sendto()/etc for a process but how do you run your web browser in that case?
I don't see how SELinux helps beyond what a good firewall can do. The browser MUST be allowed to talk to the outside world. You can rate limit that, or maybe restrict it to certain hosts and ports, but overall it seems incredibly difficult to prevent spam from an exploited browser. The OS can't tell the difference between a good TCP connection and an evil one. Neither can most users.
I think we really need a secure browser. It doesn't seem viable to compensate for an insecure one using the kernel.
Eye contact does not work as a trust metric in every case. It naturally has false positives and false negatives:
False Positives: - Sales/Marketing/Con Artists/Lawyers/Politicians/etc who want to exploit you tend to make excellent eye contact, dress well, speak with a smooth tone of voice, etc. In slashdot terms, these people are effectively pwning humanity's distributed trust metric. One possible genetic advantage to autism is invulnerability to this form of bullshit. One disadvantage is that virtually all females still require it.
False Negatives: - Obviously not all autistic people are untrustworthy. In fact, autism often prevents the successful development of neurotypical deceit behaviors. Autists can be brutally honest, excellent friends, though they may not have an intense "animal presense."
In summary: human beings should use their rational mind to modulate primate social information.
The primate social metrics (such as eye contact) have poor signal-to-noise in many parts of society. I have not met a single MBA who doesn't play up eye contact, which effectively means I can't use it to differentiate between good and bad MBAs. Of course some people still do use it, so all MBAs must still make good eye contact. In you think about it, this example shows how complexity gets bolted on through evolution.
Slashdot Mirror
I don't see how else Intel could afford to keep developing new architectures.
Maybe Intel can, but sadly they aren't. AMD is responsible for the vast majority of x86 innovation over the last 4 years: high IPC cores, larger L1 caches, on-die memory controllers, high performance serial chip-to-chip interconnect, 64 bit extensions with more general purpose registers, no-exec page protection, etc.
Thank AMD for fixing x86.
Try OpenBSD. Clean, stable, secure, well-documented, with an installer that doubles as an IQ high-pass filter.
If you don't know what that means, you are probably a better fit for Debian 3.1's new sunny-walk-in-the-park installer. Noob.
Woah. Props to neurojab and sancho for the response.
I must be in some alternate universe where intelligent discourse is once again possible on slashdot.
Almost makes me want to permanently filter for uid less than 41772.
You should have been told when you rented that there are penalties for returning late. Blockbuster is not being "greedy" by expecting you to conform to contract terms.
If you returned the movie on time, their charge is fraudulent (like Wired's). If you were late, suck it up and pay, or let them tarnish your credit.
You are not legally entitled to screw corporations just because they want to screw you.
AMD operates their own CPU fab in Dresden, Germany. AFAIK IBM has no direct role in the fabrication of K8-based processors.
AMD and IBM do work together on developing fabrication technology. But AMD is not fabless nor totally dependent on IBM for manufacturing.
I agree about the evilness of NAT, but there is a critical flaw in this argument:
"A million worms, trying 10 IPv6 addresses per second, won't find more than a tiny fraction of vulnerable machines in a year."
I believe your assumption is that current IPv4 nodes would become randomly addressed within the IPv6 space. Frankly, that is unlikely. Major ISPs and internal LANs will probably still assign contiguous addresses via DHCP, meaning to attack N active users you just target PREFIX:0 to PREFIX:N. Even if PREFIXes are assigned randomly, major ISPs will probably still place millions of nodes on the same PREFIX. Worms will evolve, and will not be significantly thwarted simply by switching to IPv6.
Fully randomized V6 addressing would help but I am unconvinced major networks will consistently deploy that even if it were MUSTed in the DHCPv6 RFC.
To justify my cynicism with a corollary: OpenBSD is the only major OS that randomizes TCP/UDP port autobind, even though the predictable Linux + Windows allocation from 1024+ assists many forms of evil.
AMD operates their own CPU fab in Dresden, Germany. AFAIK IBM has no direct role in the fabrication of the K8-based processors.
AMD and IBM do work together on developing fabrication technology. But frankly AMD is well beyond IBM in terms of its application. You can't ramp an x86 chip by 100MHz a year and expect to survive.
The whole industry had major problems with 90nm, 300mm wafers and SOI, but IBM slipped more than others. Please do not imply that IBM's gross failure to meet targets implies a similar weakness in AMD.
http://www.eff.org/IP/P2P/MGM_v_Grokster/key_quote s.php
... their enterprise turns on high-volume use, which the record shows is infringing." Almost every commercial enterprise derives value from its popularity. This point implies liability based on use of an entire family of legitimate business models (including Google's).
:-(
I've been trying to keep my cynicism under control while reading the opinion. But frankly the proposed tests for "inducement" are ludicrous, circumstantial, and horrifying to network software developers. Check out these gems:
1. "Grokster's name is apparently derived from Napster". So does a defendent need a four letter match to be guilty, or is three enough? Would they be innocent if they named it "Furry Bunny P2P"? "Retspan P2P"?
2. "It advertised its OpenNap program to Napster users". Meaning it's partial inducement to bootstrap new p2p protocols via earlier networks
with a high amount of alleged infringing activity. Will Bram need to USPS bulk mail CDs for his next protocol?
3. "Neither company attempted to develop filtering tools". OK this is where it gets extremely bad. Unless p2p developers build ineffective countermeasures ON THEIR DIME to appease entertainment companies, they are criminally liable. Will p2p apps have to blacklist game theory papers because they contain a popular rapper's name in their text? No, but the alternative is now probable liability during lawsuit.
4. "the more the software is used, the more ads are sent out
All previous theories of contributory infringement were direct. For instance, if Grokster employees stood outside of movie theaters and record stores saying "Why Buy? Steal Popular Music And Movies From Copyright Owners using Grokster!", they would clearly be guilty.
What SCOTUS has done today is create a new theory of liability, based on arbitrary whim: name similarity, failure to adequately satisfy a corporate plaintiff's demands, etc.
There should be little doubt that this case will have a chilling effect on US p2p innovation. I am deeply saddened by this unreasoned and imprecise decision.
In most cases optical media failures affect only a small fraction of saved information (DVDR dye flaking, etc).
Archiving repair information based on reed solomon codes, or similar, will significantly improve the chance of full restoration from partially failed media.
Check out PAR2, commonly used on binary USENET to repair partially corrupt or missing posts. It works great with unreliable media too. You can recover N bytes of original data using the remaining data and N bytes of PAR2 recovery info, regardless of which N bytes are corrupted or missing.
If you are worried about future availibility, also backup the PAR2 spec and portable C source.
Sigh... Another post falls victim to slashdot mods confusing wry, profane humor with flamebait.
Would someone kindly reply with an entertaining and legitimate counter-argument while they siphon away my karma?
That argument is absurd. If the hardware is capable of significant output on unpermitted frequencies, what's to stop a corrupted driver download, or bug in the official firmware, from doing that? Wireless cards are complex systems that are certainly prone to bugs.
What if a disgruntled employee leaks the docs? Will the company have its FCC certification immediately revoked? If so, why would management build hardware that exposes them to that risk?
What if someone reverse engineers their hardware and writes a fast-propagating worm that programs it to jam law enforcement frequencies? Or microwave users' balls?
If the FCC was truly anal about theoretical interference, it would not certify software transmitters at all.
Several chips from the previous 802.11b generation are heavily documented. Some of them allow sw to increase power output to >=250mW, which combined with a large directional antenna will exceed FCC allowable output. Wait... why aren't these companies being raided by the FCC and DHS?
Frankly "Blame the FCC, we're their bitch" is just a vendor cop out created by competetive paranoia, lawyer power trips, and corporate inflexibility.
They're trying to get the BSD nerds to f*ck off while they sell to the trillions of Windows users that don't mind a silicon-induced lock up twice a week.
Hey, I'm not bitter.. I'm right.
Find a better religion. My god kills the leechers.
Do not confuse authentication, confidentiality, and tracability.
authentication: third parties cannot alter your communication; the party you are talking to is who you expect.
confidentiality: third parties cannot read your communication
tracability: third parties cannot determine who you are and/or with whom you are communicating (i.e. they can't map to meatspace)
The most critical factor for dissidents is tracability.
While ssh provides authentication and encryption, it does NOT, on its own, decrease tracability. Most governments (and in the US, corporations) can easily trace a basic IP connection, even if they can't read or write the traffic on it. Just follow the wire.
Remember: who you talk to can be at least as sensitive as what you say.
No, this man actually got laid.
How do you know? Is there a new paternity test that uses just a 15.42KB jpeg?
Standard neurotypical, humping to conclusions.
Mathgirl: Hey Mathman! Can you teach me how to integrate around a pole?
Yeah, well.. a theorist can dream.
This guy doesn't know what he's talking about.
Probably. Dunno since I stopped RTFAs a while ago.
However, the IBM PowerPC 970FX aka Apple G5 processors have had NX for a while. Partial Linux support already exists. Check it out.
http://lwn.net/Articles/126862/
I like the 970FX (apart from its tiny cache). Shame Apple has a monopoly on the desktop systems, and you have to buy their OS to run Linux on one.
Nope. For the GNU hippies and slashdot whiners:
Freehand + Illustrator = Freehator
1. There is actually no RFC or other detailed documentation for the BT protocol. The unofficial clients were all written based on the source code from the official client (and more recently, based on the source code of other unofficial clients). IMO Bram should create a formal RFC, but that is pretty unlikely (he's not interested and the IETF is probably too conservative to do p2p).
2. Sadly the python clients are the only ones usable on 64MB virtual private servers. Most of the unofficial clients are platform-specific (Win32, GTK+), or require a bloated JVM that has no chance of working in less than 128MB.
I find it tragic that noone has released a high quality POSIX C client. Maybe the OpenBSD guys will eventually get around to OpenBT?
Now, could you imagine what would happen if the US had a president that bet 100 billion on the internet?
The RIAA, MPAA, and BSA would ask for a full refund?
Corrupting a BitTorrent transfer would require a preimage attack, where the attacker must determine new (malicious) data with a specific hash. For an ideal hash function, the preimage complexity is 2^(n-1). This research did NOT weaken the preimage complexity of SHA1, so does not affect BT, or HMAC users such as SSL/TLS and IPSec (ESP).
This research instead concerns the birthday attack, where an attacker must (merely) find any two messages with the same hash. For an ideal hash, the birthday complexity is 2^(n/2). This research has shown that SHA1 is far from ideal (colliding in 2^69 attempts instead of 2^80).
The MPAA is still much better off filing lawsuits than going after SHA1.
Incompetence leads to trouble in any language. For instance, a recursive function which does not enforce a recursion limit may:
- segfault in C
- throw an unhandled exception in python
- churn up 2GB swap in java (or something similar)
In any case, think DoS. The solution is to program competently, regardless of language.
yoh... ne1 got nfo on 0day deluxe four buton mice? need lether grip pro edition.. couldnt find it on exeem.
Sincerely,
slashd0t w4rez cr3w
The patch may be quick. It will still take a long time to deploy.
Anyway you have to wonder about this kind of technical oversight. If you are implementing an NX heap, you obviously need to NX the WHOLE heap for it to be useful.
Basically it looks like Microsoft is incapable of secure development at the core OS layer. I find that absolutely mind boggling given their resources.
OK can you clarify how SELinux prevents spam bots? I understand you can block BSD socket connect() / sendto() /etc for a process but how do you run your web browser in that case?
I don't see how SELinux helps beyond what a good firewall can do. The browser MUST be allowed to talk to the outside world. You can rate limit that, or maybe restrict it to certain hosts and ports, but overall it seems incredibly difficult to prevent spam from an exploited browser. The OS can't tell the difference between a good TCP connection and an evil one. Neither can most users.
I think we really need a secure browser. It doesn't seem viable to compensate for an insecure one using the kernel.
Eye contact does not work as a trust metric in every case. It naturally has false positives and false negatives:
False Positives:
- Sales/Marketing/Con Artists/Lawyers/Politicians/etc who want to exploit you tend to make excellent eye contact, dress well, speak with a smooth tone of voice, etc. In slashdot terms, these people are effectively pwning humanity's distributed trust metric. One possible genetic advantage to autism is invulnerability to this form of bullshit. One disadvantage is that virtually all females still require it.
False Negatives:
- Obviously not all autistic people are untrustworthy. In fact, autism often prevents the successful development of neurotypical deceit behaviors. Autists can be brutally honest, excellent friends, though they may not have an intense "animal presense."
In summary: human beings should use their rational mind to modulate primate social information.
The primate social metrics (such as eye contact) have poor signal-to-noise in many parts of society. I have not met a single MBA who doesn't play up eye contact, which effectively means I can't use it to differentiate between good and bad MBAs. Of course some people still do use it, so all MBAs must still make good eye contact. In you think about it, this example shows how complexity gets bolted on through evolution.