Tell that to my T61, which mysteriously BSOD'd twice while installing. And I'm hardly the only one to encounter issues like this.
The Vista compatability checker, which runs first, has always warned me about hardware for which no drivers exist. I don't have a T61, but my org has a large mix of desktop and laptop hardware and we haven't had any Vista install issues.
That said, I have never gotten any network connectivity out of the box installing Linux on my semi-vintage Dell 700m. I've tried Ubuntu 6.10 and Fedora 6. The install completes, but no network is there, and no obvious errors or any help is given for resolving the issues. Yeah, I went online and an hour of searching on another machine, readining conflicting postings scattered over dozens of sites, and some arcane edits to config files, I was able to make the wired 100mbit adapter work. But still no wireless connectivity, even though the adapter is listed as up.
I'm not really sure how the "setup update process" can "sort it all out" if there's no Vista drivers for a particular piece of hardware
True, if no drivers exist, you're screwed. The same is true on the Linux side, which supports even less hardware. My point was that the Vista setup updater will find missing and newer drivers online automatically if you can get some form of network connection with the base installer. Basic network connectivity is is possible on most hardware I've tested with Vista. If Vista doesn't support your network hardware, you can be damned sure probably won't, either.
Actually, it really really isn't. Compared with 2000 and XP - and Linux - Vista installers are very informative and provide quite a bit of information about what will and will not work, especially during upgrades. For clean installs, it is a bit less clear, but so long as you can get a network connection of some sort with your hardware, the setup update process will usually sort it all out on PIII or newer hardware.
IANA wants ISPs to implement v6. They COULD offer a discount on the allocation fees for people who choose to give them what they want.
IPv4 allocation fees are such a small part of the total cost structure for an ISP that IANA doesn't have any leverage. As IPv4 addresses become scarce, and an after-market develops and prices increase, IANA might gain some of that power. If IANA were to arbitrarily raise fees now, when there is still IPv4 address space available, there would be a major revolt, and another registry would likely be set up and IANA would lose its power completely.
Anyways, does using RAID help random access times? I wouldn't think so. Your random access time would be the random access time of which ever drive is slowest. So it wouldn't affect it much, but maybe like 1ms or so.
That's true for a single random read access, but when you have a whole bunch of random accesses to do in a short period of time, the work is essentially divided amongst the drives in the RAID set, as the blocks are distributed randomly amongst the drives in the RAID set. Total throughput for random reads per second will essentialy be multiplied by the number of drives.
This read throughput inprovement holds in RAID 5 and RAID 0, and most other hybrid RAID modes such as RAID 6 and RAID 10. It is not generally true for write I/Os, which are more complex and time consuming depending on the RAID mode.
Windows terminal services sessions are encrypted with 128-bit RC4. The Remote Assistance feature utilizes WTS. The shared secret (the password) is used to protect the terminal services session key, so password strength is an issue.
I'll grant you that VNC sessions are not encrypted, but that's true on Linux as well. You need to use an SSH wrapper (also possible and just as easy on Windows as it is on Linux), or a VPN of some sort.
First: the consumers aren't liable for fraud, and neither are Visa or MC. It's the merchants who are liable. So they are the only ones who would benefit from a new smartcard system. Wal-mart and Target and other large merchants need to get their act together and push for something. Visa/MC and even consumers have no reason to do so. Regulation is not the answer - see various smart-card deployment failures in Europe since the 1980s.
Amex actually came out with a smartcard/creditcard combo called, I think, "Blue". It went nowhere in the market, probably because no merchants upgraded their hardware to access the smartcard features. Why wouldn't merchants upgrade, if it meant lower risk? Few merchants accept Amex in the first place, because their fees are so high. And very few consumers carry Amex - it's mostly used by businesses for expense accounts and the like. So why would a merchant spend thousands to accept thier new card? Chicken and egg.
As for IPv6 deployment, I see again you propose some sort of regulation to make things work the way you'd like. I think you're naive if you think effective regulation of the Internet is even possible, or that it could possibly be beneficial. The U.N. can't deliver *food* to starving people without massive corruption and waste - what do you think would happen if they or a similar beauracracy were given control of the Internet?
I'm reminded of a quote: "Democrats are the party that promise you their government will make you richer, smarter, taller, and get the chickweed out of your lawn. Republicans are the party that says government doesn't work, and then they get elected and prove it." -PJ O'Rourke
Okay, you go ahead and convince everybody to change.
The problem with replacing credit cards with smart cards or something better is the same as the problem with deploying IPv6. Nobody wants to be a first mover, as there's not much value until a significant percentage of everybody else is using the new stuff, too. Clasic chicken and egg problem.
Things like chip-and-PIN can get implemented in Europe by legislative fiat. There's a lot of resistance to that sort of thing on this side of the pond.
Not in a real OS (read: non-Windows OS). In real OSes, you can allocate pages and indicate that they may never be swapped out of volatile memory for exactly that reason.
Your bias is showing, AC. Allocating un-swappable memory is very easy in Windows as well, just not in a high-level language like, say PHP. If you want to use C or C++, it's simple. Try at least peeking at MSDN before your knee jerks and you say "Windows can't do that".
The CFO won't let us yet... there are still apparently some transactions which require the card number and human intervention. They're working on eliminating those.
A little more effort, but just use a second database but not the regular kind, but an in-memory database. That way the CC data is in a physically separate database and a SQL-injection in your main database can't get the CC data. Also nothing is written to the disc (except possibly swap file, but I think that is not really a big concern). There seem to be some OSS versions, sorry I only know of them, I have never used one.
Good idea. From a developer perspective, it would probably be easiest to use the same database application as the rest of the system, with the files stored on a RAM disk instead of on a physical disk. It could be dynamically created at application startup via script with empty tables.
You're missing the point. The encryption doesn't prevent anything in 90% of applications, because the key mangement is terrible. You might was well just use base64 encoding and save the CPU cycles. Just using an AES-256 library function doesn't make the data secure.
Most applications I've seen - quite a few, both in-house and off-the-shelf - use a fixed symmetric key for credit card encryption, stored right in the application code or in a configuration file. Often this key is on the same server as the database, and even if it is not, the app server probably has the same vulnerabilies and probably the same passwords that gave you access to the database. They also typically don't use a unique initialization vector for each database row, so a dictionary attack against the encrypted card data is often dead simple (often the cipher and mode of operation are chosen poorly as well, and there's only about 30 bits of entropy in a credit card number).
Doing encryption key management correctly is not easy. To do it right, you'd need to use public key encryption, or a Kerberos-like system where an entered password can temporarily unlock a copy of the shared encryption key. Better yet, use hardware key escrow. And don't forget the need to revoke keys, and change them often.
It's much easier and safer to just to throw away the card numbers and CVC as soon as you get the auth code from Visa. Right now we keep card data only for as long as it takes the transaction to settle. But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too).
Certainly it is a useful tool. Just becuase the decompiler was written by a Microsoft employee doesn't mean you can use it to decompile Microsoft code in violation of a license agreement and/or copyright.
IANAL, but decompiling would seem to require copying of some sort. It's really just a form of translation. As such, the copyright holder must grant you a license to decompile, which Microsoft explicitly does not.
Decompiling Microsoft's code is a clear violation of their license agreement. It also may be a criminal offense, depending on where and for what purpose that code is decompiled.
Respect for copyright and license agreements should be a high priority for any software developer of open or closed source software. But then again, hypocrisy knows no bounds on Slashdot.
The U.S. is not the only nation with cryptography export restrictions, which in any case have been relaxed for many years now. In fact a great many other nations now have more restrictive laws with regards to cryptography than the USA, as they restrict import and export as well as use by citizens. France, for example.
So why is there no "non-China" repository in Debian, as they restrict import and use of cryptograhic technology? Smells like politics to me...
Traceroutes seem to indicate that FastServers lease space from web.com, who leases space from Peer1.net, who buys bandwidth from AT&T. That's a house of cards if I ever saw one.
Here is a list of real, "tier 1" hosting providers. They actually own the networks and data centers. My company has 70% of its revenue tied to our web presence, with about 20 servers. We only deal with these vendors (two of them). A fully managed, SLA'd server will run $500-1500 per month from one of these guys depending on configuration. We've had basically zero downtime since 2001, other than thsoe caused by our own coding problems.
Actually, don't neglect the convergence of the NAS and SAN markets. This puts Hitachi and IBM into the mix at tier 1 as well, along with players like LeftHand and EqualLogic as well. It's a very crowded space.
Actually, I think the formerly-pure-play iSCSI providers like EqualLogic and LeftHand have the most interesting products, with "stackable" scalability that's diffucult to match with a dedicated controller topology. But their services organizations aren't yet there compared with the Tier-1 vendors. I speak from experience. The gear itself works well, though.
Nearly every link on that page is broken, or from a source which indicates that MSFT is alleged to have done something, but also highlights that there is no real evidence and a lot of conjecture (the Wired articles). Or, the source is the Register, which means it is worthless.
The only valid link that seems to report hard evidence of astro-turfing is the ZDnet web services online poll ballot stuffing. But that's not really astro-turfing IMHO: as the people voting were MSFT employees, and made no attempt to hide that they were voting from Microsoft-owned IP addresses and mail clients.
Where is the Computerworld, WSJ, or other "hard journalism" expose of these astro-turfing practices? True journalism means multiple cross-validated (but still possibly anonymous) sources, or at the very least a single non-anonymous source.
And yeah, I know MSFT does a lot of advertising, but surely some brave journalist or editor would be willing to "buck the machine" if they had the true story dead-bang.
You chose to move to Bumblefuck, AK, knowing that you would forgo many of the benefits of living in an urban area (such as easy access to a wide variety of goods and services). Shut the hell up, please. You can't have your cheap land, clear skies, *and* the benefits of urban living. Nobody's going to spend $25K to run fiber to your cabin so you can complain about paying them $100 per month. There's are reasons humans have built cities for thousands of years, and chief among those are to provide a nexus for trade, and make sharing expensive infrastructure easier.
Xen is an open source GPLv2 hypervisor... so the cost benefits of open source could still appear. Anyway, the kernel will not ever be GPLv3 (according to Linus, and more for practical rather than political reasons. Some of the people who own the copyright to GPLv2 kernel code are dead!).
Windows just don't belong on a battleship or aircraft carrier.
Why not? A Naval vessel is (presumably) a closed system. There should be little, if any, concerns about interoperability with the outside world. The should be few, if any, points of egress/ingress for data on a Naval ship. Maybe a dedicated sattelite link for updating position and orders, in a strictly controlled manner. Anything else would seem to be a huge security risk. Presumably you can trust the sailors on the ship to some extent.
Take a look at SPECjbb2005 or TPC-C, which resemble "real" applications a lot more than SPECint_rate. The Quad-core Xeons are 70-100% faster than the fastest dual-core Opteron systems.
As much as I wish it weren't so, AMD has been toasted in the two-socket server space, which is the largest part of the server market. Barcelona proabably won't change that, as Penryn will arrive at the same time.
Your experience isn't shread by me, or by most other benchmarkers. Take a look at multi-threaded SPEC benchmarks for the Xeon 5300 series. SPEC_int_rate 2006, SPEC JBB_2005, etc, all show the Xeon 5300 as the clear per-socket performance leader for x86 systems. The quad-core Xeons are only bested by the IBM POWER 6, and Niagra in the Java benchmarks.
See the SPECint_rate 2006 results page, and filter on two-chip systems.
Perhaps your particular application is a degenerate case for the 5300s cache architecture, but I have to tell you our Xeon X5355 based Dells are (by almost a factor of two) the fastest dual-socket application servers we have, much faster than the dual-core Opteron systems we have that run the same apps and are just a few months older.
Slashdot Mirror
The Vista compatability checker, which runs first, has always warned me about hardware for which no drivers exist. I don't have a T61, but my org has a large mix of desktop and laptop hardware and we haven't had any Vista install issues.
That said, I have never gotten any network connectivity out of the box installing Linux on my semi-vintage Dell 700m. I've tried Ubuntu 6.10 and Fedora 6. The install completes, but no network is there, and no obvious errors or any help is given for resolving the issues. Yeah, I went online and an hour of searching on another machine, readining conflicting postings scattered over dozens of sites, and some arcane edits to config files, I was able to make the wired 100mbit adapter work. But still no wireless connectivity, even though the adapter is listed as up.
True, if no drivers exist, you're screwed. The same is true on the Linux side, which supports even less hardware. My point was that the Vista setup updater will find missing and newer drivers online automatically if you can get some form of network connection with the base installer. Basic network connectivity is is possible on most hardware I've tested with Vista. If Vista doesn't support your network hardware, you can be damned sure probably won't, either.
Actually, it really really isn't. Compared with 2000 and XP - and Linux - Vista installers are very informative and provide quite a bit of information about what will and will not work, especially during upgrades. For clean installs, it is a bit less clear, but so long as you can get a network connection of some sort with your hardware, the setup update process will usually sort it all out on PIII or newer hardware.
IPv4 allocation fees are such a small part of the total cost structure for an ISP that IANA doesn't have any leverage. As IPv4 addresses become scarce, and an after-market develops and prices increase, IANA might gain some of that power. If IANA were to arbitrarily raise fees now, when there is still IPv4 address space available, there would be a major revolt, and another registry would likely be set up and IANA would lose its power completely.
That's true for a single random read access, but when you have a whole bunch of random accesses to do in a short period of time, the work is essentially divided amongst the drives in the RAID set, as the blocks are distributed randomly amongst the drives in the RAID set. Total throughput for random reads per second will essentialy be multiplied by the number of drives.
This read throughput inprovement holds in RAID 5 and RAID 0, and most other hybrid RAID modes such as RAID 6 and RAID 10. It is not generally true for write I/Os, which are more complex and time consuming depending on the RAID mode.
Windows terminal services sessions are encrypted with 128-bit RC4. The Remote Assistance feature utilizes WTS. The shared secret (the password) is used to protect the terminal services session key, so password strength is an issue.
I'll grant you that VNC sessions are not encrypted, but that's true on Linux as well. You need to use an SSH wrapper (also possible and just as easy on Windows as it is on Linux), or a VPN of some sort.
First: the consumers aren't liable for fraud, and neither are Visa or MC. It's the merchants who are liable. So they are the only ones who would benefit from a new smartcard system. Wal-mart and Target and other large merchants need to get their act together and push for something. Visa/MC and even consumers have no reason to do so. Regulation is not the answer - see various smart-card deployment failures in Europe since the 1980s.
Amex actually came out with a smartcard/creditcard combo called, I think, "Blue". It went nowhere in the market, probably because no merchants upgraded their hardware to access the smartcard features. Why wouldn't merchants upgrade, if it meant lower risk? Few merchants accept Amex in the first place, because their fees are so high. And very few consumers carry Amex - it's mostly used by businesses for expense accounts and the like. So why would a merchant spend thousands to accept thier new card? Chicken and egg.
As for IPv6 deployment, I see again you propose some sort of regulation to make things work the way you'd like. I think you're naive if you think effective regulation of the Internet is even possible, or that it could possibly be beneficial. The U.N. can't deliver *food* to starving people without massive corruption and waste - what do you think would happen if they or a similar beauracracy were given control of the Internet?
I'm reminded of a quote:
"Democrats are the party that promise you their government will make you richer, smarter, taller, and get the chickweed out of your lawn. Republicans are the party that says government doesn't work, and then they get elected and prove it." -PJ O'Rourke
Okay, you go ahead and convince everybody to change.
The problem with replacing credit cards with smart cards or something better is the same as the problem with deploying IPv6. Nobody wants to be a first mover, as there's not much value until a significant percentage of everybody else is using the new stuff, too. Clasic chicken and egg problem.
Things like chip-and-PIN can get implemented in Europe by legislative fiat. There's a lot of resistance to that sort of thing on this side of the pond.
Umm... I did mention "hardware key escrow". Which implies either a smart card or a TPM of some sort.
Your bias is showing, AC. Allocating un-swappable memory is very easy in Windows as well, just not in a high-level language like, say PHP. If you want to use C or C++, it's simple. Try at least peeking at MSDN before your knee jerks and you say "Windows can't do that".
The CFO won't let us yet... there are still apparently some transactions which require the card number and human intervention. They're working on eliminating those.
Good idea. From a developer perspective, it would probably be easiest to use the same database application as the rest of the system, with the files stored on a RAM disk instead of on a physical disk. It could be dynamically created at application startup via script with empty tables.
You're missing the point. The encryption doesn't prevent anything in 90% of applications, because the key mangement is terrible. You might was well just use base64 encoding and save the CPU cycles. Just using an AES-256 library function doesn't make the data secure.
Most applications I've seen - quite a few, both in-house and off-the-shelf - use a fixed symmetric key for credit card encryption, stored right in the application code or in a configuration file. Often this key is on the same server as the database, and even if it is not, the app server probably has the same vulnerabilies and probably the same passwords that gave you access to the database. They also typically don't use a unique initialization vector for each database row, so a dictionary attack against the encrypted card data is often dead simple (often the cipher and mode of operation are chosen poorly as well, and there's only about 30 bits of entropy in a credit card number).
Doing encryption key management correctly is not easy. To do it right, you'd need to use public key encryption, or a Kerberos-like system where an entered password can temporarily unlock a copy of the shared encryption key. Better yet, use hardware key escrow. And don't forget the need to revoke keys, and change them often.
It's much easier and safer to just to throw away the card numbers and CVC as soon as you get the auth code from Visa. Right now we keep card data only for as long as it takes the transaction to settle. But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too).
Certainly it is a useful tool. Just becuase the decompiler was written by a Microsoft employee doesn't mean you can use it to decompile Microsoft code in violation of a license agreement and/or copyright.
IANAL, but decompiling would seem to require copying of some sort. It's really just a form of translation. As such, the copyright holder must grant you a license to decompile, which Microsoft explicitly does not.
Decompiling Microsoft's code is a clear violation of their license agreement. It also may be a criminal offense, depending on where and for what purpose that code is decompiled.
Respect for copyright and license agreements should be a high priority for any software developer of open or closed source software. But then again, hypocrisy knows no bounds on Slashdot.
The U.S. is not the only nation with cryptography export restrictions, which in any case have been relaxed for many years now. In fact a great many other nations now have more restrictive laws with regards to cryptography than the USA, as they restrict import and export as well as use by citizens. France, for example.
So why is there no "non-China" repository in Debian, as they restrict import and use of cryptograhic technology? Smells like politics to me...
This bug does not appear in Excel 2003 Service Pack 3, which was released a few weeks ago. That build number is 11.8169.8172.
Traceroutes seem to indicate that FastServers lease space from web.com, who leases space from Peer1.net, who buys bandwidth from AT&T. That's a house of cards if I ever saw one.
Here is a list of real, "tier 1" hosting providers. They actually own the networks and data centers. My company has 70% of its revenue tied to our web presence, with about 20 servers. We only deal with these vendors (two of them). A fully managed, SLA'd server will run $500-1500 per month from one of these guys depending on configuration. We've had basically zero downtime since 2001, other than thsoe caused by our own coding problems.
Actually, don't neglect the convergence of the NAS and SAN markets. This puts Hitachi and IBM into the mix at tier 1 as well, along with players like LeftHand and EqualLogic as well. It's a very crowded space.
Actually, I think the formerly-pure-play iSCSI providers like EqualLogic and LeftHand have the most interesting products, with "stackable" scalability that's diffucult to match with a dedicated controller topology. But their services organizations aren't yet there compared with the Tier-1 vendors. I speak from experience. The gear itself works well, though.
So, essentially, "I have no real evidence, and nobody else seems to either, but I know it to be true, because I really hate MSFT."
Nearly every link on that page is broken, or from a source which indicates that MSFT is alleged to have done something, but also highlights that there is no real evidence and a lot of conjecture (the Wired articles). Or, the source is the Register, which means it is worthless.
The only valid link that seems to report hard evidence of astro-turfing is the ZDnet web services online poll ballot stuffing. But that's not really astro-turfing IMHO: as the people voting were MSFT employees, and made no attempt to hide that they were voting from Microsoft-owned IP addresses and mail clients.
Where is the Computerworld, WSJ, or other "hard journalism" expose of these astro-turfing practices? True journalism means multiple cross-validated (but still possibly anonymous) sources, or at the very least a single non-anonymous source.
And yeah, I know MSFT does a lot of advertising, but surely some brave journalist or editor would be willing to "buck the machine" if they had the true story dead-bang.
Can you post a link, please to credible evidence of that? I see it posted all the time, I haven't seen any real evidence that it is true.
You chose to move to Bumblefuck, AK, knowing that you would forgo many of the benefits of living in an urban area (such as easy access to a wide variety of goods and services).
Shut the hell up, please. You can't have your cheap land, clear skies, *and* the benefits of urban living. Nobody's going to spend $25K to run fiber to your cabin so you can complain about paying them $100 per month.
There's are reasons humans have built cities for thousands of years, and chief among those are to provide a nexus for trade, and make sharing expensive infrastructure easier.
Xen is an open source GPLv2 hypervisor... so the cost benefits of open source could still appear. Anyway, the kernel will not ever be GPLv3 (according to Linus, and more for practical rather than political reasons. Some of the people who own the copyright to GPLv2 kernel code are dead!).
Why not? A Naval vessel is (presumably) a closed system. There should be little, if any, concerns about interoperability with the outside world. The should be few, if any, points of egress/ingress for data on a Naval ship. Maybe a dedicated sattelite link for updating position and orders, in a strictly controlled manner. Anything else would seem to be a huge security risk. Presumably you can trust the sailors on the ship to some extent.
Take a look at SPECjbb2005 or TPC-C, which resemble "real" applications a lot more than SPECint_rate. The Quad-core Xeons are 70-100% faster than the fastest dual-core Opteron systems.
As much as I wish it weren't so, AMD has been toasted in the two-socket server space, which is the largest part of the server market. Barcelona proabably won't change that, as Penryn will arrive at the same time.
Your experience isn't shread by me, or by most other benchmarkers. Take a look at multi-threaded SPEC benchmarks for the Xeon 5300 series. SPEC_int_rate 2006, SPEC JBB_2005, etc, all show the Xeon 5300 as the clear per-socket performance leader for x86 systems. The quad-core Xeons are only bested by the IBM POWER 6, and Niagra in the Java benchmarks.
See the SPECint_rate 2006 results page, and filter on two-chip systems.
Perhaps your particular application is a degenerate case for the 5300s cache architecture, but I have to tell you our Xeon X5355 based Dells are (by almost a factor of two) the fastest dual-socket application servers we have, much faster than the dual-core Opteron systems we have that run the same apps and are just a few months older.