There is a big difference between getting a single process exploited (maybe just one of the httpd workers) and having a full system-breach.....
There really isn't on most cloud systems. You compromise the web server, and now you've got the credentials to access the db server. That's far more important than anything on the local filesystem. Sniffing all traffic going to the system? There isn't any traffic going to anything other than the (single) running app. And even with a compromised kernel, you can't put the interface in promiscuous mode because the paravirtualised device doesn't support it.
So the question is whether you'd rather have a slimmed-down FreeBSD kernel in your TCB or a full-featured Linux kernel and GNU userland. If you have an OS where you can spin up new instances in a second, that makes it possible to compartmentalise your system much more than if starting up a new VM takes a minute. It also makes scaling easier.
Nothing. This is the plan that was discussed at BSDCan this year. It's basically a more formal way for the people that were already collaborating to continue to collaborating, but in a way that encourages more people to join in.
That's laughably wrong. ZFS is distributed under the CDDL, which includes explicit patent grants. BTRFS is distributed under the GPLv2, which doesn't. If, tomorrow, Oracle stood up and said 'we have a patent that covers ZFS and BTRFS' then if it was one owned by Sun, or during a time when they were distributing ZFS under the CDDL, then users of ZFS would already have a license for it. Users of BTRFS, however, would have clause 7 of the GPL kick in and be unable to legally redistribute it.
You have a ZIL unless you explicitly disable it (in which case, expect data loss and only do this on pools you don't care about). ZIL is not the same as a separate log device.
There are two uses for SSDs in a ZFS pool. The first is L2ARC. The ARC (adaptive replacement cache) is a combination of LRU / LFU cache that keeps blocks in memory (and also does some prefetching). With L2ARC, you have a second layer of cache in an SSD. This speeds up reads a lot. Data that is either recently or frequently used will end up in the L2ARC and so these reads will be satisfied from the flash without touching the disk. The bigger the L2ARC, the better, although practically if it's close to your working set size you'll start to see diminishing returns if you make it bigger.
The second use is as a log device. The ZIL is the ZFS Intents Log, which is effectively a journal. Transaction groups are written there first so that the filesystem is always in a consistent state. It's usually on the same disk as the storage, which means that writes can involve a lot of seeks. With the ZIL in a different drive (SSD or otherwise), you reduce the number of writes required. Because you can generally write to a ZFS pool significantly faster than to a single disk, putting the ZIL on an SSD stops it becoming a bottleneck. The rule of thumb for the size of the log device is that it should be as big as the maximum amount of data that can be written to your pool in 10 seconds. If you can do 100MB/s writes, you want about 1GB of log device.
Once a zfs filesystem is created that's it. No resize support
Minor correction: Once a ZFS pool is created, that's it. Filesystems are dynamically sized. You can also add disks to a pool, but not to a RAID set. You can also replace disks in a RAID set with larger ones and have the pool grow to fill them. You can't, however, replace them with smaller ones.
It's been possible to write a ZFS IFS for Windows for a long time, but no one has done it, and as far as I know none of the people in this group are interested in working on Windows.
It's released under the CDDL, which explicitly grants patent rights. If they had licensed it under GPLv2, then they would have been able to sue people (clause 7 allows them to say 'oh, we've just noticed that we have patents on this. Everyone stop distributing it!') and if they'd released it under Apache2 or GPLv3 then it would still be GPLv2-incompatible, so still wouldn't have been useable in Linux.
Ideally, in something like ZFS you'd want background defragmentation. When you a file that hadn't been modified for a while into ARC, you'd make a note. When it's about to be flushed unmodified, if there is some spare write capacity you'd write the entire file out contiguously and then update the block pointers to use the new version.
That said, defragmentation is intrinsically incompatible with deduplication, as it is not possible to have multiple files that all refer to some of same blocks all being contiguous on disk. It's also not a problem if you've got a decent sized L2ARC, as the random reads on the disk are fairly rare.
That depends on the reason for the failure. If it's because there's a little bit of dust on the platter, or a manufacturing defect in the substrate, then it's very unlikely. If it's because of a bug in the controller or a poor design on the head manipulation arm, then it's very likely.
This is why the recommendation if you care about reliability more than performance is to use drives from different manufacturers in the array. It's also why it costs a lot more if you buy disks from NetApp than if you buy them directly: they're the same commodity drives, but NetApp tests batches, discards the least reliable ones, and ensures that you don't have two disks from the same production run in the same array. You're still getting the same drives you can buy elsewhere for a fraction of the price, but you're getting more diversity.
ZFS doesn't have ECC, but it does checksum each block, so it can detect per-block errors. If you have valuable data, you can set the copies property to some value greater than 1 for that data set and it will ensure that each block is duplicated on the disk so if one fails a checksum then the other will be used to recover. If you have three disks, you can use RAID-Z, which loses you 1/3 of the space (not 1/2) and allows any single-disk failures to be recovered. Running zfs scrub will make it validate all of the data and when any read fails the checksums recover the data from the other two.
The reason it doesn't use ECC is that ECC doesn't mesh well with the failure modes of disks. ECC is used in RAM because when it gets hot, hit by a solar ray, or whatever, it is common for a single bit to flip (in a single direction, which makes the error correction easier). In a disk, you typically have an entire block fail, not a single bit. Modern disks use multiple levels, so the smallest failure that is even theoretically possible might be a single byte (or nibble) in a block. And since the failure isn't biased, you'd need a fairly large amount of space. A better approach would be for the filesystem to generate something like Reed–Solomon code blocks for every n blocks that are written. This would allow single-block errors to be recovered, as long as the other blocks are okay. The down side of this approach is that the error correcting block would need to be rewritten whenever any of the other blocks is modified. this might be relatively easy to add to ZFS, as it uses a CoW structure, so block-overwrites are relatively rare (although erasing a lot of data would require a lot of checksums to be recalculated). This would mean that a single-block write would end up triggering a lot of reads and that would hurt performance. For ZFS, this might actually be easier to implement, as blocks are written out in transaction groups and so including an error correction block at the end might be a fairly simple modification.
I live in the UK, and I've never had anything other than polite and courteous interactions with the police. Of course, that might be because I've never been involved in smashing shop windows and stealing stuff...
They're not doing it to improve civility or stop anonymous abuse. These can both be solved by other, less intrusive mechanisms. Even Slashdot manages it: penalise anonymous users a lot, penalise new members a little bit, and require users to establish a reputation to gain full participation. If they lose that reputation, their ability to participate drops off. The real reason that they want real names is because it makes the information that they harvest and sell to advertisers more valuable if it's tied to a real name and address.
If production went down 100% (i.e. no more DRAM is produced), would you expect prices to only go up 100% (i.e. double)? I think that supply-demand curves don't look how you think they look...
The problem is that the NSA and GCHQ have dual mandates. They are responsible for both ensuring their respective countries are not vulnerable to attacks and for ensuring that they have techniques for attacking others. This means that when they discover a vulnerability in a piece of widely deployed software, they have conflicting requirements. If they publish it, then the systems that they're defending will be safer because it will be fixed, but if they don't publish it then the systems that they're attacking will remain vulnerable. This gets even worse when they start introducing intentional back doors (given how many Russian spies there were in these institutions during the Cold War, it's pretty much expected that there will be some Chinese spies in there now, so those back doors are almost certainly not secret).
Even without the incentive not to check for prior art in patents (triple damages for infringement if it can be proven that you knew you were infringing), have you ever read a modern patent? Trying to implement something from a patent is harder than inventing it from scratch. Compare this with patents a hundred years ago, where even with the linguistic drift it's usually possible to work out what they were describing and how it worked.
Nope, most of the long-term studies judge success based on degree and employment. Try again.
Re:Yes, exactly what we need. More distractions.
on
No Child Left Untableted
·
· Score: 3, Informative
Only two factors have consistently been shown to positively correlate with student performance: parental support and teacher enthusiasm. But, hey, throwing technology at the problem might work this time...
We only made the switch to remove gcc from the default install on amd64, i386 and ARMv6. ARM v6 is still compiled with gcc (clang probably should work okay on ARMv4 and ARMv5, but the people still using them tend to be conservative). It's not yet the default on MIPS, but since we're about to release an open source MIPS core at my day job that runs FreeBSD we're working on improving MIPS support. PC98 is i386. It currently does include gcc, because some oddity in its bootloader requires gcc (not sure what). XBox is also i386. PowerPC 32 is still a little way behind (no PIC support, some issues with TLS), but PowerPC64 is now working fine with clang so will make the switch fine. IA64 is basically dead and Oracle seems to be trying to kill SPARC64 as a platform for anything other than Oracle software, so we'll see if they're still around in a few years. There is a SPARC64 back end in LLVM, but it's not well maintained because no one cares.
You might want to look at the list of LLVM developers and see how many work at Sony some time. In particular, the LLVM Linker (lld) is lead by a Sony engineer. Now take a guess at which product group he works in...
Speaking as a member of the FreeBSD Core Team, who contributes code to a GNU project (GNUstep) and has signed an FSF copyright assignment for the purpose, and who was the one to make the disable-gcc-by-default commit, I have to say: What?
With my LLVM dev hat on, please can you point to some analyses that are implemented in GCC and not LLVM? I have some masters' students in need of interesting projects in a few months...
RDRAND is not used directly, it's 'whitened' by Yarrow or a similar algorithm (there are now a few pluggable options, although I'm not sure they made it into 10.0). It's one entropy source, and things like interrupt timings and so on are others. If RDRAND is produces non-deterministic data in a way that are easy for the NSA to predict then there are some possible network attacks involving TCP sequence numbers early on in the boot. After that, there are other entropy sources (e.g. interrupt timings) that make it much harder to predict the inputs to Yarrow (and, unless Yarrow is also broken, you need all of the inputs to be able to predict the output).
Slashdot Mirror
There is a big difference between getting a single process exploited (maybe just one of the httpd workers) and having a full system-breach.....
There really isn't on most cloud systems. You compromise the web server, and now you've got the credentials to access the db server. That's far more important than anything on the local filesystem. Sniffing all traffic going to the system? There isn't any traffic going to anything other than the (single) running app. And even with a compromised kernel, you can't put the interface in promiscuous mode because the paravirtualised device doesn't support it.
So the question is whether you'd rather have a slimmed-down FreeBSD kernel in your TCB or a full-featured Linux kernel and GNU userland. If you have an OS where you can spin up new instances in a second, that makes it possible to compartmentalise your system much more than if starting up a new VM takes a minute. It also makes scaling easier.
Nothing. This is the plan that was discussed at BSDCan this year. It's basically a more formal way for the people that were already collaborating to continue to collaborating, but in a way that encourages more people to join in.
That's laughably wrong. ZFS is distributed under the CDDL, which includes explicit patent grants. BTRFS is distributed under the GPLv2, which doesn't. If, tomorrow, Oracle stood up and said 'we have a patent that covers ZFS and BTRFS' then if it was one owned by Sun, or during a time when they were distributing ZFS under the CDDL, then users of ZFS would already have a license for it. Users of BTRFS, however, would have clause 7 of the GPL kick in and be unable to legally redistribute it.
You have a ZIL unless you explicitly disable it (in which case, expect data loss and only do this on pools you don't care about). ZIL is not the same as a separate log device.
There are two uses for SSDs in a ZFS pool. The first is L2ARC. The ARC (adaptive replacement cache) is a combination of LRU / LFU cache that keeps blocks in memory (and also does some prefetching). With L2ARC, you have a second layer of cache in an SSD. This speeds up reads a lot. Data that is either recently or frequently used will end up in the L2ARC and so these reads will be satisfied from the flash without touching the disk. The bigger the L2ARC, the better, although practically if it's close to your working set size you'll start to see diminishing returns if you make it bigger.
The second use is as a log device. The ZIL is the ZFS Intents Log, which is effectively a journal. Transaction groups are written there first so that the filesystem is always in a consistent state. It's usually on the same disk as the storage, which means that writes can involve a lot of seeks. With the ZIL in a different drive (SSD or otherwise), you reduce the number of writes required. Because you can generally write to a ZFS pool significantly faster than to a single disk, putting the ZIL on an SSD stops it becoming a bottleneck. The rule of thumb for the size of the log device is that it should be as big as the maximum amount of data that can be written to your pool in 10 seconds. If you can do 100MB/s writes, you want about 1GB of log device.
Once a zfs filesystem is created that's it. No resize support
Minor correction: Once a ZFS pool is created, that's it. Filesystems are dynamically sized. You can also add disks to a pool, but not to a RAID set. You can also replace disks in a RAID set with larger ones and have the pool grow to fill them. You can't, however, replace them with smaller ones.
It's been possible to write a ZFS IFS for Windows for a long time, but no one has done it, and as far as I know none of the people in this group are interested in working on Windows.
It's released under the CDDL, which explicitly grants patent rights. If they had licensed it under GPLv2, then they would have been able to sue people (clause 7 allows them to say 'oh, we've just noticed that we have patents on this. Everyone stop distributing it!') and if they'd released it under Apache2 or GPLv3 then it would still be GPLv2-incompatible, so still wouldn't have been useable in Linux.
Ideally, in something like ZFS you'd want background defragmentation. When you a file that hadn't been modified for a while into ARC, you'd make a note. When it's about to be flushed unmodified, if there is some spare write capacity you'd write the entire file out contiguously and then update the block pointers to use the new version.
That said, defragmentation is intrinsically incompatible with deduplication, as it is not possible to have multiple files that all refer to some of same blocks all being contiguous on disk. It's also not a problem if you've got a decent sized L2ARC, as the random reads on the disk are fairly rare.
That depends on the reason for the failure. If it's because there's a little bit of dust on the platter, or a manufacturing defect in the substrate, then it's very unlikely. If it's because of a bug in the controller or a poor design on the head manipulation arm, then it's very likely.
This is why the recommendation if you care about reliability more than performance is to use drives from different manufacturers in the array. It's also why it costs a lot more if you buy disks from NetApp than if you buy them directly: they're the same commodity drives, but NetApp tests batches, discards the least reliable ones, and ensures that you don't have two disks from the same production run in the same array. You're still getting the same drives you can buy elsewhere for a fraction of the price, but you're getting more diversity.
ZFS doesn't have ECC, but it does checksum each block, so it can detect per-block errors. If you have valuable data, you can set the copies property to some value greater than 1 for that data set and it will ensure that each block is duplicated on the disk so if one fails a checksum then the other will be used to recover. If you have three disks, you can use RAID-Z, which loses you 1/3 of the space (not 1/2) and allows any single-disk failures to be recovered. Running zfs scrub will make it validate all of the data and when any read fails the checksums recover the data from the other two.
The reason it doesn't use ECC is that ECC doesn't mesh well with the failure modes of disks. ECC is used in RAM because when it gets hot, hit by a solar ray, or whatever, it is common for a single bit to flip (in a single direction, which makes the error correction easier). In a disk, you typically have an entire block fail, not a single bit. Modern disks use multiple levels, so the smallest failure that is even theoretically possible might be a single byte (or nibble) in a block. And since the failure isn't biased, you'd need a fairly large amount of space. A better approach would be for the filesystem to generate something like Reed–Solomon code blocks for every n blocks that are written. This would allow single-block errors to be recovered, as long as the other blocks are okay. The down side of this approach is that the error correcting block would need to be rewritten whenever any of the other blocks is modified. this might be relatively easy to add to ZFS, as it uses a CoW structure, so block-overwrites are relatively rare (although erasing a lot of data would require a lot of checksums to be recalculated). This would mean that a single-block write would end up triggering a lot of reads and that would hurt performance. For ZFS, this might actually be easier to implement, as blocks are written out in transaction groups and so including an error correction block at the end might be a fairly simple modification.
In those parts of the country where there was rioting, there is a tendency for the police to smash people's heads and shoot them in their beds
Can you site a single instance of the police shooting someone in their beds?
I live in the UK, and I've never had anything other than polite and courteous interactions with the police. Of course, that might be because I've never been involved in smashing shop windows and stealing stuff...
They're not doing it to improve civility or stop anonymous abuse. These can both be solved by other, less intrusive mechanisms. Even Slashdot manages it: penalise anonymous users a lot, penalise new members a little bit, and require users to establish a reputation to gain full participation. If they lose that reputation, their ability to participate drops off. The real reason that they want real names is because it makes the information that they harvest and sell to advertisers more valuable if it's tied to a real name and address.
If production went down 100% (i.e. no more DRAM is produced), would you expect prices to only go up 100% (i.e. double)? I think that supply-demand curves don't look how you think they look...
The problem is that the NSA and GCHQ have dual mandates. They are responsible for both ensuring their respective countries are not vulnerable to attacks and for ensuring that they have techniques for attacking others. This means that when they discover a vulnerability in a piece of widely deployed software, they have conflicting requirements. If they publish it, then the systems that they're defending will be safer because it will be fixed, but if they don't publish it then the systems that they're attacking will remain vulnerable. This gets even worse when they start introducing intentional back doors (given how many Russian spies there were in these institutions during the Cold War, it's pretty much expected that there will be some Chinese spies in there now, so those back doors are almost certainly not secret).
But basically no individuals are equipped to leverage Android on their own.
Applications are the easy bit. See F-Droid. The hard part is getting device drivers for your hardware...
Even without the incentive not to check for prior art in patents (triple damages for infringement if it can be proven that you knew you were infringing), have you ever read a modern patent? Trying to implement something from a patent is harder than inventing it from scratch. Compare this with patents a hundred years ago, where even with the linguistic drift it's usually possible to work out what they were describing and how it worked.
Nope, most of the long-term studies judge success based on degree and employment. Try again.
Only two factors have consistently been shown to positively correlate with student performance: parental support and teacher enthusiasm. But, hey, throwing technology at the problem might work this time...
We only made the switch to remove gcc from the default install on amd64, i386 and ARMv6. ARM v6 is still compiled with gcc (clang probably should work okay on ARMv4 and ARMv5, but the people still using them tend to be conservative). It's not yet the default on MIPS, but since we're about to release an open source MIPS core at my day job that runs FreeBSD we're working on improving MIPS support. PC98 is i386. It currently does include gcc, because some oddity in its bootloader requires gcc (not sure what). XBox is also i386. PowerPC 32 is still a little way behind (no PIC support, some issues with TLS), but PowerPC64 is now working fine with clang so will make the switch fine. IA64 is basically dead and Oracle seems to be trying to kill SPARC64 as a platform for anything other than Oracle software, so we'll see if they're still around in a few years. There is a SPARC64 back end in LLVM, but it's not well maintained because no one cares.
You might want to look at the list of LLVM developers and see how many work at Sony some time. In particular, the LLVM Linker (lld) is lead by a Sony engineer. Now take a guess at which product group he works in...
Seriously, the core devs hate free software
Speaking as a member of the FreeBSD Core Team, who contributes code to a GNU project (GNUstep) and has signed an FSF copyright assignment for the purpose, and who was the one to make the disable-gcc-by-default commit, I have to say: What?
With my LLVM dev hat on, please can you point to some analyses that are implemented in GCC and not LLVM? I have some masters' students in need of interesting projects in a few months...
RDRAND is not used directly, it's 'whitened' by Yarrow or a similar algorithm (there are now a few pluggable options, although I'm not sure they made it into 10.0). It's one entropy source, and things like interrupt timings and so on are others. If RDRAND is produces non-deterministic data in a way that are easy for the NSA to predict then there are some possible network attacks involving TCP sequence numbers early on in the boot. After that, there are other entropy sources (e.g. interrupt timings) that make it much harder to predict the inputs to Yarrow (and, unless Yarrow is also broken, you need all of the inputs to be able to predict the output).