It's not just a holdover: it's also a compromise after different OS builders tried to simplify things the same way without coordinating and whose arbitrary choices happened to conflict. Once you have unixy LF and macish CR in the wild, reviving the old CRLF admixture made an equally unhappy compromised. That compromise was baked into telnet and subsequent protocols. By the time Microsoft brought MS-DOS to market, CRLF looked like the sensible, standards-compliant choice.
I am mostly summarizing the old EOLstory, which says it better.
You have described the Truy Ergonomic keyboard. Really, that's the brand name they picked. Not buckling spring, but still mechanical keys, noise optional (Cherry MX Blue or Brown). Not cheap at $250, but the most appealing design I've seen yet.
I did own a Kinesis Classic years ago. Crazy arrangement as Average mentions, very different. If you have RSI concerns, different is exactly what you want. I used to switch back and forth every once in a while, just to change up the motion. I can't say I ever really liked the bowl though, and I eventually gave it away (which I now regret). The real keys use the same Cherry Brown key switches as the unfortunately-named Truly Ergonomic. The rubber function "keys" are pure rubbish though.
Ext2/3/4 sucks as an interchange format. In short, it does too much. Any filesystem sufficiently complex to support real workloads is going to impose an excessive implementation burden for sneakernet. The bizarre thing is that we have a minimalist filesystem that can represent the file model with fidelity (large files, unicode names, etc) that is implemented in every modern OS: UDF. If it can read DVDs, it can read UDF and every general purpose OS released in the last decade can write to the appropriate version, 2.01. Not for nothing is it called the Universal Disk Format.
The real mystery is how did Microsoft con an industry into paying for such a lousy alternative to UDF. SDXC requires exFAT, so every new camera and anything else that hopes to read these high capacity sdcards has to cope with licensing requirements. WTF.
Help me out here: is it not blatantly obvious that the numbers in that strip assume randomly generated pass-phrases? I thought that that was 1/2 the point. With a 48-bit key mapped to four characters of a 12-bit symbol-set composed of English words, you can get keys that are both strong and easy for humans to remember. Let users choose the pass-phrase and you sacrifice the first part, and it's only the combination that's interesting.
I wouldn't presume to accuse the engineers behind SPDY of ignoring the existing work in the space. I did take exception to the immediate parent's dismissive and inaccurate characterization of SCTP. That protocol is a worthy attempt to solve real problems at the most technically desirable layer. SPDY looks to be a good piece of engineering, inventing only as much as necessary to achieve a well defined benefit. I cannot fault its creators for that.
I stand behind my assertion that SPDY will succeed at the expense of SCTP. There are finite resources available for such work and those two protocols are in direct competition. After all the investment by browser implementors, web server vendors, proxies, reverse proxies, etc to support the former, can you really see any interest in doing so all over again for only modest direct benefit? If you succeed, then that constituency will have been largely satisfied. The web will indeed be better off – no small thing! And it will be good enough. Good enough in the same way that HTTPS is good enough. The protocol is sufficiently extensible that new ciphers have been deployed without breaking older implementations, but the true weaknesses lie in the fundamentally flawed nature of the CA institution that it spawned: a social problem, one not readily susceptible to technical improvement. Only now that the weakness in the CA system have been exploited and publicized has there been much appetite for any innovation in that space whatsoever. DNSSec is only just now percolating up through the resolver to applications – how long before we can rely on a sound technical foundation for transport crypto such as the HIP protocol aims to provide? The shortcuts taken today will linger to haunt future generations.
Engineers solve real problems, affording us real, practical benefit. I get that. Please forgive me that I am sad that solving these problems one niche at a time means that we can't seem to pull together towards a general solution for a broader benefit. I don't want it to just work: I wish for the foundations to be sound.
Have you looked at SCTP at all? 90% of the problem that SPDY aims to solve is already addressed by SCTP. Message framing and multiplexing multiple streams over a single connection with different delivery guarantees are the standout features. SPDY main accomplishment is also its major drawback: it accepts as a design requirement TCP compatibility. It is a product of those who believe that the internet as originally conceived, is dead. Instead of a packet-switched network routed according to destination address, internet access has come to imply only outbound TCP session connectivity, with some UDP and ICMP if you're lucky. The fact that this is largely adequate for the way we use the network today should not be taken as an endorsement; our use today is limited to those aspects because we cannot do more. NAT and perimeter firewalls have effectively crippled the evolution of the global network. You can no longer upgrade only the endpoints: one must wait upon the whole of the network to join the transition. Innovation then is limited to layers above established protocols. Witness the madness that is IP-HTTPS. With that viewpoint in mind, I cannot celebrate the advent SPDY; I must lament it's significance.
Adding insult is that it is perhaps not too late. The endpoints which benefit most from these efforts are those on the proprietary networks of the mobile operators like AT&T and Verizon. Those operators have the control necessary to permit SCTP operation, and there is a marketable competitive advantage to be had in doing so. The other side of the equation does not have the same barriers. Google, Akamai, Amazon - these endpoints are entirely owned by parties with both the capability and the business interest to enable the technology.
SCTP has applications far beyond those that can be addressed by SPDY, but If SPDY succeeds, SCTP fails. They could have solved the problem on the internet. They chose to solve the problem on the web.
I'm a little more familiar with the C#.NET environment, but I don't see any reason you couldn't apply the idea to C code as well. LLVM bitcode already exists with both a container and a intermediate format corresponding to.NET's IL or Java's bytecode. LLVM is designed to be suitable for direct compilation down to machine code without the companion virtual machines that.NET and Java expect. If all you want to do is delay the platform-dependent compilation phase, LLVM looks perfect to me.
Weather kills people all the time. The forensics is a little trickier though: fewer fingerprints and more computer simulations, fewer explosives and more droughts. On the flip side, there's still plenty of expert testimony.
+1 to visually distinguishable tabs. I still want a bit "whiter" whitespace though, something that settles a little more easily into the background. I've lately settled on the following, in combination with DejaVu Sans Mono. Unicode support mileage with other fonts varies.
if &encoding =~ "utf-8" set list listchars=tab:┄─,trail:· else set list listchars=tab:._,trail:- endif
... not that I can actually show what those look like since it appears that slashcode doesn't approve of box drawing characters. At least not "BOX DRAWINGS LIGHT TRIPLE DASH HORIZONTAL" and "BOX DRAWINGS LIGHT HORIZONTAL". You'll have to decode those HTML entities yourself, oh intrepid reader. I could probably get "MIDDLE DOT" through, but I guess I'm just not that committed.
I think your comment helps illustrate the point. The information you can so easily put hand to wasn't free. Finding the best tool for the job can require significant research. I don't pass up orange marmalade because I'm confused, I walk away because I don't want to spend a half hour sampling jam. When faced with a set already winnowed down to those with the broadest appeal, I'm far more likely to invest the time because I'll feel like I've got a shot at finding one that's good enough in an acceptable time frame. There comes a point where I'd rather stick with my familiar Smuckers, even if it's not the best out there.
I just want to get my work done. I don't want to have to repeat the work of comparative analysis just to get started. It's been done before, by everyone who wanted to play. Even less do I want to repeat the effort I've put in to working with my selected tool if turns out to have been a bad choice.
I realize that none of this is a real reply, but I found the casual tone of your statements striking. None of that is obvious to someone on the outside. We can't see from your vantage point. So many of the comments to this article seem to miss the basic observation: a surfeit of choice impedes adoption. It's true of software technologies just as it is for the high-def video market.
It's usually not the register width that gives you the boost, but the register count. AMD doubled both the width and the number of general purpose registers when they designed x86_64 (aka AMD64, aka IA32e). Arstechnica has a detailed overview (jump to page 3 for relevant slide and it's accompanying explanation). You are right about the larger pointers being a liability when it comes to memory bandwidth, but the size of your basic C99 "int" remains unchanged. If you want a 64-bit integer, you'll have to ask for a "long int" on x86_64, or a "long long int" on modern i386, or better yet, an "int64_t" on any architecture that supports it.
There are two parts to the answer to that. Traditional NFS access control is entirely host based. You can map root on the remote computer to an unprivileged user or map an entire host to a single user, but that's about it. NFS was designed in an era where all of a network's computers were managed by the sysadmins, and you could reasonably trust the computers on your local net. That trust is now a liability for protocols like NFS and NIS.
The extended answer is that the underlying rpc protocol has long supported more sophisticated access control. AFAICT, the only one which is currently usable is RPCSEC_GSS, the kerberos security flavor. Sun solaris has had this for years, but it has only recently become usable with linux (and there are still some gotchas). The new NFS protocol in development, NFSv4, mandates this and two others: SPKM-3 and LIPKEY. Both are SSL/TLS based. SPKM-3 uses certificates for user authentication, LIPKEY uses passwords. All of these schemes require the users sitting at the remote keyboard fork over his authentication info and cache credentials of some sort, so if that host is compromised, so may be his account. But that's unavoidable. Quite different from leaving your department fileserver wide open.
In theory, there's nothing to stop you from running an Active Directory server and adding a fileserver with samba-3 for the windows clients and nfs for the *nix clients, both using Active Directory's kerberos implementation for authentication. Being able to replace the AD server with samba-4 just sweetens the deal.
If you don't want to agree to the terms of Red Hat's contract, don't. I'm sure copies of RHEL are readily available from other sources. Nothing in the contract prevents you from copying and distributing the software once you have it. The contract limits your right to *use* the software, which is not protected by the GPL (to stay within the domain of copyright law). It may be a little sneaky, but it doesn't make free software unfree.
In fact, Red Hat would be within their rights to provide the source only to their customers, though, again, they would be free to redistribute them. But they don't do that. They work in the open, and they share the important stuff: the source. The actual source packages for all of RHEL are available on Red Hat's own ftp servers. Our copy of RHEL WS didn't include postgres, so I had to rebuild the package, but it's the same package, vendor patches and all.
RHEL is a product and a service, and it costs money. And that's okay: there's nothing wrong with selling free software.
At it's heart, chroot just changes a process's view of the filesystem. There are still plenty of ways to interfere with the system from inside a chroot jail. I've never used grsecurity, but from the website it's clear that they have substantially improved the feature, i.e. now apache won't be able to break out of that jail.
Boycott's are not the only reasonable response to poor behavior, just the one appropriate in this case. We're not talking about a basic necessity, or even a rare commodity. It's just a game, as he said, just fun.
He might have said, "I love this game, so I'll buy it, but I'll give twice as much to the EFF to make up for it". That would have been consistent with the expressed sentiment.
As I said in the post you responded to, he is not being hypocritical. (it just smells like it) All he did was show that he didn't mind blizzards actions much. My priorities are different, so I didn't see that right away.
Oy, and to think: I almost mis-spelled hypocrisy too.:)
His post was not the definition of hypocrisy: it merely evinced it. He implied that he found fault with their actions, but then promised to buy their products anyway. I find the latter inconsistent with the former. Is that so controversial?
I think I see my error now. Looking back, all he really said was that he puts a higher priority on fun then on âoepoliticsâ. That didn't make any sense to me. I should have known from his characterization of this misdeed as politics, that he didn't really mind Blizzard's actions.
What makes the Opteron a server chip is the presense of three hypertransport links, the bus used for communication between multiple CPUs and other components such as the motherboard chipset. The Athlon64 will have only one. This is important since hypertransport, unlike say PCI, uses point-to-point links. The AGP and PCI bridges could be on separate hypertransport links and in theory we could see things like gigE controllers directly attached to the hypertransport bus.
Also, last I heard, the Opteron will use Dual DDR memory, while Athlon64 will have to make do with single-channel DDR. Recall that both Hammer chips (SledgeHammer, aka Opteron, and ClawHammer, aka Athlon64), have the memmory controller integrated onto the CPU.
For both of these reasons, the Opteron and Athlon64 sockets are incompatible (Socket 754 vs Socket 940). There's an old review with plenty of information here
Plug the 64 bit controller into the 32 bit slot and let the PCI bus be your bottlneck. See their features under minimum system requirements, which specifiy 32 bit or 64 bit. Also, motherboard compatibility, which lists many chipsets without 64 bit pci.
The reason we went with 3ware controllers last time was that we were maxing out the pci bus. Moving to a 64 bit card solved that problem. It's too bad 3ware didn't opt for 66 MHz PCI instead of the wider bus. I wonder how much this has cost them?
I'm adding my vote for 3ware. You can get an 8 port IDE card for less than $400 or an 8 port SATA card for under $500. Beware big IDE raids, cabling issues become a major pain. We ended up using 36" (out of spec) rounded ide cables for our last 1.1 TB raid. I'm hoping that next time, we can use serial ata disks and the forthcoming 3ware raid card with native SATA. Their current offering uses the same chips as the 7500 IDE raid controller, combined with SATA bridges.
Do you really need hardware raid? These days disks are so big that you don't need RAID5 (and thus a beefy raid controller) unless you need an unholy amount of storage. For redunancy, RAID1 will do nicely, either in software or cheap hardware.
Have you actually compared VB and VB.NET? The only person I've talked to who has says that they are substantially different. VB.NET is more of a migration path to C#.
How exactly is SATA better than IEEE 1394 (firewire) for internal uses? Do you like being limited to the number of ports the motherboard manufacturer thought was necessary? 1394 allows you to chain devices, akin to scsi - much more convenient.
SATA requires a special power connector too, likely on the motherboard itself. 1394 gives you power too, in one little connector.
Linux certainly does support 1394. When our tape library failed at work, we replaced it with a bunch of firewire disks. Not only do they offer more storage at a lower cost, but they are all simultaneously online and are hell of a lot faster than tape. See linux1394.org
Do you really want to perpetuate the cruft that is ATA? You don't need drivers for SATA because it inherits many of PATA's limitations. Personally, i like hotswap (important for software raid) and i like isochonous transfer (good for cd burners as well as video streams). 1394 requires new drivers because it offers more. Linux has no problem reading 1394 drives. Windows has no problem reading 1394 drives. MacOS has no problem reading 1394 drives. How difficult would it have been to boot off of 1394? The only real obstacle is that anachonism - the PC BIOS. Replace with linuxBIOS and you'd be golden.
If Apple and Co had not decided to tax firewire, we would have had this years ago. Back in the days of the FX chipset, intel promised to include 1394 in it's motherboard chipsets, right next to USB. But no. They didn't want to be beholden to a third party, so they went off and invented the abomination that is USB2.
DDR333 is here now, but you won't see a 333MHz FSB until Hammer hits the scene. According to Toms' Hardware, you won't even see it in Barton. While a DDR333 connection to the northbridge might be nice for smp setups, it'll be wasted connected by a 133 MHz DDR interface to one cpu. It'll help, just not as much as it should.
The problem isn't that Blizzard reacted to bnetd: it's that they used a corrupt law to do it. Writing software that works with a commercial product shouldn't be a crime. They didn't violate copyright anymore than do marker manufactures. Making a tool than can be used illegally is a hideous standard.
The fact that bnetd is inconvenient to Blizzard shouldn't make it criminal. If that were the standard, HP could sue IBM on the grounds that selling computers cut into thier sales. Why, they might as well be stealing!
No I don't care about Joe Slashdot. If you don't speak up when the black hats come for the other guy, how can you expect the rest to help when they come for you?
The DMCA is a bad law, a bought law. The US handed copyright holders a Big Stick to use on it's own people. Until we can take it away, the least we can do is shun the ones that go around beating people up.
Slashdot Mirror
It's not just a holdover: it's also a compromise after different OS builders tried to simplify things the same way without coordinating and whose arbitrary choices happened to conflict. Once you have unixy LF and macish CR in the wild, reviving the old CRLF admixture made an equally unhappy compromised. That compromise was baked into telnet and subsequent protocols. By the time Microsoft brought MS-DOS to market, CRLF looked like the sensible, standards-compliant choice.
I am mostly summarizing the old EOLstory, which says it better.
Nicely done.
You have described the Truy Ergonomic keyboard. Really, that's the brand name they picked. Not buckling spring, but still mechanical keys, noise optional (Cherry MX Blue or Brown). Not cheap at $250, but the most appealing design I've seen yet.
I did own a Kinesis Classic years ago. Crazy arrangement as Average mentions, very different. If you have RSI concerns, different is exactly what you want. I used to switch back and forth every once in a while, just to change up the motion. I can't say I ever really liked the bowl though, and I eventually gave it away (which I now regret). The real keys use the same Cherry Brown key switches as the unfortunately-named Truly Ergonomic. The rubber function "keys" are pure rubbish though.
Ext2/3/4 sucks as an interchange format. In short, it does too much. Any filesystem sufficiently complex to support real workloads is going to impose an excessive implementation burden for sneakernet. The bizarre thing is that we have a minimalist filesystem that can represent the file model with fidelity (large files, unicode names, etc) that is implemented in every modern OS: UDF. If it can read DVDs, it can read UDF and every general purpose OS released in the last decade can write to the appropriate version, 2.01. Not for nothing is it called the Universal Disk Format.
The real mystery is how did Microsoft con an industry into paying for such a lousy alternative to UDF. SDXC requires exFAT, so every new camera and anything else that hopes to read these high capacity sdcards has to cope with licensing requirements. WTF.
Help me out here: is it not blatantly obvious that the numbers in that strip assume randomly generated pass-phrases? I thought that that was 1/2 the point. With a 48-bit key mapped to four characters of a 12-bit symbol-set composed of English words, you can get keys that are both strong and easy for humans to remember. Let users choose the pass-phrase and you sacrifice the first part, and it's only the combination that's interesting.
I wouldn't presume to accuse the engineers behind SPDY of ignoring the existing work in the space. I did take exception to the immediate parent's dismissive and inaccurate characterization of SCTP. That protocol is a worthy attempt to solve real problems at the most technically desirable layer. SPDY looks to be a good piece of engineering, inventing only as much as necessary to achieve a well defined benefit. I cannot fault its creators for that.
I stand behind my assertion that SPDY will succeed at the expense of SCTP. There are finite resources available for such work and those two protocols are in direct competition. After all the investment by browser implementors, web server vendors, proxies, reverse proxies, etc to support the former, can you really see any interest in doing so all over again for only modest direct benefit? If you succeed, then that constituency will have been largely satisfied. The web will indeed be better off – no small thing! And it will be good enough. Good enough in the same way that HTTPS is good enough. The protocol is sufficiently extensible that new ciphers have been deployed without breaking older implementations, but the true weaknesses lie in the fundamentally flawed nature of the CA institution that it spawned: a social problem, one not readily susceptible to technical improvement. Only now that the weakness in the CA system have been exploited and publicized has there been much appetite for any innovation in that space whatsoever. DNSSec is only just now percolating up through the resolver to applications – how long before we can rely on a sound technical foundation for transport crypto such as the HIP protocol aims to provide? The shortcuts taken today will linger to haunt future generations.
Engineers solve real problems, affording us real, practical benefit. I get that. Please forgive me that I am sad that solving these problems one niche at a time means that we can't seem to pull together towards a general solution for a broader benefit. I don't want it to just work: I wish for the foundations to be sound.
Have you looked at SCTP at all? 90% of the problem that SPDY aims to solve is already addressed by SCTP. Message framing and multiplexing multiple streams over a single connection with different delivery guarantees are the standout features. SPDY main accomplishment is also its major drawback: it accepts as a design requirement TCP compatibility. It is a product of those who believe that the internet as originally conceived, is dead. Instead of a packet-switched network routed according to destination address, internet access has come to imply only outbound TCP session connectivity, with some UDP and ICMP if you're lucky. The fact that this is largely adequate for the way we use the network today should not be taken as an endorsement; our use today is limited to those aspects because we cannot do more. NAT and perimeter firewalls have effectively crippled the evolution of the global network. You can no longer upgrade only the endpoints: one must wait upon the whole of the network to join the transition. Innovation then is limited to layers above established protocols. Witness the madness that is IP-HTTPS. With that viewpoint in mind, I cannot celebrate the advent SPDY; I must lament it's significance.
Adding insult is that it is perhaps not too late. The endpoints which benefit most from these efforts are those on the proprietary networks of the mobile operators like AT&T and Verizon. Those operators have the control necessary to permit SCTP operation, and there is a marketable competitive advantage to be had in doing so. The other side of the equation does not have the same barriers. Google, Akamai, Amazon - these endpoints are entirely owned by parties with both the capability and the business interest to enable the technology.
SCTP has applications far beyond those that can be addressed by SPDY, but If SPDY succeeds, SCTP fails. They could have solved the problem on the internet. They chose to solve the problem on the web.
I'm a little more familiar with the C# .NET environment, but I don't see any reason you couldn't apply the idea to C code as well. LLVM bitcode already exists with both a container and a intermediate format corresponding to .NET's IL or Java's bytecode. LLVM is designed to be suitable for direct compilation down to machine code without the companion virtual machines that .NET and Java expect. If all you want to do is delay the platform-dependent compilation phase, LLVM looks perfect to me.
Weather kills people all the time. The forensics is a little trickier though: fewer fingerprints and more computer simulations, fewer explosives and more droughts. On the flip side, there's still plenty of expert testimony.
+1 to visually distinguishable tabs. I still want a bit "whiter" whitespace though, something that settles a little more easily into the background. I've lately settled on the following, in combination with DejaVu Sans Mono. Unicode support mileage with other fonts varies.
I think your comment helps illustrate the point. The information you can so easily put hand to wasn't free. Finding the best tool for the job can require significant research. I don't pass up orange marmalade because I'm confused, I walk away because I don't want to spend a half hour sampling jam. When faced with a set already winnowed down to those with the broadest appeal, I'm far more likely to invest the time because I'll feel like I've got a shot at finding one that's good enough in an acceptable time frame. There comes a point where I'd rather stick with my familiar Smuckers, even if it's not the best out there.
I just want to get my work done. I don't want to have to repeat the work of comparative analysis just to get started. It's been done before, by everyone who wanted to play. Even less do I want to repeat the effort I've put in to working with my selected tool if turns out to have been a bad choice.
I realize that none of this is a real reply, but I found the casual tone of your statements striking. None of that is obvious to someone on the outside. We can't see from your vantage point. So many of the comments to this article seem to miss the basic observation: a surfeit of choice impedes adoption. It's true of software technologies just as it is for the high-def video market.
It's usually not the register width that gives you the boost, but the register count. AMD doubled both the width and the number of general purpose registers when they designed x86_64 (aka AMD64, aka IA32e). Arstechnica has a detailed overview (jump to page 3 for relevant slide and it's accompanying explanation). You are right about the larger pointers being a liability when it comes to memory bandwidth, but the size of your basic C99 "int" remains unchanged. If you want a 64-bit integer, you'll have to ask for a "long int" on x86_64, or a "long long int" on modern i386, or better yet, an "int64_t" on any architecture that supports it.
There are two parts to the answer to that. Traditional NFS access control is entirely host based. You can map root on the remote computer to an unprivileged user or map an entire host to a single user, but that's about it. NFS was designed in an era where all of a network's computers were managed by the sysadmins, and you could reasonably trust the computers on your local net. That trust is now a liability for protocols like NFS and NIS.
The extended answer is that the underlying rpc protocol has long supported more sophisticated access control. AFAICT, the only one which is currently usable is RPCSEC_GSS, the kerberos security flavor. Sun solaris has had this for years, but it has only recently become usable with linux (and there are still some gotchas). The new NFS protocol in development, NFSv4, mandates this and two others: SPKM-3 and LIPKEY. Both are SSL/TLS based. SPKM-3 uses certificates for user authentication, LIPKEY uses passwords. All of these schemes require the users sitting at the remote keyboard fork over his authentication info and cache credentials of some sort, so if that host is compromised, so may be his account. But that's unavoidable. Quite different from leaving your department fileserver wide open.
In theory, there's nothing to stop you from running an Active Directory server and adding a fileserver with samba-3 for the windows clients and nfs for the *nix clients, both using Active Directory's kerberos implementation for authentication. Being able to replace the AD server with samba-4 just sweetens the deal.
If you don't want to agree to the terms of Red Hat's contract, don't. I'm sure copies of RHEL are readily available from other sources. Nothing in the contract prevents you from copying and distributing the software once you have it. The contract limits your right to *use* the software, which is not protected by the GPL (to stay within the domain of copyright law). It may be a little sneaky, but it doesn't make free software unfree.
In fact, Red Hat would be within their rights to provide the source only to their customers, though, again, they would be free to redistribute them. But they don't do that. They work in the open, and they share the important stuff: the source. The actual source packages for all of RHEL are available on Red Hat's own ftp servers. Our copy of RHEL WS didn't include postgres, so I had to rebuild the package, but it's the same package, vendor patches and all.
RHEL is a product and a service, and it costs money. And that's okay: there's nothing wrong with selling free software.
At it's heart, chroot just changes a process's view of the filesystem. There are still plenty of ways to interfere with the system from inside a chroot jail. I've never used grsecurity, but from the website it's clear that they have substantially improved the feature, i.e. now apache won't be able to break out of that jail.
Boycott's are not the only reasonable response to poor behavior, just the one appropriate in this case. We're not talking about a basic necessity, or even a rare commodity. It's just a game, as he said, just fun.
He might have said, "I love this game, so I'll buy it, but I'll give twice as much to the EFF to make up for it". That would have been consistent with the expressed sentiment.
As I said in the post you responded to, he is not being hypocritical. (it just smells like it) All he did was show that he didn't mind blizzards actions much. My priorities are different, so I didn't see that right away.
Oy, and to think: I almost mis-spelled hypocrisy too. :)
His post was not the definition of hypocrisy: it merely evinced it. He implied that he found fault with their actions, but then promised to buy their products anyway. I find the latter inconsistent with the former. Is that so controversial?
I think I see my error now. Looking back, all he really said was that he puts a higher priority on fun then on âoepoliticsâ. That didn't make any sense to me. I should have known from his characterization of this misdeed as politics, that he didn't really mind Blizzard's actions.
I stand corrected.
You do realize that that's basically the definition of hypocrisy, right?
What makes the Opteron a server chip is the presense of three hypertransport links, the bus used for communication between multiple CPUs and other components such as the motherboard chipset. The Athlon64 will have only one. This is important since hypertransport, unlike say PCI, uses point-to-point links. The AGP and PCI bridges could be on separate hypertransport links and in theory we could see things like gigE controllers directly attached to the hypertransport bus.
Also, last I heard, the Opteron will use Dual DDR memory, while Athlon64 will have to make do with single-channel DDR. Recall that both Hammer chips (SledgeHammer, aka Opteron, and ClawHammer, aka Athlon64), have the memmory controller integrated onto the CPU.
For both of these reasons, the Opteron and Athlon64 sockets are incompatible (Socket 754 vs Socket 940). There's an old review with plenty of information here
Plug the 64 bit controller into the 32 bit slot and let the PCI bus be your bottlneck. See their features under minimum system requirements, which specifiy 32 bit or 64 bit. Also, motherboard compatibility, which lists many chipsets without 64 bit pci.
The reason we went with 3ware controllers last time was that we were maxing out the pci bus. Moving to a 64 bit card solved that problem. It's too bad 3ware didn't opt for 66 MHz PCI instead of the wider bus. I wonder how much this has cost them?
I'm adding my vote for 3ware. You can get an 8 port IDE card for less than $400 or an 8 port SATA card for under $500. Beware big IDE raids, cabling issues become a major pain. We ended up using 36" (out of spec) rounded ide cables for our last 1.1 TB raid. I'm hoping that next time, we can use serial ata disks and the forthcoming 3ware raid card with native SATA. Their current offering uses the same chips as the 7500 IDE raid controller, combined with SATA bridges.
Do you really need hardware raid? These days disks are so big that you don't need RAID5 (and thus a beefy raid controller) unless you need an unholy amount of storage. For redunancy, RAID1 will do nicely, either in software or cheap hardware.
Have you actually compared VB and VB.NET? The only person I've talked to who has says that they are substantially different. VB.NET is more of a migration path to C#.
How exactly is SATA better than IEEE 1394 (firewire) for internal uses? Do you like being limited to the number of ports the motherboard manufacturer thought was necessary? 1394 allows you to chain devices, akin to scsi - much more convenient.
SATA requires a special power connector too, likely on the motherboard itself. 1394 gives you power too, in one little connector.
Linux certainly does support 1394. When our tape library failed at work, we replaced it with a bunch of firewire disks. Not only do they offer more storage at a lower cost, but they are all simultaneously online and are hell of a lot faster than tape. See linux1394.org
Do you really want to perpetuate the cruft that is ATA? You don't need drivers for SATA because it inherits many of PATA's limitations. Personally, i like hotswap (important for software raid) and i like isochonous transfer (good for cd burners as well as video streams). 1394 requires new drivers because it offers more. Linux has no problem reading 1394 drives. Windows has no problem reading 1394 drives. MacOS has no problem reading 1394 drives. How difficult would it have been to boot off of 1394? The only real obstacle is that anachonism - the PC BIOS. Replace with linuxBIOS and you'd be golden.
If Apple and Co had not decided to tax firewire, we would have had this years ago. Back in the days of the FX chipset, intel promised to include 1394 in it's motherboard chipsets, right next to USB. But no. They didn't want to be beholden to a third party, so they went off and invented the abomination that is USB2.
DDR333 is here now, but you won't see a 333MHz FSB until Hammer hits the scene. According to Toms' Hardware, you won't even see it in Barton. While a DDR333 connection to the northbridge might be nice for smp setups, it'll be wasted connected by a 133 MHz DDR interface to one cpu. It'll help, just not as much as it should.
The problem isn't that Blizzard reacted to bnetd: it's that they used a corrupt law to do it. Writing software that works with a commercial product shouldn't be a crime. They didn't violate copyright anymore than do marker manufactures. Making a tool than can be used illegally is a hideous standard.
The fact that bnetd is inconvenient to Blizzard shouldn't make it criminal. If that were the standard, HP could sue IBM on the grounds that selling computers cut into thier sales. Why, they might as well be stealing!
No I don't care about Joe Slashdot. If you don't speak up when the black hats come for the other guy, how can you expect the rest to help when they come for you?
The DMCA is a bad law, a bought law. The US handed copyright holders a Big Stick to use on it's own people. Until we can take it away, the least we can do is shun the ones that go around beating people up.