Just store the state of the vector space that corresponds to proper initialization in some sort of HSM. As part of the boot process you load that into memory and you are now initialized and ready to do full-strength authentication.
If you're willing to do that, then just encrypt the password file and store the key in an HSM. Having the initialization vector is equivalent to having the password file with just conventional hashes.
I guess the advantage with this system is that if you have to restore from a backup tape after physical loss of the HSM then you can recover the file by just having a bunch of accounts log in.
Of course, if the attacker has a bunch of valid accounts on the system, then he can do the same thing and get the hashes...
Why can't a chromebook get a virus? have that made the disk read only or something? perhaps discovered some way to write a perfect OS with Zero vulnerabilities and no need to ever update it?
It uses secure boot. Look it up.:)
Sure, it might be possible to jailbreak it as is routinely done with iPhones, but it would require that kind of effort. Since every Chromebook has a little switch that lets you disable the secure boot feature after a self-imposed wipe nobody bothers to jailbreak them.
Basically it is like having tripwire on steroids. If the image isn't signed by Google and valid, then it won't run.
Well, you can keep it encrypted in someone else's cloud (assuming you trust them not to make that option not work in an update), but yes, it would be nice if Android/ChromeOS/etc could be pointed at your own authentication systems.
Beware of any statements like, "don't need antivirus" and "gets a laptop that can't get viruses"
The OS is read-only and uses secure-boot. If something does manage to install itself there, the device will refuse to boot and you need to do an OS reload from a thumb disk to restore it (which is fairly easy to do).
So, think of it like having the antivirus built-in. Otherwise everything happens in the Chrome browser where every tab runs in a jail. Sure, that can have bugs, but those get discovered and fixed by updates. So, again, think of it like having the anti-virus built-in.
What does an anti-virus do which a Chromebook isn't already doing?
Having a third party manage things has it's own set of associated risks. Which may be poorly understood/managed if this is a radical change of paradigm. Also "full-disk encryption" is pointless on a device which isn't storing data. A critical factor is how easy is corporate management with Chromebooks. Including can it be done using servers you control...
It would actually be nice to be able to point Android/Chromebooks/etc at your own servers. There is nothing about the design that necessitates that they talk to Google. That's just how Google set them up.
Full-disk encryption still protects your cache/cookies, and any files you may have downloaded just to view, or to upload somewhere else. It also prevents somebody else from installing a software keylogger/etc (in conjunction with secure boot). I think it is relevant for any PC.
Other issues include do you want Google (and their "friends") looking over what you are doing?
Well, you can use Google for authentication-only. You don't HAVE to sync your settings, or use their other services. But, yes, it would be nice if you could run your own authentication/sync servers.
Can loss of Internet connectivity (or a server on the other side of the planet) inhibit you ability to do anything, even where your LAN/WAN/VPN may be perfectly functional? (Including in cases where you havn't outsourced your data.)
The devices are perfectly capable of running offline entirely - they cache credentials. Of course, they won't be syncing/etc if they can't reach Google.
Also without proper control of encryption keys (and possibly encryption methods) supposedly encrypted data may as well be in plaintext for all practical purposes.
The chrome sync code is all available in Chromium, so anybody can audit the algorithm. If you check the box your settings should be encrypted before they are uploaded to Google using your password. So, that side of things seems to be handled fairly well. Of course, you're already trusting Google to be able to deploy updates on your device, so if they want to give one of your Chromebooks a "special" update that captures your password or whatever they could conceivably do so. Also, it is difficult to validate that the pre-loaded software on a Chromebook is using the source code in Chromium.
In a tight economy, side cameras will only sell if they are a. manditory on all new models, or. b. not marked up at the same exorbitant rate as side mirrors.
Actually, one of the reasons for having cameras is that they can boost fuel economy. With CAFE requirements that means that manufacturers can sell more SUVs and stay under the limits. So, there is plenty of incentive to put reasonably-priced cameras on cars, if not make them standard.
Airliners do have external cameras, mainly for taxiing (on some airliners the pilot is seated forward of the nose wheel and if you're in a tight spot it is very useful to actually be able to see under the plane and be able to just barely cut corners near the edges of the taxiways. Having cameras pointed at control surfaces isn't actually a bad idea, but they do have servos on them and their positions can be displayed in the cockpit.
2300 Chrome machines vs. 4300 XP machines, I wonder what the true saving are. Since the totals doesn't add up, what did they do eliminate 2000 workers and 2000 machines, or are they going to make 2000 workers use pen and paper or am I missing some here?
No idea why the numbers changed (though it is pretty common in mass-update situations like this to audit workstation assignments and get rid of all the extra laptops that got requisitioned so that somebody could have two/etc).
However, I can easily see why a Chromebook is cheaper in a corporate environment, assuming it can run all your software. They're nearly zero-effort to deploy (just log in once using an admin account and it auto-provisions), self-update automatically, don't need antivirus, already have full-disk encryption and secure boot, and Google handles all the identity management. You only use them with remote applications (web or otherwise), so there is nothing to backup locally, and no retention issues with legal holds. Basically you can eliminate almost your entire workstation-management infrastructure, and the hardware isn't really any more expensive than what you'd otherwise purchase. If somebody breaks their laptop, they just go over to the supply closet and get a new one, log in, and in 30 seconds everything is auto-synced.
The catch is that you have to be able to run EVERYTHING in Chrome.
A chromebook gives any business a fairly complete enterprise-level workstation management service for free. To get to all the management functions you need a Google Apps account, but even Grandma gets a laptop that can't get viruses, backs up everything important offsite automatically, auto-updates, and which is fully encrypted. That is a whole bunch of software/configuration/caretaking if you want to do it on Windows.
Basically, if you communicated with someone that is 'reasonably believed' to be a terrorist, you've lost constitutional protection against searches without a warrant, according to the NSA.
According to the NSA in this particular admission. Adding it all up you're a person of interest if you: 1. Are a foreign terrorist. 2. Are a foreigner at all (we're apparently recording every SMS everywhere, and who knows how many full calls). 3. Communicate with a foreign terrorist. 4. Probably anybody who communicates with #3, to who knows how many degrees of separation. 5. Administer a system that a potential foreign terrorist uses, or work for a company that administers such a system.
It isn't a stretch to say that while their target is foreigners they're willing to target just about anybody who might get them a step closer to their goal, innocent or not. And everybody is a foreigner to all but one country, so if any other governments are taking the NSA approach then just about everybody on earth is being spied on.
And what happens if you're a target of survailence? They're listening to your calls, or at least capturing all your call metadata. They're capturing all your network traffic. Your computer is almost certainly rootkitted (I'm surprised they don't have a patent on one-click pwn assuming Amazon didn't beat them to it). Every major telecom, ISP, online service, etc is handing over feeds of everything you do, and probably everything the people you communicate with are doing as well. Your employer probably has been pwned using your credentials as well.
Just think about how over-the-top that sounds, but I could dig up a citation for just about everything up there. They have a whole infrastructure for rooting devices - somebody punches in your IP, and every box sending traffic from that IP gets directed to exploit servers and then your boxes get handed over to a support group to perform ongoing maintenance while the analysts sift through everything. I run a tor relay - there are probably analysts taking better care of "maintaining" my systems than most IT teams dedicate to their server farms.
In the food industry it isn't considered acceptable to mishandle food and make up for it with a few tests.
Actually it is. Batches get rejected after tests and then the batches after get tested.
Yes, but you don't take a batch of food that was all mixed together, discover that they were improperly handled in a manner that could render them unsafe, and then run a test and based on the result ship them anyway.
Given the extensive testing, gross negligence would be a really hard sell.
They explicitly knew that it came from an origin that could have introduced salmonella. Unless you test the entire lot (destructively) you can't be certain that it isn't there. That could be argued as gross negligence.
In the food industry it isn't considered acceptable to mishandle food and make up for it with a few tests.
Even though samples were tested, there could be a concern that there were problems in the food that was not tested.
There is actually a principle in the regulation of food and pharamceuticals that you can't "test quality into a product."
You build quality into a product by controlling the manufacture, and testing really just serves as a confirmation that all went well.
There is no way to sample peanut butter such that you can be certain that there isn't a microbe in the part of the peanut butter you didn't test. Now, you can make that risk fairly low as you sample more and more, but if there was reason to suspect the integrity of the product in the first place then you can imagine the lawyers lining up.
And, as others pointed out, if they give away product for free they still face liability, make no money, and potentially undercut their own sales. If some poor guy dies of salmonella you can imagine the tales of a company feeding them peanut butter that they'd already determined isn't good enough for ordinary people...
Interesting - sounds about like the impact of free trade in the real world. You min-max each step of a supply chain in the country whose laws are most allowing of polluting/exploitation/etc of that process, and sell the product wherever you can get top dollar for it.
Should the OS care how the drive works? Shouldn't it just ask it to read/write data?
In reality there is a place for both - at least until cache gets so cheap that we can afford to have gobs of it everywhere.
There are optimizations the OS can do due to having more information about what applications are up to and the filesystem design. There are optimizations the physical drive can do due to understanding how the data is physically stored on the disks. Until one or the other changes there is good reason to cache in both places.
Sure, but the OS operating the drive has its own RAM cache.
There are only a few reasons to put a cache on a drive that I can think of:
1. If the RAM is battery-backed then writes to the drive cache can be treated as writes to the drive itself. 2. If the physical operation of the drive is abstracted from the OS, then it may only be possible to optimize out-of-order writes by utilizing a cache at the hardware level. For example, an OS might write a consecutive series of blocks, but perhaps one of those blocks was remapped by the drive to a different cylinder making it MUCH cheaper to write that one block later. 3. A variation of #2 is that on SSD the erase and write operations operate on different sized blocks, so there might be other optimizations the controller can make if it can perform operations out-of-order.
So, RAM being faster on its own isn't really a driver for putting a cache on a drive (just spend the money on more system RAM, where it can be used more flexibly). However, a RAM cache allows the drive to do other optimizations on writes not possible at the OS level.
Suppose a university scientist wins a grant to buy a million dollar instrument. Thirty years later, the scientist dies. Nobody knows what the instrument is anymore, or what it is worth. University policy does not allow the sale of excess property. Nobody knows what restrictions were placed on the sale of the equipment in the grant award. Nobody wants to pay money to figure any of these things out. So, the equipment is either ignored or landfilled.
In my experience this happens often.
Yup. At work there is still an old VAX sitting in a room because nobody wanted to deal with the disposal forms. It still had residual capitalization since the asset was tied to the value of the work required to deploy it (the hardware is the cheap part of a custom software project), and the writeoff went across many years. It couldn't be disposed of without fully depreciating it, which is a PITA. So, it just sits there.
The value of any kind of specialized hardware also depends greatly on finding the right buyer. We had a bunch of data acquisition boxes that only worked with a particular vendor's proprietary software, but newer versions of the software used different boxes and the old ones were discontinued. That made the old boxes either worthless or priceless depending on whether you could find somebody desperate for them.
Yup. Short of a lookup for a list of every name in every language on the planet, how is a computer going to realize that "Nadine," "Nadia," "Nadija," "Nadezda," and "Nadezhda" could be the same person? And that is just limiting ourselves to the 26 letters of the English alphabet.
No, it's a clear case of we fucked up and people died. The explanation is that it was unavoidable, and funny enough, you see, someone just made a spelling mistake and that's why we didn't catch the guy. Totally unavoidable.
It really reflects that names make really poor primary keys. Until we start tatooing guids on people at birth, we're going to have problems like this. Either you let the terrorist go because of a misspelling, or you detain everybody named "Mary Jane" because somebody with that name committed some crime.
I'm not sure if all of those are on the roadmap - a few are.
As I said, I think the main issue with btrfs is maturity. Btrfs "supports" raid5. Nobody sane would store anything important on it today. Etc...
I suspect that df and quota support fall into that general category of stuff that is half-done. You can add quotas after creating subvolumes, but the userspace tools don't automatically set them up for existing subvolumes today. There is no reason it couldn't do the job in the future.
Heck, just the output of the userspace tool when you look at your quotas would be vastly more useful if they just cleaned it up (mapping IDs to paths, etc).
Df is actually a bit trickier, because volume-management is a bit more flexible in btrfs compared to ZFS. A collection of 5 drives might have some files stored RAID1, and some files stored RAID5, and some of the RAID 5 files might be striped across differing numbers of drives. So, understanding how much space is in use is easy, but understanding how much is free is a bit trickier. That said, clearly it can be done better than it is today.
So, most of the issues with btrfs vs ZFS just reflect that the former isn't quite done yet. They're not really limitations of the filesystem itself.
The one item you brought up which does concern me is encryption - it definitely is an afterthought on btrfs and it might be a long time before it is properly supported as a result.
Btrfs supports RAID 5/6, with reshaping (ZFS does not support the latter).
Then there is the issue of bit rot. A ZFS scrub isn't just an online fsck... it goes through every single sector looking for corruption and either finding it... or if there is redundancy left, fixing it.
Fully supported on btrfs. I do it weekly. All reads are of course checked, but a scrub checks all the disks asynchronously.
Finally there is the issue of snapshots. With ZFS, I can mount a drive, snapshot the entire system, copy that snap onto the mounted drive, dismount it and be on my way, a backup done.
Snapshots are fully supported on btrfs. You can also use send/receive with them which would be more efficient in this use case than just copying the snapshot (which copies all data and not just changes since the last snapshot).
My question was what features does ZFS have which btrfs doesn't have? All of these are btrfs features. The last two are fairly robust - raid 5/6 is pretty immature and I don't run it on my own systems yet.
They preach freedom but use eminent domain to steal people's property (the Keystone Pipeline they are so fond of is built on stolen land)...
While I agree with most of your post, there has to be SOME place for eminent domain, and something like a pipeline seems like an appropriate use of it. It isn't like they can just skip a 100 yard section of the pipeline because somebody doesn't want to sell.
Now, I strongly oppose using eminent domain to just hand property over to corporations or to buy parcels of land that could just be bought on the market. It should only be used when it is important to the nation that something be sited in a particular place. If you just need a police station somewhere in town, then look at the property listings. If you need a pumping station at this point along a water main, then see if you can just get a reasonable price from somebody in the immediate vicinity but if not identify the ideal location and give the owner market value for their loss (I'd probably add a premium to deter abuse - though I suppose even that is potentially subject to abuse of a different kind).
There is no other reasonable way to do it. Generally things like roads/pipes/etc work better when they're straight, so you can't zig-zag around every house in the state.
Slashdot Mirror
Just store the state of the vector space that corresponds to proper initialization in some sort of HSM. As part of the boot process you load that into memory and you are now initialized and ready to do full-strength authentication.
If you're willing to do that, then just encrypt the password file and store the key in an HSM. Having the initialization vector is equivalent to having the password file with just conventional hashes.
I guess the advantage with this system is that if you have to restore from a backup tape after physical loss of the HSM then you can recover the file by just having a bunch of accounts log in.
Of course, if the attacker has a bunch of valid accounts on the system, then he can do the same thing and get the hashes...
Why can't a chromebook get a virus? have that made the disk read only or something? perhaps discovered some way to write a perfect OS with Zero vulnerabilities and no need to ever update it?
It uses secure boot. Look it up. :)
Sure, it might be possible to jailbreak it as is routinely done with iPhones, but it would require that kind of effort. Since every Chromebook has a little switch that lets you disable the secure boot feature after a self-imposed wipe nobody bothers to jailbreak them.
Basically it is like having tripwire on steroids. If the image isn't signed by Google and valid, then it won't run.
Well, you can keep it encrypted in someone else's cloud (assuming you trust them not to make that option not work in an update), but yes, it would be nice if Android/ChromeOS/etc could be pointed at your own authentication systems.
Beware of any statements like, "don't need antivirus" and "gets a laptop that can't get viruses"
The OS is read-only and uses secure-boot. If something does manage to install itself there, the device will refuse to boot and you need to do an OS reload from a thumb disk to restore it (which is fairly easy to do).
So, think of it like having the antivirus built-in. Otherwise everything happens in the Chrome browser where every tab runs in a jail. Sure, that can have bugs, but those get discovered and fixed by updates. So, again, think of it like having the anti-virus built-in.
What does an anti-virus do which a Chromebook isn't already doing?
Having a third party manage things has it's own set of associated risks. Which may be poorly understood/managed if this is a radical change of paradigm. Also "full-disk encryption" is pointless on a device which isn't storing data.
A critical factor is how easy is corporate management with Chromebooks. Including can it be done using servers you control...
It would actually be nice to be able to point Android/Chromebooks/etc at your own servers. There is nothing about the design that necessitates that they talk to Google. That's just how Google set them up.
Full-disk encryption still protects your cache/cookies, and any files you may have downloaded just to view, or to upload somewhere else. It also prevents somebody else from installing a software keylogger/etc (in conjunction with secure boot). I think it is relevant for any PC.
Other issues include do you want Google (and their "friends") looking over what you are doing?
Well, you can use Google for authentication-only. You don't HAVE to sync your settings, or use their other services. But, yes, it would be nice if you could run your own authentication/sync servers.
Can loss of Internet connectivity (or a server on the other side of the planet) inhibit you ability to do anything, even where your LAN/WAN/VPN may be perfectly functional? (Including in cases where you havn't outsourced your data.)
The devices are perfectly capable of running offline entirely - they cache credentials. Of course, they won't be syncing/etc if they can't reach Google.
Also without proper control of encryption keys (and possibly encryption methods) supposedly encrypted data may as well be in plaintext for all practical purposes.
The chrome sync code is all available in Chromium, so anybody can audit the algorithm. If you check the box your settings should be encrypted before they are uploaded to Google using your password. So, that side of things seems to be handled fairly well. Of course, you're already trusting Google to be able to deploy updates on your device, so if they want to give one of your Chromebooks a "special" update that captures your password or whatever they could conceivably do so. Also, it is difficult to validate that the pre-loaded software on a Chromebook is using the source code in Chromium.
In a tight economy, side cameras will only sell if they are a. manditory on all new models, or. b. not marked up at the same exorbitant rate as side mirrors.
Actually, one of the reasons for having cameras is that they can boost fuel economy. With CAFE requirements that means that manufacturers can sell more SUVs and stay under the limits. So, there is plenty of incentive to put reasonably-priced cameras on cars, if not make them standard.
Airliners do have external cameras, mainly for taxiing (on some airliners the pilot is seated forward of the nose wheel and if you're in a tight spot it is very useful to actually be able to see under the plane and be able to just barely cut corners near the edges of the taxiways. Having cameras pointed at control surfaces isn't actually a bad idea, but they do have servos on them and their positions can be displayed in the cockpit.
Frankly, I'd be shocked if it didn't include 85% of the world's population. Ollie North is just a bonus...
2300 Chrome machines vs. 4300 XP machines, I wonder what the true saving are. Since the totals doesn't add up, what did they do eliminate 2000 workers and 2000 machines, or are they going to make 2000 workers use pen and paper or am I missing some here?
No idea why the numbers changed (though it is pretty common in mass-update situations like this to audit workstation assignments and get rid of all the extra laptops that got requisitioned so that somebody could have two/etc).
However, I can easily see why a Chromebook is cheaper in a corporate environment, assuming it can run all your software. They're nearly zero-effort to deploy (just log in once using an admin account and it auto-provisions), self-update automatically, don't need antivirus, already have full-disk encryption and secure boot, and Google handles all the identity management. You only use them with remote applications (web or otherwise), so there is nothing to backup locally, and no retention issues with legal holds. Basically you can eliminate almost your entire workstation-management infrastructure, and the hardware isn't really any more expensive than what you'd otherwise purchase. If somebody breaks their laptop, they just go over to the supply closet and get a new one, log in, and in 30 seconds everything is auto-synced.
The catch is that you have to be able to run EVERYTHING in Chrome.
A chromebook gives any business a fairly complete enterprise-level workstation management service for free. To get to all the management functions you need a Google Apps account, but even Grandma gets a laptop that can't get viruses, backs up everything important offsite automatically, auto-updates, and which is fully encrypted. That is a whole bunch of software/configuration/caretaking if you want to do it on Windows.
Chrombook is Linux rite?
It is Gentoo. :) Well, in the same sense that Ubuntu is Debian...
Basically, if you communicated with someone that is 'reasonably believed' to be a terrorist, you've lost constitutional protection against searches without a warrant, according to the NSA.
According to the NSA in this particular admission. Adding it all up you're a person of interest if you:
1. Are a foreign terrorist.
2. Are a foreigner at all (we're apparently recording every SMS everywhere, and who knows how many full calls).
3. Communicate with a foreign terrorist.
4. Probably anybody who communicates with #3, to who knows how many degrees of separation.
5. Administer a system that a potential foreign terrorist uses, or work for a company that administers such a system.
It isn't a stretch to say that while their target is foreigners they're willing to target just about anybody who might get them a step closer to their goal, innocent or not. And everybody is a foreigner to all but one country, so if any other governments are taking the NSA approach then just about everybody on earth is being spied on.
And what happens if you're a target of survailence? They're listening to your calls, or at least capturing all your call metadata. They're capturing all your network traffic. Your computer is almost certainly rootkitted (I'm surprised they don't have a patent on one-click pwn assuming Amazon didn't beat them to it). Every major telecom, ISP, online service, etc is handing over feeds of everything you do, and probably everything the people you communicate with are doing as well. Your employer probably has been pwned using your credentials as well.
Just think about how over-the-top that sounds, but I could dig up a citation for just about everything up there. They have a whole infrastructure for rooting devices - somebody punches in your IP, and every box sending traffic from that IP gets directed to exploit servers and then your boxes get handed over to a support group to perform ongoing maintenance while the analysts sift through everything. I run a tor relay - there are probably analysts taking better care of "maintaining" my systems than most IT teams dedicate to their server farms.
Actually it is. Batches get rejected after tests and then the batches after get tested.
Yes, but you don't take a batch of food that was all mixed together, discover that they were improperly handled in a manner that could render them unsafe, and then run a test and based on the result ship them anyway.
Independent batches are, well, independent.
Given the extensive testing, gross negligence would be a really hard sell.
They explicitly knew that it came from an origin that could have introduced salmonella. Unless you test the entire lot (destructively) you can't be certain that it isn't there. That could be argued as gross negligence.
In the food industry it isn't considered acceptable to mishandle food and make up for it with a few tests.
Even though samples were tested, there could be a concern that there were problems in the food that was not tested.
There is actually a principle in the regulation of food and pharamceuticals that you can't "test quality into a product."
You build quality into a product by controlling the manufacture, and testing really just serves as a confirmation that all went well.
There is no way to sample peanut butter such that you can be certain that there isn't a microbe in the part of the peanut butter you didn't test. Now, you can make that risk fairly low as you sample more and more, but if there was reason to suspect the integrity of the product in the first place then you can imagine the lawyers lining up.
And, as others pointed out, if they give away product for free they still face liability, make no money, and potentially undercut their own sales. If some poor guy dies of salmonella you can imagine the tales of a company feeding them peanut butter that they'd already determined isn't good enough for ordinary people...
Interesting - sounds about like the impact of free trade in the real world. You min-max each step of a supply chain in the country whose laws are most allowing of polluting/exploitation/etc of that process, and sell the product wherever you can get top dollar for it.
Should the OS care how the drive works? Shouldn't it just ask it to read/write data?
In reality there is a place for both - at least until cache gets so cheap that we can afford to have gobs of it everywhere.
There are optimizations the OS can do due to having more information about what applications are up to and the filesystem design. There are optimizations the physical drive can do due to understanding how the data is physically stored on the disks. Until one or the other changes there is good reason to cache in both places.
RAM is still much faster than flash.
Sure, but the OS operating the drive has its own RAM cache.
There are only a few reasons to put a cache on a drive that I can think of:
1. If the RAM is battery-backed then writes to the drive cache can be treated as writes to the drive itself.
2. If the physical operation of the drive is abstracted from the OS, then it may only be possible to optimize out-of-order writes by utilizing a cache at the hardware level. For example, an OS might write a consecutive series of blocks, but perhaps one of those blocks was remapped by the drive to a different cylinder making it MUCH cheaper to write that one block later.
3. A variation of #2 is that on SSD the erase and write operations operate on different sized blocks, so there might be other optimizations the controller can make if it can perform operations out-of-order.
So, RAM being faster on its own isn't really a driver for putting a cache on a drive (just spend the money on more system RAM, where it can be used more flexibly). However, a RAM cache allows the drive to do other optimizations on writes not possible at the OS level.
Suppose a university scientist wins a grant to buy a million dollar instrument. Thirty years later, the scientist dies. Nobody knows what the instrument is anymore, or what it is worth. University policy does not allow the sale of excess property. Nobody knows what restrictions were placed on the sale of the equipment in the grant award. Nobody wants to pay money to figure any of these things out. So, the equipment is either ignored or landfilled.
In my experience this happens often.
Yup. At work there is still an old VAX sitting in a room because nobody wanted to deal with the disposal forms. It still had residual capitalization since the asset was tied to the value of the work required to deploy it (the hardware is the cheap part of a custom software project), and the writeoff went across many years. It couldn't be disposed of without fully depreciating it, which is a PITA. So, it just sits there.
The value of any kind of specialized hardware also depends greatly on finding the right buyer. We had a bunch of data acquisition boxes that only worked with a particular vendor's proprietary software, but newer versions of the software used different boxes and the old ones were discontinued. That made the old boxes either worthless or priceless depending on whether you could find somebody desperate for them.
btrfs lacks stability and reliability
Hence my original question, "Beyond maturity, what is actually missing?"
Yup. Short of a lookup for a list of every name in every language on the planet, how is a computer going to realize that "Nadine," "Nadia," "Nadija," "Nadezda," and "Nadezhda" could be the same person? And that is just limiting ourselves to the 26 letters of the English alphabet.
No, it's a clear case of we fucked up and people died. The explanation is that it was unavoidable, and funny enough, you see, someone just made a spelling mistake and that's why we didn't catch the guy. Totally unavoidable.
It really reflects that names make really poor primary keys. Until we start tatooing guids on people at birth, we're going to have problems like this. Either you let the terrorist go because of a misspelling, or you detain everybody named "Mary Jane" because somebody with that name committed some crime.
How is that not probable cause for a warrant?
Heaven help us when somebody named "John Smith" blows up a bus.
I'm not sure if all of those are on the roadmap - a few are.
As I said, I think the main issue with btrfs is maturity. Btrfs "supports" raid5. Nobody sane would store anything important on it today. Etc...
I suspect that df and quota support fall into that general category of stuff that is half-done. You can add quotas after creating subvolumes, but the userspace tools don't automatically set them up for existing subvolumes today. There is no reason it couldn't do the job in the future.
Heck, just the output of the userspace tool when you look at your quotas would be vastly more useful if they just cleaned it up (mapping IDs to paths, etc).
Df is actually a bit trickier, because volume-management is a bit more flexible in btrfs compared to ZFS. A collection of 5 drives might have some files stored RAID1, and some files stored RAID5, and some of the RAID 5 files might be striped across differing numbers of drives. So, understanding how much space is in use is easy, but understanding how much is free is a bit trickier. That said, clearly it can be done better than it is today.
So, most of the issues with btrfs vs ZFS just reflect that the former isn't quite done yet. They're not really limitations of the filesystem itself.
The one item you brought up which does concern me is encryption - it definitely is an afterthought on btrfs and it might be a long time before it is properly supported as a result.
RAID 5/6 is exactly what is needed.
Btrfs supports RAID 5/6, with reshaping (ZFS does not support the latter).
Then there is the issue of bit rot. A ZFS scrub isn't just an online fsck... it goes through every single sector looking for corruption and either finding it... or if there is redundancy left, fixing it.
Fully supported on btrfs. I do it weekly. All reads are of course checked, but a scrub checks all the disks asynchronously.
Finally there is the issue of snapshots. With ZFS, I can mount a drive, snapshot the entire system, copy that snap onto the mounted drive, dismount it and be on my way, a backup done.
Snapshots are fully supported on btrfs. You can also use send/receive with them which would be more efficient in this use case than just copying the snapshot (which copies all data and not just changes since the last snapshot).
My question was what features does ZFS have which btrfs doesn't have? All of these are btrfs features. The last two are fairly robust - raid 5/6 is pretty immature and I don't run it on my own systems yet.
They preach freedom but use eminent domain to steal people's property (the Keystone Pipeline they are so fond of is built on stolen land)...
While I agree with most of your post, there has to be SOME place for eminent domain, and something like a pipeline seems like an appropriate use of it. It isn't like they can just skip a 100 yard section of the pipeline because somebody doesn't want to sell.
Now, I strongly oppose using eminent domain to just hand property over to corporations or to buy parcels of land that could just be bought on the market. It should only be used when it is important to the nation that something be sited in a particular place. If you just need a police station somewhere in town, then look at the property listings. If you need a pumping station at this point along a water main, then see if you can just get a reasonable price from somebody in the immediate vicinity but if not identify the ideal location and give the owner market value for their loss (I'd probably add a premium to deter abuse - though I suppose even that is potentially subject to abuse of a different kind).
There is no other reasonable way to do it. Generally things like roads/pipes/etc work better when they're straight, so you can't zig-zag around every house in the state.