That won't protect you from controller defects, which seem to be quite a significant source of problems going by where people are finding checksum errors with ZFS.
Reed-Solomon is designed only for randomly-distributed errors. For errors that are in a large, contiguous block (such as a sector) you need Turbo Codes
Uh? Par2 doesn't give a damn where your errors are, if you've got 20MB of.par2 files, you can recover 20MB of the data, wherever it is (assuming you've got the rest).
nice features (such a firewall built directly into the NIC)
Um, wasn't that so buggy they never actually hooked it up? Which isn't really a problem because it's about the most useless feature ever, is packet filtering on your Windows box really that big a CPU hog?
And their NICs are a fucking joke; no documentation, and awful binary blob drivers which barely worked and required Linux and OpenBSD to reverse engineer the damn thing to make working open source ones (which can still be wobbly). I'll never forgive Sun for replacing the Intel 1000/Pro NICs in their Galaxy line of servers with nForce junk (Intel write and support very high quality BSD licensed drivers).
And then there's their SATA stuff, with its undocumented NCQ support which again, required reverse engineering to get working. Way to waste the time of a limited pool of developers because you can't be bothered or are too anal to make public documentation about the most trivial aspects of a chipset. Anyone would think they don't *want* people to support them.
And let's not mention their recent spate of overheating problems, and DMA bugs. I used to like nForce stuff, but now I barely even trust them in Windows, and I don't appreciate nVidia treating their chipsets like top secret weapons when things like their NICs are the primary networking option on £1000+ servers.
Which isn't to say I want them to exit the business, we certainly need the competition, I just want them to suck less.
They're already made that distinction; they all have a core set of packages which are vital to a working system, e.g. what you get when you debootstrap a Debian/Ubuntu install, which is enough for a usable shell, basic networking, and installing other apps.
Knowing how Virgin Media handles billing and service, 20 of those can look forward to not being charged, another 50 can look forward to being charged $300k, and 80% of them will spend 3 hours on the phone either on hold, or with John, an Indian who speaks about 12 words of English (none of which include "supervisor").
Also, about 10% of them will be considered too fat to go all the way into suborbit, and will instead find their $200k going towards a short Cessna flight.
It's quite noticable on Page 2; see the cliffs in the last shot, Vista has shadows where XP has none. Not terribly exciting though, especially given the additional FPS impact; woo a few shadows;)
Some things you probably have to see moving, though. e.g. Bioshock uses more dynamic water with DX10 (which as betterer vertex shaders or so?), and responds more to objects moving in it.
Do you have a test case showing what you're doing then? Because document.addEventListener("click", function(event) { event.preventDefault(); }, false); and document.onclick = function(event) { event.preventDefault(); } both work fine in 3.1.2 here.
I'm now looking at completely reinstalling a bunch of older BSD servers just to get this idiotic vulnerability resolved, because the maintainers aren't backporting the patch and upgrading BIND itself would be a royal pain
I recently upgraded a bunch of FreeBSD boxes I didn't want to rebuild world on:
You can configure the port to replace the base bind too, but this is easier to roll back in event of problems. Presumably the situations similar for the other BSD's.
I don't blame them for not wanting to support !Windows. I do blame them for writing broken ACPI tables and trusting Microsoft's legendarily forgiving implementation do their work for them. I do blame them for saying they're ACPI compliant when they're blatently not. I do blame them for not even expressing interest in fixing it when it's pointed out to them.
Sure, they're not necessarily evil, but they are displaying incompetence I find unacceptable in a hardware vendor, and I don't think it's in any way bad that they're getting bad press because of it.
However I'd also like to see all the user level config files that currently go into the various "~/.prog_name" folders collected into something like a "~/etc" directory.
This is exactly what the XDG Base Directory Specification specifies; by default user configs are expected to live in ~/.config/progname/
It boggles the mind that people still use it in the age of BitTorrent
I expect people use it because it's consistantly faster, doesn't require you to upload as much as you download to be nice to the swarm and doesn't broadcast your IP address for all to see.
To me, the biggest inefficiency that got me away from Usenet is the header downloads. If you have a long retention provider like Giganews, some of the groups can have multiple millions of headers, so just in order to see what is available on the big binary groups can take more than hour even on broadband.
Which is why we invented NZB's and run indexing sites.
The move to bzr was also a MySQL AB thing; if Sun had anything to do with it they'd probably have gone with Mercurial.
After being acquired by Sun, we learned that Sun will standardise on Mercurial. However, our decision on Bazaar was in the works already before MySQL was acquired and wont affect Suns policy.
The benefit? Unless your app uses more than around 3GB of RAM, basically zero
Plenty of things quite enjoy being able to perform operations in 64bits at a time, actually. Especially when it comes to media, crypto, compression, and indeed games; on top of having 2-3x the usable number of general purpose registers, which certainly isn't something to sneer at given how awful x86 has traditionally been in this area. Plenty of things you're likely to actually care about the performance of are likely to get a nice boost.
64-bits as a waste of address space, UNLESS you're accessing large amounts of memory (>3GB per program!)
Well, you generally only get 3GB when you've performed tricks to ask the OS to allow that; e.g./3GB boot flag, fiddling with MAXDSIZ, or recompiling with a different user/kernel space split.
On top of that, it's not all about RAM, it's about address space; if you've only got 32 bits to play with, you need to be very careful about allocating it, since any wastage can lead to exhausting your virtual address space before your physical space; like with filesystems, fragmentation becomes more of a concern the closer you get to your maximum capacity.
Large virtual spaces are also useful when it comes to doing things like mmapping large files; for instance, a database might like to mmap data files to avoid unnecessary copying you get with read()/write(), but mmapping a 1GB file means you need 1GB of address space, even if you don't touch any of it. When it's common to access disk using memory addresses, 3GB starts looking small very fast.
You also very quickly eat into it using modern graphics cards; 512MB is common, having two isn't that uncommon, and things are moving towards 1GB; bang goes your 3GB, all that frame buffer needs addressing too, on top of the kernel's other needs.
Really, 32bit needs to die screaming, sooner rather than later.
Is it actually a problem? These things are designed to cope with very high temperatures. My 8800GTS 512 idles at 68c, I can't say I'm too worried about it; by the time it dies, it's going to be getting sand kicked in its face by £30 passively cooled cards.
CoreAVC should do it if you pay for the pro one (allegedly; not noticed the trial version doing so, but perhaps it doesn't include it). You can also try MPC-HC which will try to use DXVA for H.264, though I'm yet to actually catch it doing so.
If it's any consolation, GPU accelerated playback on Windows doesn't work all that often, and open source codecs/players tend to be the better ones there speed and support wise, acceleration or no.
mirroring should speed up read performance relative to a single drive
No, not unless you're doing multiple concurrent IO. It's not RAID-0, it can't interlace IO's to get greater sequential transfer rate. In fact if it's done naively you get reduced STR by bouncing the IO's between the disks.
My 1000G Seagates do around 109MB/s, though they do drop around 60MB/s on the inner edge. See StorageReview; the ES.2 is basically the same as the 7200.11, and they have the SAS version topping out around 120MB/s.
Depends on what laptop you have. My Sony TX1XP is all Intel stuff, and works pretty much out of the box, though the useless modem needs a non-free driver. If you're helping them sort out their OS, one would hope you'd previously helped them not get crap hardware.
And yeah, those Canon AllInOne printers are a joke; I have a MP360 and it doesn't even work in OS X, and the Windows drivers are a bit iffy; I have one machine where the drivers mysteriously stopped working one day, and no amount of reinstalling would fix it, so had to move it to another machine. Awful, awful WinPrinter nonsense; my next one will probably speak Postscript, and won't be a Canon.
Actually you can disprove the existence of another hidden volume in the corner case that the visible volume is full.
Not without looking very closely at the data. You could conceivably map blocks from the hidden partition into files in the unhidden one; if all you're doing is looking at an encrypted directory full of porn mpg's, you're unlikely to notice a few MB of "random" data hidden away in the slack, even if you're rather tech savvy.
They might not waterboard you, but they can throw you in jail for a few years for failing to prove you don't have the key thanks to RIPA.
Your proposal basically seems to be as useful as doing dd if=/dev/random of=/secure bs=1M count=1024 in the default install; you can't prove it's not an encrypted file, and so if everyone has a chunk of random data, people for whom that random data really is encrypted can pretend it's not because it's standard behavior (and indeed, doesn't everyone have some random data lying around they used for testing and neglected to delete?). On the other hand, people who actually do want to use crypto will probably be using full disk encryption, and so instead of having 1% of their fs locked away in a random file, the entire thing is. Your proposal does nothing to help those users; to do what you seem to want, the default install should use FDE. That would certainly be a bold move.
I was mostly refering to the disgust I feel in threads like this where there are always the undertones, or outright praise of things like prisoner rape, and the sense that it's a valid part of someone's punishment.
Slashdot Mirror
That won't protect you from controller defects, which seem to be quite a significant source of problems going by where people are finding checksum errors with ZFS.
DMA is hard, let's go ride bikes!
Reed-Solomon is designed only for randomly-distributed errors. For errors that are in a large, contiguous block (such as a sector) you need Turbo Codes
Uh? Par2 doesn't give a damn where your errors are, if you've got 20MB of .par2 files, you can recover 20MB of the data, wherever it is (assuming you've got the rest).
nice features (such a firewall built directly into the NIC)
Um, wasn't that so buggy they never actually hooked it up? Which isn't really a problem because it's about the most useless feature ever, is packet filtering on your Windows box really that big a CPU hog?
And their NICs are a fucking joke; no documentation, and awful binary blob drivers which barely worked and required Linux and OpenBSD to reverse engineer the damn thing to make working open source ones (which can still be wobbly). I'll never forgive Sun for replacing the Intel 1000/Pro NICs in their Galaxy line of servers with nForce junk (Intel write and support very high quality BSD licensed drivers).
And then there's their SATA stuff, with its undocumented NCQ support which again, required reverse engineering to get working. Way to waste the time of a limited pool of developers because you can't be bothered or are too anal to make public documentation about the most trivial aspects of a chipset. Anyone would think they don't *want* people to support them.
And let's not mention their recent spate of overheating problems, and DMA bugs. I used to like nForce stuff, but now I barely even trust them in Windows, and I don't appreciate nVidia treating their chipsets like top secret weapons when things like their NICs are the primary networking option on £1000+ servers.
Which isn't to say I want them to exit the business, we certainly need the competition, I just want them to suck less.
They're already made that distinction; they all have a core set of packages which are vital to a working system, e.g. what you get when you debootstrap a Debian/Ubuntu install, which is enough for a usable shell, basic networking, and installing other apps.
Knowing how Virgin Media handles billing and service, 20 of those can look forward to not being charged, another 50 can look forward to being charged $300k, and 80% of them will spend 3 hours on the phone either on hold, or with John, an Indian who speaks about 12 words of English (none of which include "supervisor").
Also, about 10% of them will be considered too fat to go all the way into suborbit, and will instead find their $200k going towards a short Cessna flight.
It's quite noticable on Page 2; see the cliffs in the last shot, Vista has shadows where XP has none. Not terribly exciting though, especially given the additional FPS impact; woo a few shadows ;)
Some things you probably have to see moving, though. e.g. Bioshock uses more dynamic water with DX10 (which as betterer vertex shaders or so?), and responds more to objects moving in it.
Do you have a test case showing what you're doing then? Because document.addEventListener("click", function(event) { event.preventDefault(); }, false); and document.onclick = function(event) { event.preventDefault(); } both work fine in 3.1.2 here.
Er, that's named_flags="-c /etc/namedb/named.conf", of course.
I'm now looking at completely reinstalling a bunch of older BSD servers just to get this idiotic vulnerability resolved, because the maintainers aren't backporting the patch and upgrading BIND itself would be a royal pain
I recently upgraded a bunch of FreeBSD boxes I didn't want to rebuild world on:
You can configure the port to replace the base bind too, but this is easier to roll back in event of problems. Presumably the situations similar for the other BSD's.
I don't blame them for not wanting to support !Windows. I do blame them for writing broken ACPI tables and trusting Microsoft's legendarily forgiving implementation do their work for them. I do blame them for saying they're ACPI compliant when they're blatently not. I do blame them for not even expressing interest in fixing it when it's pointed out to them.
Sure, they're not necessarily evil, but they are displaying incompetence I find unacceptable in a hardware vendor, and I don't think it's in any way bad that they're getting bad press because of it.
However I'd also like to see all the user level config files that currently go into the various "~/.prog_name" folders collected into something like a "~/etc" directory.
This is exactly what the XDG Base Directory Specification specifies; by default user configs are expected to live in ~/.config/progname/
The memory controller is onchip of course, and it has a bandwidth of about 50-60GB/s I believe
Which is in fact, around the amount of memory bandwidth Niagara systems have, with 6 memory controllers per socket.
It boggles the mind that people still use it in the age of BitTorrent
I expect people use it because it's consistantly faster, doesn't require you to upload as much as you download to be nice to the swarm and doesn't broadcast your IP address for all to see.
To me, the biggest inefficiency that got me away from Usenet is the header downloads. If you have a long retention provider like Giganews, some of the groups can have multiple millions of headers, so just in order to see what is available on the big binary groups can take more than hour even on broadband.
Which is why we invented NZB's and run indexing sites.
The move to bzr was also a MySQL AB thing; if Sun had anything to do with it they'd probably have gone with Mercurial.
After being acquired by Sun, we learned that Sun will standardise on Mercurial. However, our decision on Bazaar was in the works already before MySQL was acquired and wont affect Suns policy.
The benefit? Unless your app uses more than around 3GB of RAM, basically zero
Plenty of things quite enjoy being able to perform operations in 64bits at a time, actually. Especially when it comes to media, crypto, compression, and indeed games; on top of having 2-3x the usable number of general purpose registers, which certainly isn't something to sneer at given how awful x86 has traditionally been in this area. Plenty of things you're likely to actually care about the performance of are likely to get a nice boost.
64-bits as a waste of address space, UNLESS you're accessing large amounts of memory (>3GB per program!)
Well, you generally only get 3GB when you've performed tricks to ask the OS to allow that; e.g. /3GB boot flag, fiddling with MAXDSIZ, or recompiling with a different user/kernel space split.
On top of that, it's not all about RAM, it's about address space; if you've only got 32 bits to play with, you need to be very careful about allocating it, since any wastage can lead to exhausting your virtual address space before your physical space; like with filesystems, fragmentation becomes more of a concern the closer you get to your maximum capacity.
Large virtual spaces are also useful when it comes to doing things like mmapping large files; for instance, a database might like to mmap data files to avoid unnecessary copying you get with read()/write(), but mmapping a 1GB file means you need 1GB of address space, even if you don't touch any of it. When it's common to access disk using memory addresses, 3GB starts looking small very fast.
You also very quickly eat into it using modern graphics cards; 512MB is common, having two isn't that uncommon, and things are moving towards 1GB; bang goes your 3GB, all that frame buffer needs addressing too, on top of the kernel's other needs.
Really, 32bit needs to die screaming, sooner rather than later.
Is it actually a problem? These things are designed to cope with very high temperatures. My 8800GTS 512 idles at 68c, I can't say I'm too worried about it; by the time it dies, it's going to be getting sand kicked in its face by £30 passively cooled cards.
My recent experience with Vista. It doesn't exactly go swimmingly :(
CoreAVC should do it if you pay for the pro one (allegedly; not noticed the trial version doing so, but perhaps it doesn't include it). You can also try MPC-HC which will try to use DXVA for H.264, though I'm yet to actually catch it doing so.
If it's any consolation, GPU accelerated playback on Windows doesn't work all that often, and open source codecs/players tend to be the better ones there speed and support wise, acceleration or no.
mirroring should speed up read performance relative to a single drive
No, not unless you're doing multiple concurrent IO. It's not RAID-0, it can't interlace IO's to get greater sequential transfer rate. In fact if it's done naively you get reduced STR by bouncing the IO's between the disks.
My 1000G Seagates do around 109MB/s, though they do drop around 60MB/s on the inner edge. See StorageReview; the ES.2 is basically the same as the 7200.11, and they have the SAS version topping out around 120MB/s.
Depends on what laptop you have. My Sony TX1XP is all Intel stuff, and works pretty much out of the box, though the useless modem needs a non-free driver. If you're helping them sort out their OS, one would hope you'd previously helped them not get crap hardware.
And yeah, those Canon AllInOne printers are a joke; I have a MP360 and it doesn't even work in OS X, and the Windows drivers are a bit iffy; I have one machine where the drivers mysteriously stopped working one day, and no amount of reinstalling would fix it, so had to move it to another machine. Awful, awful WinPrinter nonsense; my next one will probably speak Postscript, and won't be a Canon.
Actually you can disprove the existence of another hidden volume in the corner case that the visible volume is full.
Not without looking very closely at the data. You could conceivably map blocks from the hidden partition into files in the unhidden one; if all you're doing is looking at an encrypted directory full of porn mpg's, you're unlikely to notice a few MB of "random" data hidden away in the slack, even if you're rather tech savvy.
They might not waterboard you, but they can throw you in jail for a few years for failing to prove you don't have the key thanks to RIPA.
Your proposal basically seems to be as useful as doing dd if=/dev/random of=/secure bs=1M count=1024 in the default install; you can't prove it's not an encrypted file, and so if everyone has a chunk of random data, people for whom that random data really is encrypted can pretend it's not because it's standard behavior (and indeed, doesn't everyone have some random data lying around they used for testing and neglected to delete?). On the other hand, people who actually do want to use crypto will probably be using full disk encryption, and so instead of having 1% of their fs locked away in a random file, the entire thing is. Your proposal does nothing to help those users; to do what you seem to want, the default install should use FDE. That would certainly be a bold move.
I was mostly refering to the disgust I feel in threads like this where there are always the undertones, or outright praise of things like prisoner rape, and the sense that it's a valid part of someone's punishment.
Using the patches in the TrueCrypt 5 port, TrueCrypt 6 builds and appears to run fine on FreeBSD \o/