You're forgetting about the password salt. If this attacks becomes practical, all you need to do is to use a longer salt. You get exponential attack complexity for a linear amount of space.
You can have perfectly fine relational DBs without SQL, and arguably, relational DBs *are* better *without* SQL.
True, but because relational database engines are tightly connected to SQL-the-language, you can't switch language without switching engines. People who are good at designing computer languages usually aren't up to making an enterprise class database engine just to get their language out in the field...
The real power is when the whole OS knows the file is deduplicated. Virtuozzo supposedly provides this (I can't know for sure, I've had zero luck trying to buy anything from them). Then the OS can get away with only having each program in memory once, even if it's used in a hundred different VM's. That saves a lot of memory and if you're lucky it even gets you higher icache hit rates.
Desktops are obsolete and laptops aren't powerful enough to run the games. That keeps me from PC gaming. There's no way I can be bothered or justify the expense of setting up a desktop just for gaming, and I already have a laptop for everything else.
The only way it could work is if my HTPC became a gaming PC too. However that would interfere with its HTPC duties, it would require a more powerful box and hence no 10W idling (and possibly even be noisy, ouch!) and I'd be playing on the TV which negates most of the advantages of PC gaming in the first place.
SQL isn't the problem, it's a tool. Bad programmers are the problem.
Relational databases are quite useful. It's too bad they're hampered by such a lousy syntax though. It's like if we all decided to stick with COBOL but added closures and templates and whatnot...
Well in theory the right wing is all about individual freedom whereas the left wing is about what's good for everyone. This particular decision fits perfectly with that.
What is strange is all the OTHER decisions where the right wing has restricted individual freedom to do something which is good for everyone (or at least to prevent something which is bad for everyone).
off course, this would only be feasible for very small files, but/etc/shadow is usually small enough,
/etc/shadow is typically >1kB, which is 2^(1000*8) possibilities. A stupid brute force approach isn't going to work. If you can be sure which users exist in the file in which order, and root is the only one with a password, then maybe, but I doubt you could get it fast enough even in that case. If it turns out the be a threat we just need to increase the salt size.
Covert channels are fairly easy to achieve in a virtualized setup, particularly if you oversubscribe -- and if you don't oversubscribe you generally gain nothing from virtualization. Allocating physical CPU's, memory, network interfaces, and disks for each virtual server is impractical. Therefore I don't think the covert channel attack is much of a threat.
Detecting whether a particular file exists on other machines is interesting though. You can do that with Arkeia (deduplicating backup) I believe, by creating a particular file and checking how much data is actually sent across the network for that backup. If it's less than the compressed size of the file, then someone else on the same backup server has the same file...
The difference is that with multicast, each stream effectively gets a dynamically routed Internet address. Whenever someone starts viewing a stream, all the routers in between the sender and the receiver need to be informed that traffic to a particular multicast address has to be transmitted in a particular direction. When they stop viewing the stream, the routing needs to be updated again.
Those routers check if any routers it talks to requested that traffic, if so, it sends it
That's the problem. That requires a routing table equal to the number of simultaneous streams going through that particular router, with constant updates when viewers join or leave. In comparison, the IPv4 table has around 300000 entries and many core routers have limits around a million routes. Imagine if someone decided to do P2P by multicast (an otherwise quite reasonable design) -- how many torrents are running world wide right now?
Yes, K used to be 1024, now it's just useless. The k vs. K distinction broke down with M, and that's why we have trouble. M should never have been allowed to be binary, and it wasn't really for long. The gap between hard drives becoming common and them being measured in base 10 was short. Floppies went base 10 (more or less) already with the "1.44MB" drive.
This is not only practical, but makes sense in theory because it matches the physical layout of the sectors of the disk.
No it doesn't. What matches the physical layout of the sectors is a unit which is 1024 (well preferably 512 or 4096, but 1024 will do) for the first level and 1000 for each level after that. Hence, "1.44MB" floppy.
Good luck with getting people to switch to that one...
Telecommunications has always defined KB as 1000 bytes
Telecommunications tend to not count in bytes at all, and there's no capital-K unit in telecoms AFAIK.
Back in the 80's some people tried to make k=1000 and K=1024, which was quite reasonable. Unfortunately sizes eventually got to the point where M needed to be used...
Sure, if your machine's routing table is screwed so it thinks it can reach the server's IPv6 address when it can't then things will break, but that's just tough shit - if your configuration is completely broken then you shouldn't complain when things break badly.
Google loses about 0.7% of requests if they turn on AAAA's. Sure it's the fault of the customer, but that's real money lost for them.
Personally, I think they should just turn on the AAAA records and let the customers who have broken routers see that their routers are broken and fix them.
If you were Google, would you be willing to sacrifice 0.7% of your users just to be an IPv6 pioneer? They'd be gaining less than 0.01% of users who are IPv6 only.
Multicast doesn't automatically get deployed with IPv6.
Multicast across providers is an unsolved problem, quite possibly an unsolvable problem. Just forget about it, it's putting intelligence in the network and the whole point of the Internet is that the routers are stupid.
Well "everyone" handled South Africa, which ended peacefully. "Everyone" handled Serbia, which wasn't peaceful. "Everyone" handled Iraq after Kuwait was invaded.
I'm holding high hopes that Israel will be handled too, preferably peacefully of course.
There's no reason that your pissed off sysadmin needs access to the systems at the other sites. Anyway, it's conceivable that some security policies will require the use of tapes. I just doubt it'll be common enough to keep the tape industry going. The real money is in tape robots and those are just as much online as the disk arrays.
10Gbps is just a rented fiber away. As long as we're talking mere tens of km, that's fairly cheap. As soon as we're talking distances where you need active equipment in between it gets expensive, but I bet most tapes are kept within 50km of the tape drive used for writing them.
Isn't magnetic leakage onto nearby tape still a problem? Having to put the tape in a drive and let it wind its way through isn't much fun. Not much of a problem in a tape robot, but then the competition to a tape robot is a disk array where they'll be running a good fraction of the time. It's much easier to do regular verification on a disk array; there's enough bandwidth that you can even do it weekly.
Slashdot Mirror
You're forgetting about the password salt. If this attacks becomes practical, all you need to do is to use a longer salt. You get exponential attack complexity for a linear amount of space.
You can have perfectly fine relational DBs without SQL, and arguably, relational DBs *are* better *without* SQL.
True, but because relational database engines are tightly connected to SQL-the-language, you can't switch language without switching engines. People who are good at designing computer languages usually aren't up to making an enterprise class database engine just to get their language out in the field...
US cars don't do corners, remember?
Formula 1 racing requires physical fitness. I'm not sure whether that's particularly important for it being a sport, but anyway.
The real power is when the whole OS knows the file is deduplicated. Virtuozzo supposedly provides this (I can't know for sure, I've had zero luck trying to buy anything from them). Then the OS can get away with only having each program in memory once, even if it's used in a hundred different VM's. That saves a lot of memory and if you're lucky it even gets you higher icache hit rates.
Desktops are obsolete and laptops aren't powerful enough to run the games. That keeps me from PC gaming. There's no way I can be bothered or justify the expense of setting up a desktop just for gaming, and I already have a laptop for everything else.
The only way it could work is if my HTPC became a gaming PC too. However that would interfere with its HTPC duties, it would require a more powerful box and hence no 10W idling (and possibly even be noisy, ouch!) and I'd be playing on the TV which negates most of the advantages of PC gaming in the first place.
SQL isn't the problem, it's a tool. Bad programmers are the problem.
Relational databases are quite useful. It's too bad they're hampered by such a lousy syntax though. It's like if we all decided to stick with COBOL but added closures and templates and whatnot...
Well in theory the right wing is all about individual freedom whereas the left wing is about what's good for everyone. This particular decision fits perfectly with that.
What is strange is all the OTHER decisions where the right wing has restricted individual freedom to do something which is good for everyone (or at least to prevent something which is bad for everyone).
off course, this would only be feasible for very small files, but /etc/shadow is usually small enough,
/etc/shadow is typically >1kB, which is 2^(1000*8) possibilities. A stupid brute force approach isn't going to work. If you can be sure which users exist in the file in which order, and root is the only one with a password, then maybe, but I doubt you could get it fast enough even in that case. If it turns out the be a threat we just need to increase the salt size.
Covert channels are fairly easy to achieve in a virtualized setup, particularly if you oversubscribe -- and if you don't oversubscribe you generally gain nothing from virtualization. Allocating physical CPU's, memory, network interfaces, and disks for each virtual server is impractical. Therefore I don't think the covert channel attack is much of a threat.
Detecting whether a particular file exists on other machines is interesting though. You can do that with Arkeia (deduplicating backup) I believe, by creating a particular file and checking how much data is actually sent across the network for that backup. If it's less than the compressed size of the file, then someone else on the same backup server has the same file...
The difference is that with multicast, each stream effectively gets a dynamically routed Internet address. Whenever someone starts viewing a stream, all the routers in between the sender and the receiver need to be informed that traffic to a particular multicast address has to be transmitted in a particular direction. When they stop viewing the stream, the routing needs to be updated again.
Those routers check if any routers it talks to requested that traffic, if so, it sends it
That's the problem. That requires a routing table equal to the number of simultaneous streams going through that particular router, with constant updates when viewers join or leave. In comparison, the IPv4 table has around 300000 entries and many core routers have limits around a million routes. Imagine if someone decided to do P2P by multicast (an otherwise quite reasonable design) -- how many torrents are running world wide right now?
Yes, K used to be 1024, now it's just useless. The k vs. K distinction broke down with M, and that's why we have trouble. M should never have been allowed to be binary, and it wasn't really for long. The gap between hard drives becoming common and them being measured in base 10 was short. Floppies went base 10 (more or less) already with the "1.44MB" drive.
This is not only practical, but makes sense in theory because it matches the physical layout of the sectors of the disk.
No it doesn't. What matches the physical layout of the sectors is a unit which is 1024 (well preferably 512 or 4096, but 1024 will do) for the first level and 1000 for each level after that. Hence, "1.44MB" floppy.
Good luck with getting people to switch to that one...
An int is 4 bytes.
All the world's a VAX.
Telecommunications has always defined KB as 1000 bytes
Telecommunications tend to not count in bytes at all, and there's no capital-K unit in telecoms AFAIK.
Back in the 80's some people tried to make k=1000 and K=1024, which was quite reasonable. Unfortunately sizes eventually got to the point where M needed to be used...
An IBM "1.44MB" floppy is 1.44*1000*1024 bytes.
Sure, if your machine's routing table is screwed so it thinks it can reach the server's IPv6 address when it can't then things will break, but that's just tough shit - if your configuration is completely broken then you shouldn't complain when things break badly.
Google loses about 0.7% of requests if they turn on AAAA's. Sure it's the fault of the customer, but that's real money lost for them.
Personally, I think they should just turn on the AAAA records and let the customers who have broken routers see that their routers are broken and fix them.
If you were Google, would you be willing to sacrifice 0.7% of your users just to be an IPv6 pioneer? They'd be gaining less than 0.01% of users who are IPv6 only.
Multicast doesn't automatically get deployed with IPv6.
Multicast across providers is an unsolved problem, quite possibly an unsolvable problem. Just forget about it, it's putting intelligence in the network and the whole point of the Internet is that the routers are stupid.
Well "everyone" handled South Africa, which ended peacefully. "Everyone" handled Serbia, which wasn't peaceful. "Everyone" handled Iraq after Kuwait was invaded.
I'm holding high hopes that Israel will be handled too, preferably peacefully of course.
That's usually what victors do after a war. France did it to Germany, and no one's complaining.
I hope you won't mind when everyone gets their minds together and take it back from Israel then. The WMD excuse ought to work this time.
There's no reason that your pissed off sysadmin needs access to the systems at the other sites. Anyway, it's conceivable that some security policies will require the use of tapes. I just doubt it'll be common enough to keep the tape industry going. The real money is in tape robots and those are just as much online as the disk arrays.
10Gbps is just a rented fiber away. As long as we're talking mere tens of km, that's fairly cheap. As soon as we're talking distances where you need active equipment in between it gets expensive, but I bet most tapes are kept within 50km of the tape drive used for writing them.
LTO-4 is a meagre 800GB per tape. 2.5 LTO tapes take up more room than a 2TB hard drive.
Isn't magnetic leakage onto nearby tape still a problem? Having to put the tape in a drive and let it wind its way through isn't much fun. Not much of a problem in a tape robot, but then the competition to a tape robot is a disk array where they'll be running a good fraction of the time. It's much easier to do regular verification on a disk array; there's enough bandwidth that you can even do it weekly.