Nope. Whether the solution is software or hardware is absolutely irrevelant to the security of the cryptographic routines. Plus, the fact is that virtually all hardware products are proprietary and lack the peer-reviews that open standards or open source software enjoy. Just ask any decent cryptographer whether she would trust a black box (storage device with built-in encryption, proprietary "secure" protocol, etc), or peer-reviewed, open, standard solutions (TLS/SSL, IPsec, TrueCrypt, etc). BTW I look forward to the IEEE P1619 project coming up with a final standard.
Just look up the numerous stories about USB keys with built-in encryption that have been cracked for example.
A quintillion is only 2**60. Finding an SHA-256 collision requires 2**128 steps. So, no, it will never happen to you. To put things is perspective, the security/integrity of RSA keys (hence TLS/SSL, online banking, etc) depend on primality tests which only guarantee that the randomly generated RSA p and q parameters have a probability of about 1 in 2**80 or so of not being primes...
Or snapshot the filesystem after each rsync. This is what I do with ZFS snapshots, it works wonderfully well... Other than ZFS, snapshots are supported by LVM on Linux and UFS1 and UFS2 on FreeBSD.
The idea of combining rsync and ZFS snapshots has been first talked about on the zfs-discuss mailing list about 2 years ago.
I have been a ZFS user for a while and know a lot of its internals.
Let me comment on what you said.
checksums really only help in detecting errors.
Not in ZFS. When the checksum reveals silent data corruption, ZFS
attempts to self-heal itself by rewriting the sector with a known good
copy. Self-healing is possible if you are
using mirroring, raidz (single parity), raidz2 (dual parity), or even
a single disk (provided the copies=2 filesystem attribute is set).
The self-healing algorithm in the raidz and raidz2
cases is actually interesting as it is based on combinatorial
reconstruction: ZFS makes a series of guesses as to which
drive(s) returned bad data, it reconstructs the data block from the
other drives, and then validates whether this guess was correct or not
by verifying the checksum.
checksums have limits on how many errors they can detect.
All the ZFS checksumming algorithms (fletcher2, fletcher4, SHA-256)
generate 256-bit checksums. The default is fletcher2 and offers very
good error detection (even errors affecting more than 256 bits of data)
assuming unintentional data corruption (the
fletcher family are not a cryptographic hash algorithms, it is actually
possible to intentionally find collisions). SHA-256 is
collision-resistant therefore it will in practice detect all
data corruptions. It would be computationally infeasible to come
up with a corrupted data block that still matches the SHA-256 checksum.
A good intro to the ZFS capabilities are
these
slides
Even ECC memory isn't a panacea. ECC can only correct 1-bit errors. It can't correct 2-bit errors (only detect them) and can't even detect nor correct 3-bit (or more) errors.
To the poster that seemed to think a 1-bit error causing a downtime is a sign of a defective design: the truth is that 99.9% of the software out there doesn't even try to work around data corruption issues. One can easily introduce 1-bit errors capable of crashing virtually any app. For example by flipping 1 bit of the first byte of the MBR (master boot record) of an OS, it can make it unbootable (it changes the opcode of what is usually a JMP instruction to something else).
I read the rest of the summary (and TFA) and realized I totally overlooked the width of Larrabee's SIMD units: 512 bits, versus only 32 for the competition ! Ok *now* Larrabee looks promising:)
A GeForce 7800 GTX has 302 million transistors -- 100x the number of the original Pentium processor.
Yes. And newer GPUs have even more transistors than that. The AMD R770 GPU (HD 4800 series video cards) has 965 million of transistors. The Nvidia GT200 (GTX 200 series cards) has 1.4 billion of them.
Also, the R770 is based on a VLIW architecture with 160 stream processing units, 5 ALUs each, 800 ALUs total, potentially executing 800 instructions per clock (theoretical of course, only ideal code can reach this throughput). The R770 is clocked at up to 750 MHz (HD 4870). As to the GT200, it has 240 streaming processors and can theoretically execute up to 240 instructions per clock. It runs at up to 1296 MHz (GTX 280) or 1500 MHz (Tesla-based S1070 1U box). Of course AMD's and Nvidia's next generation GPUs (8 months from now?) will be even faster.
All this to say that it is way too early to know how Larrabee, planned for production in 2009, will rank among the competition. x86 compatibility will be nice for sure, and I assume Larrabee will have low instruction latencies and good caching performance, but as a GPGPU and i386/amd64 assembly developer, hearing about a "32-core P54C-based GPU" is actually below my expectations. I predict AMD/Nvidia GPUs will still perform better on highly parallelizable workloads with low instruction interdependencies. Intel seems is positionning Larrabee to be better at more general-purpose workloads that are inconvenient to port to today's GPU architectures.
As others explained these strict naming schemes are a stupid idea. First of all they indicate you have no documentation and rely on hostnames to document your network. They are painful to read/type. Hard to spell over the phone. Confusing when you add an ftp service to spdns000. Typos are easily made (ltftp01 is rebooted instead of lsftp01). Naming errors are bound to happen (what do you do when you notice an error a few weeks after a server has been set up but only discovers it now when the hostname is already in dozen of config files, do you waste time fixing something that, in the end, is completely irrelevant ?). The naming convention also totally breaks when you merge or collaborate closely with another company with not the same naming convention. Etc. I could go on and on.
Here is what works: a naming convention with no specific rules. Just use unique names, not too exceedingly hard to type or remember. Use CNAMEs to represent functionnality. Encode the location in subdomains. Example: {shrek,moon,highway}.{losangeles,newyork}.company.local, with 'webmail' pointing to the right servers in the 2 locations. If you are afraid to not remember what is the OS/purpose of highway.newyork.company.local, then look it up in your network documentation.
Just reply to her that (according to internal industry market research):
"S.U.V.s tend to be bought by people who are insecure, vain, self-centered, and self-absorbed, who are frequently nervous about their marriages, and who lack confidence in their driving skills.". She will argue back, tell her it's because she is nervous about the relationship. Then either she stops arguing -- you win, you get your small car. Or she leaves you -- you win too, you won't have to buy an SUV. Easy!
Where are they all going? Is there some kind of giant warehouse somewhere?
ebay ?
Re:RAID5 is stupid, RAID 10 or no RAID
on
What NAS To Buy?
·
· Score: 1
With Raid5.. two drives fail and your done.
Which is why some people do RAID 6 instead. Or you could keep doing RAID 5,
but periodically scrub your array to detect failing disks ASAP, like
ZFS scrubbing.
What, your RAID implementation doesn't implement scrubbing ? Maybe you
should blame it instead of blaming RAID 5, and consider switching
to ZFS:-)
Windows defaults to a 2/2 GB split. Linux/*BSD/Solaris default to 3/1 GB.
There is no "best" value. It's a matter of tradeoffs. But the split can
easily be changed with a boot option on Solaris and Windows. Linux (and
I think the BSDs) require a kernel recompilation.
On AMD64, Linux defaults to a 224/32 TB split IIRC (because current AMD and
Intel processors only support 256 TB of virtual memory, not the full 64-bit
address space).
In a standard i386 Linux/BSD/Solaris kernel, the kernel space is only 1GB; the first 3 GB are dedicated to userland. So everytime the kernel has to access high-mem, it first has to map it into this 1GB of low-memory. This remapping operation may be expensive as it involves TLB flushes.
I have seen the sequential disk read throughput of an old SATA box jump by +30-40% with a 64-bit kernel, because of the paging overhead of a 32-bit kernel required to access high-memory (ie. memory between 1GB and 4GB).
AMD also gave a lot of help to initially port the Linux kernel to AMD64 processors (they kind of coordinated the whole thing via www.x86-64.org), and they continue to be an important contributor to the Linux kernel (I see many patches related to chipset drivers, SATA, etc). The also contribute to OpenSolaris, OpenJDK, KVM (NPT support, Vista / XP 64-bit bugfixes, etc). AFAIK most of these open source contributions are made by AMD employees from the OSRC (Operating System Research Center) group.
Good software is written by good people. There is no general rules you can follow to automagically make your software good.
Sure some rules will tend to make your software a little bit better: KISS design principle, release early release often, unit tests, etc. But fundamentally it's all about people.
Then you might ask "what makes a good developer good". Well's that's not so easy to answer.
Slashdot Mirror
Nope. Whether the solution is software or hardware is absolutely irrevelant to the security of the cryptographic routines. Plus, the fact is that virtually all hardware products are proprietary and lack the peer-reviews that open standards or open source software enjoy. Just ask any decent cryptographer whether she would trust a black box (storage device with built-in encryption, proprietary "secure" protocol, etc), or peer-reviewed, open, standard solutions (TLS/SSL, IPsec, TrueCrypt, etc). BTW I look forward to the IEEE P1619 project coming up with a final standard.
Just look up the numerous stories about USB keys with built-in encryption that have been cracked for example.
As opposed to dead talking females.
A quintillion is only 2**60. Finding an SHA-256 collision requires 2**128 steps. So, no, it will never happen to you. To put things is perspective, the security/integrity of RSA keys (hence TLS/SSL, online banking, etc) depend on primality tests which only guarantee that the randomly generated RSA p and q parameters have a probability of about 1 in 2**80 or so of not being primes...
Or snapshot the filesystem after each rsync. This is what I do with ZFS snapshots, it works wonderfully well... Other than ZFS, snapshots are supported by LVM on Linux and UFS1 and UFS2 on FreeBSD. The idea of combining rsync and ZFS snapshots has been first talked about on the zfs-discuss mailing list about 2 years ago.
I have been a ZFS user for a while and know a lot of its internals. Let me comment on what you said.
Not in ZFS. When the checksum reveals silent data corruption, ZFS attempts to self-heal itself by rewriting the sector with a known good copy. Self-healing is possible if you are using mirroring, raidz (single parity), raidz2 (dual parity), or even a single disk (provided the copies=2 filesystem attribute is set). The self-healing algorithm in the raidz and raidz2 cases is actually interesting as it is based on combinatorial reconstruction: ZFS makes a series of guesses as to which drive(s) returned bad data, it reconstructs the data block from the other drives, and then validates whether this guess was correct or not by verifying the checksum.
All the ZFS checksumming algorithms (fletcher2, fletcher4, SHA-256) generate 256-bit checksums. The default is fletcher2 and offers very good error detection (even errors affecting more than 256 bits of data) assuming unintentional data corruption (the fletcher family are not a cryptographic hash algorithms, it is actually possible to intentionally find collisions). SHA-256 is collision-resistant therefore it will in practice detect all data corruptions. It would be computationally infeasible to come up with a corrupted data block that still matches the SHA-256 checksum.
A good intro to the ZFS capabilities are these slides
Evironment -> Environment
Even ECC memory isn't a panacea. ECC can only correct 1-bit errors. It can't correct 2-bit errors (only detect them) and can't even detect nor correct 3-bit (or more) errors. To the poster that seemed to think a 1-bit error causing a downtime is a sign of a defective design: the truth is that 99.9% of the software out there doesn't even try to work around data corruption issues. One can easily introduce 1-bit errors capable of crashing virtually any app. For example by flipping 1 bit of the first byte of the MBR (master boot record) of an OS, it can make it unbootable (it changes the opcode of what is usually a JMP instruction to something else).
I read the rest of the summary (and TFA) and realized I totally overlooked the width of Larrabee's SIMD units: 512 bits, versus only 32 for the competition ! Ok *now* Larrabee looks promising :)
Yes. And newer GPUs have even more transistors than that. The AMD R770 GPU (HD 4800 series video cards) has 965 million of transistors. The Nvidia GT200 (GTX 200 series cards) has 1.4 billion of them.
Also, the R770 is based on a VLIW architecture with 160 stream processing units, 5 ALUs each, 800 ALUs total, potentially executing 800 instructions per clock (theoretical of course, only ideal code can reach this throughput). The R770 is clocked at up to 750 MHz (HD 4870). As to the GT200, it has 240 streaming processors and can theoretically execute up to 240 instructions per clock. It runs at up to 1296 MHz (GTX 280) or 1500 MHz (Tesla-based S1070 1U box). Of course AMD's and Nvidia's next generation GPUs (8 months from now?) will be even faster.
All this to say that it is way too early to know how Larrabee, planned for production in 2009, will rank among the competition. x86 compatibility will be nice for sure, and I assume Larrabee will have low instruction latencies and good caching performance, but as a GPGPU and i386/amd64 assembly developer, hearing about a "32-core P54C-based GPU" is actually below my expectations. I predict AMD/Nvidia GPUs will still perform better on highly parallelizable workloads with low instruction interdependencies. Intel seems is positionning Larrabee to be better at more general-purpose workloads that are inconvenient to port to today's GPU architectures.
As others explained these strict naming schemes are a stupid idea. First of all they indicate you have no documentation and rely on hostnames to document your network. They are painful to read/type. Hard to spell over the phone. Confusing when you add an ftp service to spdns000. Typos are easily made (ltftp01 is rebooted instead of lsftp01). Naming errors are bound to happen (what do you do when you notice an error a few weeks after a server has been set up but only discovers it now when the hostname is already in dozen of config files, do you waste time fixing something that, in the end, is completely irrelevant ?). The naming convention also totally breaks when you merge or collaborate closely with another company with not the same naming convention. Etc. I could go on and on.
Here is what works: a naming convention with no specific rules. Just use unique names, not too exceedingly hard to type or remember. Use CNAMEs to represent functionnality. Encode the location in subdomains. Example: {shrek,moon,highway}.{losangeles,newyork}.company.local, with 'webmail' pointing to the right servers in the 2 locations. If you are afraid to not remember what is the OS/purpose of highway.newyork.company.local, then look it up in your network documentation.
IOW more than a simple handshake.
Just reply to her that (according to internal industry market research): "S.U.V.s tend to be bought by people who are insecure, vain, self-centered, and self-absorbed, who are frequently nervous about their marriages, and who lack confidence in their driving skills.". She will argue back, tell her it's because she is nervous about the relationship. Then either she stops arguing -- you win, you get your small car. Or she leaves you -- you win too, you won't have to buy an SUV. Easy!
The "proof" contained so many errors that a previously uncontacted amazon tribe could have debunked it.
ebay ?
Which is why some people do RAID 6 instead. Or you could keep doing RAID 5, but periodically scrub your array to detect failing disks ASAP, like ZFS scrubbing. What, your RAID implementation doesn't implement scrubbing ? Maybe you should blame it instead of blaming RAID 5, and consider switching to ZFS :-)
If only Emacs came with a decent text editor...
Windows defaults to a 2/2 GB split. Linux/*BSD/Solaris default to 3/1 GB. There is no "best" value. It's a matter of tradeoffs. But the split can easily be changed with a boot option on Solaris and Windows. Linux (and I think the BSDs) require a kernel recompilation.
On AMD64, Linux defaults to a 224/32 TB split IIRC (because current AMD and Intel processors only support 256 TB of virtual memory, not the full 64-bit address space).
In a standard i386 Linux/BSD/Solaris kernel, the kernel space is only 1GB; the first 3 GB are dedicated to userland. So everytime the kernel has to access high-mem, it first has to map it into this 1GB of low-memory. This remapping operation may be expensive as it involves TLB flushes.
Oh shit you beat me to it motherfucker. Fuck. I am really pissed. Your mom is a cunt with big tits.
Oh yeah I almost forgot: Cocksucker!
Shit, piss, fuck, cunt, cocksucker, motherfucker, tits.
I bet I am going to get modded flamebait.
May I suggest Myths and facts about 64-bit Linux for your reading pleasure ?
Oracle ? (Linux platform is the most popular one, followed by Windows, then other UNIX OSes)
Tivo ? (Linux-based DVRs).
Red Hat ? Novell ? Canonical ? (Obvious ones).
AMD also gave a lot of help to initially port the Linux kernel to AMD64 processors (they kind of coordinated the whole thing via www.x86-64.org), and they continue to be an important contributor to the Linux kernel (I see many patches related to chipset drivers, SATA, etc). The also contribute to OpenSolaris, OpenJDK, KVM (NPT support, Vista / XP 64-bit bugfixes, etc). AFAIK most of these open source contributions are made by AMD employees from the OSRC (Operating System Research Center) group.
Good software is written by good people. There is no general rules you can follow to automagically make your software good.
Sure some rules will tend to make your software a little bit better: KISS design principle, release early release often, unit tests, etc. But fundamentally it's all about people.
Then you might ask "what makes a good developer good". Well's that's not so easy to answer.
old women use supercomputers to dry laundry !