I wasn't sure at first if they were setting the data by doping the material, but on closer reading "The engineers manipulated the nanomaterial so the electrons' spin within the material could be controlled,..." makes it sound electrically re-writeable. Which is probably the only thing anyone's really interested in, unless it was super-cheap. (i.e. cheap enough to replace pressed optical discs with ROM USB-storage.)
As bobjr94 hopes, it would be nice if it is that cheap, though, and optical discs are replaced by a standard flash storage standard.
the + instead of ';' makes it collect up multiple arguments to grep like xargs instead of the traditional find -exec behaviour which is like xargs -n1. I use -exec {} + all the time, because it's less typing, and safe with filenames with punctuation or whitespace, so you don't have to type -print0 | xargs -0 either. (BTW, if you have a list of filenames that you processes with something line oriented, you can use xargs -d'\n')
except electric heaters, stoves, and incandescent lights. They're all just resistors that get hot. Power factor = 1.0.
> then 50% of the power you're using isn't being measured by the power company's basic meters.
The "extra" power (Apparent power (Volts * Amps) - real power (actual Watts accounting for phase) is only wasted by the inefficiency of your transmission lines.
Other people have already explained this in detail in this thread.
Other than that, good try at explaining this for people who don't already know.
> Mount users' home directories noexec, don't give users root access.
noexec doesn't stop you from running/lib/ld.so on an ELF binary, or/bin/bash on a shell script. Or whatever interpreter you want, if it's installed.
Most people who know how to do that also know enough to avoid breaking things. But they might not have the self-discipline to stop playing games. Other than that, yeah, use firewalls and network policy.
See slide 17 in the presentation. But the trick is, your forged reply to a query for 83.foo.com is:
83.foo.com IN NS www.foo.com (83.foo.com is a subdomain, whose name server is www.foo.com) www.foo.com IN A 6.6.6.6 (glue)
So I guess I still agree with you, that BIND must be trusting more than it needs to. Caches could distrust any glue except when it has to. (I think the glue is only necessary when the name server is part of the domain it's serving. e.g. The glue would be needed if the name server was ns1.83.foo.com. Otherwise why not ask the.foo.com server for www.foo.com's A record, or use a cached one, instead of trusting the glue?)
IIRC, djbdns is skeptical of glue. I remember reading a big rant about glue on DJB's web site years ago. I'm not sure if that's why it's not vulnerable, or if it's because it already did source-port randomization.
Anyway, that presentation seems to cover a lot of what I wanted to know. In the worst case, you have a cache that trusts glue, and you can poison it by guessing a 16bit ID. In the even worse case, multiple requests for the same name leave the cache willing to accept more than 1 ID for a single response, leading to a birthday attack.
The trick is to generate lots of DNS queries for names you choose when the server isn't run by idiots (accepting recursive queries from the whole Internet). Web log analyzers are one possible vector. Otherwise if you can feed HTML to something that will resolve names for IMG tags, or presumably javascript could go nuts...
So, the dirty fix is to always request a random bogus sub-domain before making the real request?
No, cache misses for A records don't make a recursive resolver go back to the parent domain for an updated NS record. If a cache was poisoned so it thought.bank.com queries were handled by w.x.y.z (the attackers IP), a request for nonexistant.bank.com would cause it to send an A request for the name to w.x.y.z, but not go back to the.com servers to find out which server is authoritative for.bank.com. (It will do that once the cached NS record for.bank.com expires, which could be weeks. Or until another black hat re-poisons that cache.).
ArsenneLupin, this topic must be right up your alley, since you've stolen your name from a master thief.:)
I was going to say, don't browsers have copies of the root certificates locally, and require a chain of signatures from them to anything they're going to accept without complaint. But I didn't realize that one could potentially get another cert for a domain without anyone checking with the people who have the first cert.
Now I understand how the pieces could fit together to play man-in-the-middle with a bank. Otherwise I couldn't see how you could get a valid SSL certificate for yourtarget.com. Which you _need_ if people are going to access your fake site with SSL, and you're not just proxying the traffic to the real yourtarget.com without decrypting it.
Even with the low-validation certs you mentioned, where you just need to be able to receive mail at the domain, and have a phone, I would have hoped they wouldn't issue certificates for domains that they (or another cert authority) have already issued or signed a previous cert for.
BTW, the article makes this sound way easier than this, esp. since it's talking about the cert vendors selling encryption, when they actually sell trust. The encryption is free (and easy). Trust is hard, and can be worth paying for. The article was a real mixed bag: painfully bad technical sections, but I loved reading about Vixie's response, calling people and telling them to fly to the west coast without telling them why. That's serious paranoia about even traffic analysis of email (assuming you could trust PGP).
I wasn't familiar with the attack, and this article isn't really helping much. I guess I'll just look it up elsewhere. I know its not for a technical audience, but I wish people wouldn't say things that are more or less wrong. Since when is a hostname = a web page? This is so wrong that it makes the article painful to read. (Which is unfortunate, because the personal story is somewhat interesting.) And the article has a few more-technical bits later, so why stoop to being so wrong at the start?
a couple examples from the main article:
... He used a software program called Scapy to fire random queries at the system. He liked to see how it would respond and decided to ask for the location of a series of nonexistent Web pages at a Fortune 500 company. Then he tried to trick his DNS server in San Diego into thinking that he knew the location of the bogus pages.
If I didn't understand DNS and HTTP, I might be thinking this had something to do with HTTP 404 errors. Most people have seen the difference between a bad page on a good server and a server that doesn't exist at all.
Suddenly it worked. The server accepted one of the fake pages as real. But so what? He could now supply fake information for a page nobody would ever visit. Then he realized that the server was willing to accept more information from him. Since he had supplied data about one of the company's Web pages, it believed that he was an authoritative source for general information about the company's domain. The server didn't know that the Web page didn't existâ"it was listening to Kaminsky now, as if it had been hypnotized.
Hypnotized? WTF? This sounds like hollywood-hacking to me. Just a case of misplaced trust. Otherwise this paragraph isn't so bad. (except for saying pages instead of names. He already made a directory assistance analogy, why not continue with DNS = phonebook metaphors. e.g. computers need a number to call another computer, but people like to use names... Or don't people understand that web servers are just computers like their own?)
yeah, I don't think I'm remembering the 500fps correctly. I get 550fps with mesa 7.2 on a C2D E6600 (dual core 2.4GHz), Ubuntu pre-Intrepid AMD64. Tested in a Xephyr X server. I get 1170fps on my g965, which is in the same ballpark as software.
> I imagine a card could be built such that it would never run more than a few hundred FPS, but would render massive scenes at a comfortable 60 (vsync'd).
glxgears speeds are all about driver overhead, locking/unlocking and stuff like that. So yeah, not at all implausible, esp. with immature drivers that weren't very efficient and were cpu-bound at high FPS.
Why would you use loopback when Linux can use swap files directly. They don't have to be block devices.
For dynamics swap creation, check out swapspace(8), or swapd(8). They have to fill a file with zeros right when the system is under memory pressure and swapping, though. I use swapspace(8), and I like it. A runaway process will make the system thrash even harder, but if something is growing slowly it's great.
What would help them would be an API like XFS's reserve space ioctl (xfs_io resvspace...), but that worked for making swap files. XFS reserved space is still marked a unwritten, so it reads as zero, not as the data that was on the disk before. (old xfs without unwritten extent support worked for this, but it's a nasty security hole to expose stale disk data to anyone. A new API could allow it only for root, or for someone who could read the blockdev the FS is on anyway.)
I've found that the default swappiness = 60 was bad if you're running a bittorrent client on your desktop. When I came back to the computer, programs like firefox would always be swapped out and take > 10 seconds to get going. It was a couple years ago that I started setting swappiness = 30 or 10, so I don't know if Linux has changed any. Anyway, p2p filesharing makes Linux think it's a good idea to cache files for what should be low priority I/O, at the expense of your desktop.
Hmm, I wonder if ionice affects Linux's desire to push other things out of memory to cache files...
glxgears is such a simple scene (no textures, for one thing) that even software rendering is not slow. Way back in the day on a P200MMX, maybe HW 3D was needed for a fast glxgears...
These days a core2 can run glxgears _really_ fast. e.g. 3GHz Harpertown gets > 500fps, IIRC.
As others have said, streaming un-paid-for unencrypted video is dumb.
You could send the first couple minutes unencrypted since anyone can watch it free (preview). Then start streaming the rest encrypted, and send the decryption key when the user pays. It doesn't have to be DRM, it could just decrypt the file.
> Why not just bounce chunks of data around forever on the Internet?
Yeah, great idea, because SRAM buffers in network switches and routers are so much cheaper per GB than hard drives or memory sticks. If you want to do that, build your own damn Internet that you can clog up without bothering the people who are trying to use the current one. Networks are already the bottleneck for a lot of things.
It is true that high-speed networks can have a lot of data in-flight, though. Esp. over long-distance high-speed fiber-optic links. The speed of light is not _that_ high compared to the switching speed.
A more sensible idea would be a distributed data-replication network, where people offer storage in return for being able to store their own data off site. (encrypted of course.) I think I've heard of projects like that. I think I'm thinking of freenet, if that's what it's called, though. Where you put a file on the net, and it's sent to hubs that request it. So unpopular stuff doesn't get replicated. So I guess I haven't heard of anything quite like that for a distributed network. There is MogileFS, though, for when all the machines are trusted (I think), and form a single filesystem.
I haven't kept up with TCP developments recently, but a couple years ago I read up on TCP Vegas vs. Reno, and all that. Vegas would make the Internet better if everyone used it (IIRC, its congestion control tried to back off sooner when packets are late, to avoid getting packet drops. Reno only considers drops). But nobody will switch to it first because it gets out-competed for bandwidth by TCP Reno and variants (which everyone uses). I know there are tweaks to Reno (NewReno), but AFAIK everyone using Vegas would still be the ideal case.
TCP Vegas over IPv6 is no different from TCP Vegas over IPv4. It still doesn't take its fair share of bandwidth vs. TCP Reno (v4 or v6). Can anyone think of a way to link these switch-overs? I don't think many people would want to bias routers against dropping v6 TCP packets on the assumption they were TCP Vegas.
But v6 and Vegas seem like two big switchovers that would both be useful. There's got to be a way to get people to make both switches, if they're going to use IPv6.
I can't find the article I saw, but the plan is to design a new driver interface along with USB 3.0. It seems they realize how much it currently sucks. Less CPU overhead = less power, too.
Is there any technical reason why they couldn't make it more future-proof, so devices made now will be compatible with future cards made 10 or 20 years from now? e.g. 2^64 bytes sounds good to me... Although a 2^64 byte FAT32 filesystem sounds nasty.
ext2/3 is relatively simple. There are solid GPL implementations, and presumably there are non-GPL implementations that could be licensed for non-GPL projects. Wouldn't ext3 make a good flash format? Or maybe ext2 so the re's no journal to wear out. Or there are probably filesystems designed for flash devices. Why the hell are we still using FAT? A windows filesystem driver for a new FS could be on driver disks that come with new flash devices, and OSes that don't suck would have even less trouble.
IDE hard drives are forward and backward compatible over a good 20 year interval, right? I know it will make sense for most people to upgrade to larger cards and newer cameras and media players, but switching to a new format will make it annoying.
BTW, I have to agree with the guy who suggested a standard form factor for SATA flash devices. Although low-power devices like cameras might have trouble implementing the high-speed signals (1.5GHz?) required.
> In general the ECC on DVD is going to prevent you from getting bad data; it's extremely unlikely that you're going to be able to successfully read an ECC block with (say) some bits flipped.
I burn my movie collection on DVD with par2 blocks and md5sum files. When I verify them, with some disks in some drives I get data errors. So I have seen in practice that you sometimes get silently corrupted data. My NEC-3500A burner is starting to get old, and doesn't read as well as it used to, I guess.
Par2 is slow to generate, but worth it. I have actually recovered files from slightly bad disks thanks to my par2 files.
For a disc with lots of small files, par2 would suck because it doesn't know about directories, for one thing. dvdisaster is like par2 for iso images. I don't think it's set up so that you can keep the error correction files on the same disc as the data, though.
> What would be nice would be if someone could resurrect Prograf with it's warts polished off.
Prograf sounds similar to LabVIEW (http://www.ni.com/labview/demos.htm), which I used when I was doing my physics degree. http://www.icon-tech.com.au/faq_introduction.html. According to that FAQ, there is now an open-source openG project which implements LabVIEW's underlying G programming language (for which LabVIEW itself is an IDE). G can't be represented textually, so it suffers the same problem as Prograf.
And from experience, making a proper program with error handling, instead of just blindly talking to the physics lab hardware (serial port, GPIB, etc.) adds complexity to the program that makes it harder to deal with any part of the program. Unlike in C, where the error handling code lives near the code that might generate the error, you have to have whole chunks of your program inside case/switch "boxes", with extra "wires" running all over the place.
However, you could write modules in LabVIEW, and wire them together without seeing their internal complexity, just their inputs and outputs.
I never really liked LabVIEW as something I wanted to use myself. It is interesting in that it's the only graphical language I know of (well, now I've heard of Prograf). Other people in my class liked it: one guy who really liked it also had some CS background (so he knew what programming in an imperative language like C is like, giving him some basis for comparison). He was also left-handed, which is correlated with being a visual thinker (very much unlike myself). I found LabVIEW to be a real pain sometimes, with the limitations of the built-in library stuff, but that was more than 6 years ago now, so maybe the quality of the thing has improved and it can be a good language for visually oriented people.
As you say, when you can replay journals when you mount the snapshot device, but e.g. for ext3, data=ordered (the default) doesn't guarantee which version of the file's data you'll have after a journal replay, just that the metadata will be consistent.
So it's a Good Thing to have your filesystem in a consistent state when you make a snapshot. You avoid all the bad ju-ju of dirty filesystems...
I wouldn't think you need to spend 10k$. A new machine with two SATA disks in software RAID1 might well handle the same I/O throughput as your old machine, if you have lots of RAM to cache I/O. Maybe a couple RAID1 sets, with four or six disks total. If you're only using one CPU now, you'll probably be fine with a single new CPU. The trick is to find a solid, reliable single CPU board. Tyan makes some good stuff... I like their dual Opteron boards, and I'd guess that their single Opteron boards are of similar quality. I don't know if it's possible to find an Athlon64 board reliable enough for use as a critical server.
If your O/S can do software RAID1, you should be all set. If you need the reliability, but the O/S just can't do it for you, then hardware is the way to go. A 3ware card, even an older one, will be fine, or even a mobo-builtin SATA controller with fake-hardware (i.e. BIOS-driven software RAID). RAID1 is _easy_. RAID5 requires lots of buffering to avoid having to do reads to calculate parity, but RAID1 is easy. RAID5 is good for big arrays where write performance is less important than space.
Depending on how important hotswaping disks is for maintaining uptime with RAID1, you should check on the drivers (and RAID controller card) to see what you have to do if a disk dies. (At least to install a new hot spare.)
> 2. You ensure randomness in the entropy pool, and thereby in the state of the > random generator. The generator itself however is still pseudo random.
I think a pseudo-random generator continuously re-seeded with true randomness will produce truly random output, not pseudo-random output. Running true randomness through a good mixing function shouldn't destroy it, and neither should taking hashes of parts of the entropy pool.
Cryptographic strength is all about predictability, but for simulations, true random numbers matter because you don't want to skew things with any possible patterns.
> 3. Sorry if I sound annoyed here, but what was the point of your post other then > trying to push a specific system?
You said the data you get from/dev/random is pseudo-random. The point of my post was that it's truly random because it comes from truly random events, like the precise timing of a keypress. I used Linux as an example because I know how it works, not purely to push it. I guess I can see how you might have gotten that impression, though, so no hard feelings.
>/dev/urandom is not random at all, it is pseudo-random at best.
On Linux, that's wrong./dev/urandom returns very high quality pseudo-random at _worst_./dev/random never resorts to mere pseudo randomness, and read(2)s on it block until the kernel has accumulated enough entropy in its pool. (yes, Linux maintains an entropy pool which it seeds from random events so there is some true randomness waiting for programs like gnupg or statistical simulations that need it.)
You're correct about everything else, though. The only thing you didn't know is that/dev/random doesn't come from a purely algorithmic source. Kernels have access to more than just a Turing machine:).
> This is why it is so important to have a good entropy source, it makes it > virtually impossible to guess at the state of the generator.
Now you're talking. That's why Linux uses the low bits of the CPU's clock cycle counter sampled during interrupts (which are generated by disks, the network, keyboards, and mice, etc. i.e. fairly unpredictable things, esp. wrt. exact numbers of CPU cycles!) It mixes these samples into its pool with cryptographically strong algorithms (insert hand-waving here...:), so even if the samples aren't very random, they don't make it worse.
If you're totally paranoid, RML's netdev-random patch will let you choose whether you want to add entropy from network interrupts to the entropy pool. Of course, you could also use rngd from rng-tools to feed entropy from your chipset's built-in rng (which measure thermal noise, and so has randomness that fairly directly from quantum mechanical processes, the only known source of true unpredictability in the Universe.)
Slashdot Mirror
I wasn't sure at first if they were setting the data by doping the material, but on closer reading ..."
"The engineers manipulated the nanomaterial so the electrons' spin within the material could be controlled,
makes it sound electrically re-writeable. Which is probably the only thing anyone's really interested in,
unless it was super-cheap. (i.e. cheap enough to replace pressed optical discs with ROM USB-storage.)
As bobjr94 hopes, it would be nice if it is that cheap, though, and optical discs are replaced by a standard flash storage standard.
FYI, GNU find has xargs built in these days:
find -name '*.php*' -exec grep func {} +
the + instead of ';' makes it collect up multiple arguments to grep
like xargs instead of the traditional find -exec behaviour which is like xargs -n1. I use -exec {} + all the time, because it's less typing, and safe with
filenames with punctuation or whitespace, so you don't have to type -print0 | xargs -0 either. (BTW, if you have a list of filenames that you processes with something line oriented, you can use xargs -d'\n')
> No loads in real life are linear
except electric heaters, stoves, and incandescent lights. They're all just resistors that get hot. Power factor = 1.0.
> then 50% of the power you're using isn't being measured by the power company's basic meters.
The "extra" power (Apparent power (Volts * Amps) - real power (actual Watts accounting for phase) is only wasted by the inefficiency of your transmission lines.
Other people have already explained this in detail in this thread.
Other than that, good try at explaining this for people who don't already know.
> Mount users' home directories noexec, don't give users root access.
noexec doesn't stop you from running /lib/ld.so on an ELF binary, or /bin/bash on a shell script. Or whatever interpreter you want, if it's installed.
Most people who know how to do that also know enough to avoid breaking things. But they might not have the self-discipline to stop playing games. Other than that, yeah, use firewalls and network policy.
I was as confused as you were by all this, since the article didn't say what the actual attack is. I eventually found something that explains it.
http://www.doxpara.com/DMK_BO2K8.ppt linked from http://www.isp-planet.com/equipment/2008/nominum+vantio.html
See slide 17 in the presentation. But the trick is, your forged reply to a query for 83.foo.com is:
83.foo.com IN NS www.foo.com (83.foo.com is a subdomain, whose name server is www.foo.com)
www.foo.com IN A 6.6.6.6 (glue)
So I guess I still agree with you, that BIND must be trusting more than it needs to. Caches could distrust any glue except when it has to. (I think the glue is only necessary when the name server is part of the domain it's serving. e.g. The glue would be needed if the name server was ns1.83.foo.com. Otherwise why not ask the .foo.com server for www.foo.com's A record, or use a cached one, instead of trusting the glue?)
IIRC, djbdns is skeptical of glue. I remember reading a big rant about glue on DJB's web site years ago. I'm not sure if that's why it's not vulnerable, or if it's because it already did source-port randomization.
Anyway, that presentation seems to cover a lot of what I wanted to know. In the worst case, you have a cache that trusts glue, and you can poison it by guessing a 16bit ID. In the even worse case, multiple requests for the same name leave the cache willing to accept more than 1 ID for a single response, leading to a birthday attack.
The trick is to generate lots of DNS queries for names you choose when the server isn't run by idiots (accepting recursive queries from the whole Internet). Web log analyzers are one possible vector. Otherwise if you can feed HTML to something that will resolve names for IMG tags, or presumably javascript could go nuts...
So, the dirty fix is to always request a random bogus sub-domain before making the real request?
No, cache misses for A records don't make a recursive resolver go back to the parent domain for an updated NS record. If a cache was poisoned so it thought .bank.com queries were handled by w.x.y.z (the attackers IP), a request for nonexistant.bank.com would cause it to send an A request for the name to w.x.y.z, but not go back to the .com servers to find out which server is authoritative for .bank.com. (It will do that once the cached NS record for .bank.com expires, which could be weeks. Or until another black hat re-poisons that cache.).
ArsenneLupin, this topic must be right up your alley, since you've stolen your name from a master thief. :)
I was going to say, don't browsers have copies of the root certificates locally, and require a chain of signatures from them to anything they're going to accept without complaint. But I didn't realize that one could potentially get another cert for a domain without anyone checking with the people who have the first cert.
Now I understand how the pieces could fit together to play man-in-the-middle with a bank. Otherwise I couldn't see how you could get a valid SSL certificate for yourtarget.com. Which you _need_ if people are going to access your fake site with SSL, and you're not just proxying the traffic to the real yourtarget.com without decrypting it.
Even with the low-validation certs you mentioned, where you just need to be able to receive mail at the domain, and have a phone, I would have hoped they wouldn't issue certificates for domains that they (or another cert authority) have already issued or signed a previous cert for.
BTW, the article makes this sound way easier than this, esp. since it's talking about the cert vendors selling encryption, when they actually sell trust. The encryption is free (and easy). Trust is hard, and can be worth paying for. The article was a real mixed bag: painfully bad technical sections, but I loved reading about Vixie's response, calling people and telling them to fly to the west coast without telling them why. That's serious paranoia about even traffic analysis of email (assuming you could trust PGP).
I wasn't familiar with the attack, and this article isn't really helping much. I guess I'll just look it up elsewhere. I know its not for a technical audience, but I wish people wouldn't say things that are more or less wrong. Since when is a hostname = a web page? This is so wrong that it makes the article painful to read. (Which is unfortunate, because the personal story is somewhat interesting.) And the article has a few more-technical bits later, so why stoop to being so wrong at the start?
a couple examples from the main article:
... He used a software program called Scapy to fire random queries at the system. He liked to see how it would respond and decided to ask for the location of a series of nonexistent Web pages at a Fortune 500 company. Then he tried to trick his DNS server in San Diego into thinking that he knew the location of the bogus pages.
If I didn't understand DNS and HTTP, I might be thinking this had something to do with HTTP 404 errors. Most people have seen the difference between a bad page on a good server and a server that doesn't exist at all.
Suddenly it worked. The server accepted one of the fake pages as real. But so what? He could now supply fake information for a page nobody would ever visit. Then he realized that the server was willing to accept more information from him. Since he had supplied data about one of the company's Web pages, it believed that he was an authoritative source for general information about the company's domain. The server didn't know that the Web page didn't existâ"it was listening to Kaminsky now, as if it had been hypnotized.
Hypnotized? WTF? This sounds like hollywood-hacking to me. Just a case of misplaced trust. Otherwise this paragraph isn't so bad. (except for saying pages instead of names. He already made a directory assistance analogy, why not continue with DNS = phonebook metaphors. e.g. computers need a number to call another computer, but people like to use names... Or don't people understand that web servers are just computers like their own?)
yeah, I don't think I'm remembering the 500fps correctly. I get 550fps with mesa 7.2 on a C2D E6600 (dual core 2.4GHz), Ubuntu pre-Intrepid AMD64. Tested in a Xephyr X server. I get 1170fps on my g965, which is in the same ballpark as software.
> I imagine a card could be built such that it would never run more than a few hundred FPS, but would render massive scenes at a comfortable 60 (vsync'd).
glxgears speeds are all about driver overhead, locking/unlocking and stuff like that. So yeah, not at all implausible, esp. with immature drivers that weren't very efficient and were cpu-bound at high FPS.
Why would you use loopback when Linux can use swap files directly. They don't have to be block devices.
For dynamics swap creation, check out swapspace(8), or swapd(8). They have to fill a file with zeros right when the system is under memory pressure and swapping, though. I use swapspace(8), and I like it. A runaway process will make the system thrash even harder, but if something is growing slowly it's great.
What would help them would be an API like XFS's reserve space ioctl (xfs_io resvspace ...), but that worked for making swap files. XFS reserved space is still marked a unwritten, so it reads as zero, not as the data that was on the disk before. (old xfs without unwritten extent support worked for this, but it's a nasty security hole to expose stale disk data to anyone. A new API could allow it only for root, or for someone who could read the blockdev the FS is on anyway.)
I've found that the default swappiness = 60 was bad if you're running a bittorrent client on your desktop. When I came back to the computer, programs like firefox would always be swapped out and take > 10 seconds to get going. It was a couple years ago that I started setting swappiness = 30 or 10, so I don't know if Linux has changed any. Anyway, p2p filesharing makes Linux think it's a good idea to cache files for what should be low priority I/O, at the expense of your desktop.
Hmm, I wonder if ionice affects Linux's desire to push other things out of memory to cache files...
glxgears is such a simple scene (no textures, for one thing) that even software rendering is not slow. Way back in the day on a P200MMX, maybe HW 3D was needed for a fast glxgears...
These days a core2 can run glxgears _really_ fast. e.g. 3GHz Harpertown gets > 500fps, IIRC.
As others have said, streaming un-paid-for unencrypted video is dumb.
You could send the first couple minutes unencrypted since anyone can watch it free (preview). Then start streaming the rest encrypted, and send the decryption key when the user pays. It doesn't have to be DRM, it could just decrypt the file.
> Why not just bounce chunks of data around forever on the Internet?
Yeah, great idea, because SRAM buffers in network switches and routers are so much cheaper per GB than hard drives or memory sticks. If you want to do that, build your own damn Internet that you can clog up without bothering the people who are trying to use the current one. Networks are already the bottleneck for a lot of things.
It is true that high-speed networks can have a lot of data in-flight, though. Esp. over long-distance high-speed fiber-optic links. The speed of light is not _that_ high compared to the switching speed.
A more sensible idea would be a distributed data-replication network, where people offer storage in return for being able to store their own data off site. (encrypted of course.) I think I've heard of projects like that. I think I'm thinking of freenet, if that's what it's called, though. Where you put a file on the net, and it's sent to hubs that request it. So unpopular stuff doesn't get replicated. So I guess I haven't heard of anything quite like that for a distributed network. There is MogileFS, though, for when all the machines are trusted (I think), and form a single filesystem.
I haven't kept up with TCP developments recently, but a couple years ago I read up on TCP Vegas vs. Reno, and all that. Vegas would make the Internet better if everyone used it (IIRC, its congestion control tried to back off sooner when packets are late, to avoid getting packet drops. Reno only considers drops). But nobody will switch to it first because it gets out-competed for bandwidth by TCP Reno and variants (which everyone uses). I know there are tweaks to Reno (NewReno), but AFAIK everyone using Vegas would still be the ideal case.
TCP Vegas over IPv6 is no different from TCP Vegas over IPv4. It still doesn't take its fair share of bandwidth vs. TCP Reno (v4 or v6). Can anyone think of a way to link these switch-overs? I don't think many people would want to bias routers against dropping v6 TCP packets on the assumption they were TCP Vegas.
But v6 and Vegas seem like two big switchovers that would both be useful. There's got to be a way to get people to make both switches, if they're going to use IPv6.
I can't find the article I saw, but the plan is to design a new driver interface along with USB 3.0. It seems they realize how much it currently sucks. Less CPU overhead = less power, too.
Is there any technical reason why they couldn't make it more future-proof, so devices made now will be compatible with future cards made 10 or 20 years from now? e.g. 2^64 bytes sounds good to me... Although a 2^64 byte FAT32 filesystem sounds nasty.
ext2/3 is relatively simple. There are solid GPL implementations, and presumably there are non-GPL implementations that could be licensed for non-GPL projects. Wouldn't ext3 make a good flash format? Or maybe ext2 so the re's no journal to wear out. Or there are probably filesystems designed for flash devices. Why the hell are we still using FAT? A windows filesystem driver for a new FS could be on driver disks that come with new flash devices, and OSes that don't suck would have even less trouble.
IDE hard drives are forward and backward compatible over a good 20 year interval, right? I know it will make sense for most people to upgrade to larger cards and newer cameras and media players, but switching to a new format will make it annoying.
BTW, I have to agree with the guy who suggested a standard form factor for SATA flash devices. Although low-power devices like cameras might have trouble implementing the high-speed signals (1.5GHz?) required.
> In general the ECC on DVD is going to prevent you from getting bad data; it's extremely unlikely that you're going to be able to successfully read an ECC block with (say) some bits flipped.
I burn my movie collection on DVD with par2 blocks and md5sum files. When I verify them, with some disks in some drives I get data errors. So I have seen in practice that you sometimes get silently corrupted data. My NEC-3500A burner is starting to get old, and doesn't read as well as it used to, I guess.
Par2 is slow to generate, but worth it. I have actually recovered files from slightly bad disks thanks to my par2 files.
For a disc with lots of small files, par2 would suck because it doesn't know about directories, for one thing. dvdisaster is like par2 for iso images. I don't think it's set up so that you can keep the error correction files on the same disc as the data, though.
> What would be nice would be if someone could resurrect Prograf with it's warts polished off.
. According to that FAQ, there is now an open-source openG project which implements LabVIEW's underlying G programming language (for which LabVIEW itself is an IDE). G can't be represented textually, so it suffers the same problem as Prograf.
Prograf sounds similar to LabVIEW (http://www.ni.com/labview/demos.htm), which I used when I was doing my physics degree. http://www.icon-tech.com.au/faq_introduction.html
And from experience, making a proper program with error handling, instead of just blindly talking to the physics lab hardware (serial port, GPIB, etc.) adds complexity to the program that makes it harder to deal with any part of the program. Unlike in C, where the error handling code lives near the code that might generate the error, you have to have whole chunks of your program inside case/switch "boxes", with extra "wires" running all over the place.
However, you could write modules in LabVIEW, and wire them together without seeing their internal complexity, just their inputs and outputs.
I never really liked LabVIEW as something I wanted to use myself. It is interesting in that it's the only graphical language I know of (well, now I've heard of Prograf). Other people in my class liked it: one guy who really liked it also had some CS background (so he knew what programming in an imperative language like C is like, giving him some basis for comparison). He was also left-handed, which is correlated with being a visual thinker (very much unlike myself). I found LabVIEW to be a real pain sometimes, with the limitations of the built-in library stuff, but that was more than 6 years ago now, so maybe the quality of the thing has improved and it can be a good language for visually oriented people.
As you say, when you can replay journals when you mount the snapshot device, but e.g. for ext3, data=ordered (the default) doesn't guarantee which version of the file's data you'll have after a journal replay, just that the metadata will be consistent.
So it's a Good Thing to have your filesystem in a consistent state when you make a snapshot. You avoid all the bad ju-ju of dirty filesystems...
Neutrons are magnetic (i.e. they have a magnetic moment), and in a neutron star they're all lined up.
Look at some of these search results
> Why dont you just set your stuff to be accessible publicly,
> but restricted to those with the proper password?
He just said he was using NFS. It's convenient and fast, but has no security. Well, per-IP access control...
You'd need ipsec to have a network where you'd feel comfortable doing a lot of otherwise-insecure stuff.
I wouldn't think you need to spend 10k$. A new machine with two SATA disks in software RAID1 might well handle the same I/O throughput as your old machine, if you have lots of RAM to cache I/O. Maybe a couple RAID1 sets, with four or six disks total. If you're only using one CPU now, you'll probably be fine with a single new CPU. The trick is to find a solid, reliable single CPU board. Tyan makes some good stuff... I like their dual Opteron boards, and I'd guess that their single Opteron boards are of similar quality. I don't know if it's possible to find an Athlon64 board reliable enough for use as a critical server.
If your O/S can do software RAID1, you should be all set. If you need the reliability, but the O/S just can't do it for you, then hardware is the way to go. A 3ware card, even an older one, will be fine, or even a mobo-builtin SATA controller with fake-hardware (i.e. BIOS-driven software RAID). RAID1 is _easy_. RAID5 requires lots of buffering to avoid having to do reads to calculate parity, but RAID1 is easy. RAID5 is good for big arrays where write performance is less important than space.
Depending on how important hotswaping disks is for maintaining uptime with RAID1, you should check on the drivers (and RAID controller card) to see what you have to do if a disk dies. (At least to install a new hot spare.)
> 2. You ensure randomness in the entropy pool, and thereby in the state of the
/dev/random is pseudo-random. The point of my post was that it's truly random because it comes from truly random events, like the precise timing of a keypress. I used Linux as an example because I know how it works, not purely to push it. I guess I can see how you might have gotten that impression, though, so no hard feelings.
> random generator. The generator itself however is still pseudo random.
I think a pseudo-random generator continuously re-seeded with true randomness will produce truly random output, not pseudo-random output. Running true randomness through a good mixing function shouldn't destroy it, and neither should taking hashes of parts of the entropy pool.
Cryptographic strength is all about predictability, but for simulations, true random numbers matter because you don't want to skew things with any possible patterns.
> 3. Sorry if I sound annoyed here, but what was the point of your post other then
> trying to push a specific system?
You said the data you get from
> /dev/urandom is not random at all, it is pseudo-random at best.
/dev/urandom returns very high quality pseudo-random at _worst_. /dev/random never resorts to mere pseudo randomness, and read(2)s on it block until the kernel has accumulated enough entropy in its pool. (yes, Linux maintains an entropy pool which it seeds from random events so there is some true randomness waiting for programs like gnupg or statistical simulations that need it.)
/dev/random doesn't come from a purely algorithmic source. Kernels have access to more than just a Turing machine :).
:), so even if the samples aren't very random, they don't make it worse.
On Linux, that's wrong.
You're correct about everything else, though. The only thing you didn't know is that
> This is why it is so important to have a good entropy source, it makes it
> virtually impossible to guess at the state of the generator.
Now you're talking. That's why Linux uses the low bits of the CPU's clock cycle counter sampled during interrupts (which are generated by disks, the network, keyboards, and mice, etc. i.e. fairly unpredictable things, esp. wrt. exact numbers of CPU cycles!) It mixes these samples into its pool with cryptographically strong algorithms (insert hand-waving here...
If you're totally paranoid, RML's netdev-random patch will let you choose whether you want to add entropy from network interrupts to the entropy pool. Of course, you could also use rngd from rng-tools to feed entropy from your chipset's built-in rng (which measure thermal noise, and so has randomness that fairly directly from quantum mechanical processes, the only known source of true unpredictability in the Universe.)