It is a lot easier if you make it a per-team plan rather than a per-employee plan. Hire people into specific parts of the company with the understanding that those entire teams will work the alternative schedule. If someone wants to work a normal schedule, put that person on a different team that works a normal schedule.
Sounds like they were ahead of their time. That must have been more than seven years ago.
California employment law changed in 2009 to explicitly allow what they call an "alternative workweek schedule" (Title 8, Section 11170, part 5). That allows employees to work up to 10 hours per day without overtime as long as your total hours don't exceed 40 per week and as long as it doesn't result in any shifts less than four hours long.
There are specific rules and exceptions, of course:
The workers have to vote to enact the policy. It cannot be forced upon them by management.
If the employer cuts someone's hours below the number agreed upon in the original policy, they have to pay according to the normal overtime rules.
The employer must make a reasonable attempt to accommodate any employees hired prior to adopting the alternative schedule who cannot make that schedule work for them.
Certain fields have different rules for safety reasons.
But otherwise, what you described is perfectly fine in California now, unless I'm missing something.
I find it odd that they specify which days have core hours. I mean, an ideal 30-hour week for a lot of folks would be Monday-Tuesday and Thursday-Friday so that they can have a break in the middle of the week. Or Tuesday through Friday, shifting Monday holidays to Tuesday. Or not having to work on the day when their kids have baseball/soccer/* games after school. It would make a lot more sense to say that you have to be there for those core hours on four days, without specifying which. It is not as though they're going to make use of the space on Friday, Saturday, and Sunday anyway.
For that matter, I find it really weird that they would choose 30 hours and not 24. If they hired people for 24-hour weeks (3 days), then they could have one shift from Monday through Wednesday and a second shift from Thursday through Saturday (or alternating days if folks preferred that). That would mean that their facilities cost for the second set of employees would be almost zero (maintenance and power only), and those savings would probably make up for the extra benefits. So they would be able to increase their output by 20% by increasing their costs by about 20%, all while employing twice as many people and giving employees the shorter work weeks that many of them would prefer, rather than decreasing their output by 20% by decreasing their costs by much less than 20%.
But maybe I've thought way too much about how to make part-time employment work at a tech company.
My first machine had 16 kilobytes, so I feel your pain.:-)
With that said, there's a huge difference between the space requirements for hand-rolled assembly code running on an 8-bit CPU and software that sits atop a modern monolithic kernel and glibc on a 32-bit (or worse, 64-bit) CPU.:-) Just saying.
I stand corrected. People are finding ways to do things in ridiculously small amounts of disk space.
Still, the small one doesn't really give the Pi a run for its money, which was the reason for my initial comment. After all, most folks stick a large SD card in the Pi for development, and scale back for deployment. And even then, they don't typically scale back to megabytes of storage, if only because it is basically impossible to find new stock of flash cards under about 8 GB these days. So any Pi setup you could come up with would wipe the floor with either of these RAM-wise and CPU speed-wise, and would wipe the floor with the smaller one storage-wise, too.
It is slightly smaller and has Wi-Fi, of course, so for some purposes, it might be interesting. Still, unless space is really that critical, I'd much rather use a Pi with a cheap USB Wi-Fi nub (assuming the Pi Zero doesn't have broken USB power supply limits like the original Pi).
I hope they plan to put in a connector for an external Wi-Fi antenna. No antenna that you could fit into something the size of a cherry is likely to be decent. Not to mention that anything you put the device into is going to reduce your signal strength.
Beyond that, my main concern would be the lack of flash storage. I used to build ramdisks for MkLinux, and you couldn't even fit a kernel with the RedHat installer into 16 MB. And that was fifteen years ago. I'd be surprised if a kernel with a full driver stack would even fit by itself into 16 MB of flash.... And I didn't even know you could still get flash parts that small. Is that supposed to be 16 GB, by some chance?
I've pretty much concluded that all the PHP-based bulletin boards are a security nightmare. Even the ones that are small enough to audit tend to be filled with old-style mysql_query calls and other horrors of the past.
The best thing about PHP 7, in my view, is that they're finally killing the old MySQL API. They should have done that years ago. Now, you'll be able to tell which software is reasonably up-to-date based on whether it supports PHP 7 or not. Incidentally, vBulletin's website says that it still doesn't. That's probably not a good sign.:-)
To be fair: A normal computer doesn't have this at all and a strong passphrase protects it just fine.
A strong passcode protects an iPhone just fine, too, AFAIK. A four-digit numerical passcode does not, and would not protect a computer, either. If anything, it would protect a typical computer far less, because it is far easier to interpose a disk emulator (passing reads through, storing writes to a separate device) on the SATA bus between a computer and its drive than between a CPU and flash parts that are soldered onto the logic board.
There already was a way to break the encryption, they knew about it and they still went ahead with the design.
All encryption is breakable if you can get to the keys, and the compromises basically amount to being able to get to the keys and brute-force the passcode for the keys. That's not really an unreasonable design when you consider how few attackers would have the resources to even do that much. The fact that they've hardened it further is a good thing, of course.
... even proper encryption key handling alone would've avoided that fiasco yet they failed to implement such feature leaving every phone of that particular model susceptible to brute-force attacks.
If by proper encryption key handling, you mean a dedicated crypto processor with its own isolated storage and no way to extract the keys from it, then yes. However, that's several orders of magnitude more hardened than you would typically expect for encryption key handling outside of major CAs. It certainly isn't typical of... well, anything, really.
And besides, I'm talking about tunnels that are just big enough for a small robot to crawl through and pull wires, not big enough for a person to walk through. The smaller the tube (and the smaller the entrances to it), the easier it is to seal the access ports enough to keep it reasonably dry.
Also, those cables are designed to go underground, so being in water shouldn't cause problems anyway. And if water does cause problems, that likely means that mice have eaten the jacket, which can happen underground just as easily. But because it is in a tube, it is much easier to fix. You just pull a new wire, reconnect each circuit at both ends, then pull the defective wire out.
I wasn't factoring in water and sewer. Those don't get upgraded that often, typically, and although repairs to pipes certainly suck, they usually aren't frequent, either. But wire infrastructure has to be updated to new tech every few years, whether you're replacing bad phone bundles or failing coax or fiber bundles that have gotten eaten by a mouse or pulling additional fibers to increase capacity or whatever.
When you need to upgrade the wire infrastructure, it is really handy to be able to pull new cables through tubes with a robot or fish tape or any number of other tools, and you don't actually need to get people down into the tubes at all. It is certainly easier than digging up the street. And that also makes it much more trivial for new ISPs to add their cables alongside existing services (within reason).
But yeah, if your city has the money to put in proper sewer tunnels, go for it.:-)
Nice job making up numbers, but they aren't at all accurate. Rolling and wind resistance isn't negligible, and your generator is going to tack on a lot of drag.
A trunk-deck-height pod sticking out two or three feet from the back of the vehicle? It will add a bit of drag, but I think you're grossly overestimating how much. After all, the trailer would basically be in your slipstream.
And the rolling resistance is almost proportional to the weight, as I understand it. Spreading the same weight across more wheels makes only a small difference in the overall rolling resistance because you end up with proportionally less tire surface touching the road on each tire.
This means that assuming you keep all the other factors equal, putting the engine in a trailer should have almost no impact. Any apparent savings comes mainly from having less battery capacity in the hybrid (and thus less original vehicle weight before you add the engine), rather than from having the engine inside the vehicle instead of bolted on externally.
Also, do you think that your generator will just drive the electric motor with enough current to allow for hard acceleration or hills (which would also require closely maintained feedback between the motor and generator)? How do you plan to handle that, exactly?
You won't. And that will cause a small efficiency loss while cruising at fast speeds. But those single-digit percentage differences in efficiency don't actually matter if you're only using it for a couple of days out of the year, because that's less than the savings most people would get from being able to use grid power for all but your longest trips. On the average, even if it costs 5x as much for those three days, you're probably ahead. For my driving patterns, I'd be ahead even if it cost me 10x as much.
But obviously, different people have different driving patterns, and some people will benefit more or less from those various tradeoffs. This why options are good. And for people who benefit significantly from an EV over a hybrid, there's nothing fundamentally preventing the manufacture of rentable range extender trailers for the EVs. When you add up the numbers, lots of folks will still be way ahead with that approach.
How do you think you'd average hauling around a generic generator?
If the generator is optimized to produce power at the standard voltages for charging cars, it would be approximately as efficient as existing hybrids, except for the extra wind resistance and rolling resistance involved. For something that you use less than 1% of the time, that's a big win, statistically, and if you have an EV with 300-mile range (or even 150-mile range), nearly every driver will use it less than 1% of the time.
By the way, if you live 50+ miles from where you work, maybe it's time to re-evaluate where you live/work. You know, changing your own situation rather than expecting everybody else to design for you.
Divide by two, subtract 20% for when the battery is ten years old and has less capacity than it did originally, and this really means that the hybrid will end up using fuel if you live more than about 20 miles from work. And the biggest problem is when you're traveling for any sort of recreation, where you aren't going to be parked for several hours to fully charge a battery. In those situations, a Tesla with 300-mile range works fine, and a Chevy will be using gasoline.
And in the grand scheme of things, we really should move away from ICE-based cars for air quality reasons.
No, not really. A "range extender engine" (i.e. hybrid) is the worst of both worlds. With that design, you have:
An engine taking up valuable space that could be used for battery capacity.
A gas tank taking up valuable space that could be used for battery capacity.
The extra cost of a gasoline engine that you own, reducing battery capacity to keep the vehicle affordable.
The weight of an engine, gas tank, and gasoline reducing energy efficiency.
The need to maintain a gasoline engine with all its emissions control nightmares.
A smog check every two years.
The result is that the car in your link can only go a paltry 53 miles on battery. Most days, that's barely half my daily commute. So I'd be running on gasoline about half the time, which would mean I couldn't just charge overnight and avoid stopping for fuel. That basically eliminates the main benefit of an EV, all for the benefit of range that I would use maybe once a year at most.
If, instead, I could just rent a drop-on generator trailer, those headaches and maintenance burdens would be factored into the rental cost, and would be somebody else's problem. And because those costs would be spread out across lots of different renters, the cost to each person would be much lower even after factoring in corporate profits by the rental company.
Perl doesn't typically involve less code compared with using similar techniques in another language languages. Overuse of regular expressions can lead to less code that's less maintainable, but that's the exception that proves the rule. And really, the only thing Perl does differently from other languages is to hide the tens of thousands of lines of regular expression parsing and interpreting code that are needed to make them useful. The code is still there, making the software utterly huge when you look at the complete picture.
The trouble arises where every driver has that one trip a they make that cannot be met by an EV. You end up owning two cars or you get one efficient gasoline vehicle.
That's actually really easy to solve, at least in principle. It involves a gasoline-powered generator with a moderately large gas tank on a small, rolling trailer that hooks over your car's trunk or to a trailer hitch or whatever. In an ideal world, if every car company took electric cars seriously, you'd be able to rent a standard generator trailer at Home Depot or Wal-Mart or whatever for the weekend, and every car would have a 220VAC charge cord hidden in the trunk specifically for that purpose.
I agree with everything on your list except continuous integration. What makes CI a nightmare is that so many CI systems basically eat themselves from the inside out, randomly, causing everything to stop while somebody wastes half a day to debug the CI system. But when it works, CI is a godsend. It makes it easy to know exactly when things started to fail (tests, building, etc.), which makes it much easier to pin down the causes for some types of problems. (Obviously for building, this is trivial, but for test failures, it isn't, necessarily.)
Likewise. OOP is an interesting design pattern, but not when taken to the extreme. Far too often, people use inheritance where an "if" statement in a couple of methods and an initialization-time flag would have sufficed, and the result is invariably unholy.
I don't agree, however, that functional programming is an improvement. Functional programming is a migraine. In my experience, it usually causes things that are relatively trivial in procedural programming to turn into mounds of code. Everything that's bad about OOP is also bad about FP, just in different ways.
The goal should always be to produce less code, to the maximum extent possible, and both of these paradigms tend to do the opposite—particularly in the hands of beginners, but not exclusively so.
People just don't want unbreakable security. They like the idea that if they forget the passcode or if they pass away, someone will be able to break in. They want things to be just secure enough to deter "criminals" but no further. (Sure, such a line is impossible to draw. It doesn't mean users don't want it both ways: impossible for the "bad guys" to break, possible for the "good guys" to break when necessary.)
No matter what you do, there will always be outliers on one side, the other, or both—situations you couldn't predict that result in something being uncrackable when it should be crackable or vice versa. What I think most users want is the ability to choose one way or the other without having seemingly minor decisions come back to bite them in the backside (e.g. turning on two-factor only to find out that doing so unexpectedly prevents certain types of password resets).
What this means is that every behavior that has recoverability impact needs to be explained clearly to the user, and where possible, there should be no interdependencies between these settings. This also means that there should be a mechanism for people to add third-party trust into the system. For example, a kid should be allowed to add trust to his/her parents' account, allowing anyone with access to their account to gain the ability to request a device-present password reset in some way. This should be enabled by default on phones owned by kids, and parental controls should prevent it from being removed until the kid turns 18.
The problem is, those sorts of features don't sell devices. They aren't glamorous features that everybody wants to work on. They're additional effort that, unless mandated by law, probably won't ever happen. And if we start allowing lawmakers to meddle in crypto, there's a nonzero risk that they'll want to be implicitly added to that trust in some nefarious way unless the design deliberately makes it impossible for that to happen. This, in turn, means that adding those features is particularly challenging, making them even less likely to be implemented.
To be fair, the iPhone in question lacked the secure enclave. The techniques to crack into it would not work with newer hardware. It is still an open question whether other techniques could compromise current hardware—though to be fair, that is always the case with new technology up until the point when somebody comes up with a way to break it, so I guess that isn't really saying anything.:-)
Statistically speaking, the best approach for consumers is when the government owns a nonprofit corporation and allows that nonprofit corporation to manage the infrastructure. Example: TVA. This approach takes profit out of the picture and makes it a zero-sum game, while not allowing needed work to get tied up by government bureaucrats who think they need to stick their finger into every pie.
Wise municipalities would add a 4-square-foot prefab box tunnel with ports every couple of hundred feet so that whatever needs to be run in the future can be run without digging up the streets.
There were no extinctions after its last three enormous eruptions...
I never said extinction. I said dramatic population reduction. The previous eruptions didn't occur in a society where 7 billion people were consuming approximately as much food as we are capable of producing technologically.
The ash cloud from a Yellowstone eruption would be expected to blanket most of the U.S. In affected areas, crop yield could fall to near zero overnight, and farmers would end up starting over. Given that the U.S. produces over 40% of the world's soybeans and corn, and 13% of the world's wheat, if those three numbers plunged, it would wreak havoc on an already stressed agricultural system. There's a good chance you would see significant famine and death.
Slashdot Mirror
It is a lot easier if you make it a per-team plan rather than a per-employee plan. Hire people into specific parts of the company with the understanding that those entire teams will work the alternative schedule. If someone wants to work a normal schedule, put that person on a different team that works a normal schedule.
Sounds like they were ahead of their time. That must have been more than seven years ago.
California employment law changed in 2009 to explicitly allow what they call an "alternative workweek schedule" (Title 8, Section 11170, part 5). That allows employees to work up to 10 hours per day without overtime as long as your total hours don't exceed 40 per week and as long as it doesn't result in any shifts less than four hours long.
There are specific rules and exceptions, of course:
But otherwise, what you described is perfectly fine in California now, unless I'm missing something.
I find it odd that they specify which days have core hours. I mean, an ideal 30-hour week for a lot of folks would be Monday-Tuesday and Thursday-Friday so that they can have a break in the middle of the week. Or Tuesday through Friday, shifting Monday holidays to Tuesday. Or not having to work on the day when their kids have baseball/soccer/* games after school. It would make a lot more sense to say that you have to be there for those core hours on four days, without specifying which. It is not as though they're going to make use of the space on Friday, Saturday, and Sunday anyway.
For that matter, I find it really weird that they would choose 30 hours and not 24. If they hired people for 24-hour weeks (3 days), then they could have one shift from Monday through Wednesday and a second shift from Thursday through Saturday (or alternating days if folks preferred that). That would mean that their facilities cost for the second set of employees would be almost zero (maintenance and power only), and those savings would probably make up for the extra benefits. So they would be able to increase their output by 20% by increasing their costs by about 20%, all while employing twice as many people and giving employees the shorter work weeks that many of them would prefer, rather than decreasing their output by 20% by decreasing their costs by much less than 20%.
But maybe I've thought way too much about how to make part-time employment work at a tech company.
My first machine had 16 kilobytes, so I feel your pain. :-)
With that said, there's a huge difference between the space requirements for hand-rolled assembly code running on an 8-bit CPU and software that sits atop a modern monolithic kernel and glibc on a 32-bit (or worse, 64-bit) CPU. :-) Just saying.
I stand corrected. People are finding ways to do things in ridiculously small amounts of disk space.
Still, the small one doesn't really give the Pi a run for its money, which was the reason for my initial comment. After all, most folks stick a large SD card in the Pi for development, and scale back for deployment. And even then, they don't typically scale back to megabytes of storage, if only because it is basically impossible to find new stock of flash cards under about 8 GB these days. So any Pi setup you could come up with would wipe the floor with either of these RAM-wise and CPU speed-wise, and would wipe the floor with the smaller one storage-wise, too.
It is slightly smaller and has Wi-Fi, of course, so for some purposes, it might be interesting. Still, unless space is really that critical, I'd much rather use a Pi with a cheap USB Wi-Fi nub (assuming the Pi Zero doesn't have broken USB power supply limits like the original Pi).
I hope they plan to put in a connector for an external Wi-Fi antenna. No antenna that you could fit into something the size of a cherry is likely to be decent. Not to mention that anything you put the device into is going to reduce your signal strength.
Beyond that, my main concern would be the lack of flash storage. I used to build ramdisks for MkLinux, and you couldn't even fit a kernel with the RedHat installer into 16 MB. And that was fifteen years ago. I'd be surprised if a kernel with a full driver stack would even fit by itself into 16 MB of flash.... And I didn't even know you could still get flash parts that small. Is that supposed to be 16 GB, by some chance?
I've pretty much concluded that all the PHP-based bulletin boards are a security nightmare. Even the ones that are small enough to audit tend to be filled with old-style mysql_query calls and other horrors of the past.
The best thing about PHP 7, in my view, is that they're finally killing the old MySQL API. They should have done that years ago. Now, you'll be able to tell which software is reasonably up-to-date based on whether it supports PHP 7 or not. Incidentally, vBulletin's website says that it still doesn't. That's probably not a good sign. :-)
A strong passcode protects an iPhone just fine, too, AFAIK. A four-digit numerical passcode does not, and would not protect a computer, either. If anything, it would protect a typical computer far less, because it is far easier to interpose a disk emulator (passing reads through, storing writes to a separate device) on the SATA bus between a computer and its drive than between a CPU and flash parts that are soldered onto the logic board.
All encryption is breakable if you can get to the keys, and the compromises basically amount to being able to get to the keys and brute-force the passcode for the keys. That's not really an unreasonable design when you consider how few attackers would have the resources to even do that much. The fact that they've hardened it further is a good thing, of course.
If by proper encryption key handling, you mean a dedicated crypto processor with its own isolated storage and no way to extract the keys from it, then yes. However, that's several orders of magnitude more hardened than you would typically expect for encryption key handling outside of major CAs. It certainly isn't typical of... well, anything, really.
And besides, I'm talking about tunnels that are just big enough for a small robot to crawl through and pull wires, not big enough for a person to walk through. The smaller the tube (and the smaller the entrances to it), the easier it is to seal the access ports enough to keep it reasonably dry.
Also, those cables are designed to go underground, so being in water shouldn't cause problems anyway. And if water does cause problems, that likely means that mice have eaten the jacket, which can happen underground just as easily. But because it is in a tube, it is much easier to fix. You just pull a new wire, reconnect each circuit at both ends, then pull the defective wire out.
I wasn't factoring in water and sewer. Those don't get upgraded that often, typically, and although repairs to pipes certainly suck, they usually aren't frequent, either. But wire infrastructure has to be updated to new tech every few years, whether you're replacing bad phone bundles or failing coax or fiber bundles that have gotten eaten by a mouse or pulling additional fibers to increase capacity or whatever.
When you need to upgrade the wire infrastructure, it is really handy to be able to pull new cables through tubes with a robot or fish tape or any number of other tools, and you don't actually need to get people down into the tubes at all. It is certainly easier than digging up the street. And that also makes it much more trivial for new ISPs to add their cables alongside existing services (within reason).
But yeah, if your city has the money to put in proper sewer tunnels, go for it. :-)
A trunk-deck-height pod sticking out two or three feet from the back of the vehicle? It will add a bit of drag, but I think you're grossly overestimating how much. After all, the trailer would basically be in your slipstream.
And the rolling resistance is almost proportional to the weight, as I understand it. Spreading the same weight across more wheels makes only a small difference in the overall rolling resistance because you end up with proportionally less tire surface touching the road on each tire.
This means that assuming you keep all the other factors equal, putting the engine in a trailer should have almost no impact. Any apparent savings comes mainly from having less battery capacity in the hybrid (and thus less original vehicle weight before you add the engine), rather than from having the engine inside the vehicle instead of bolted on externally.
You won't. And that will cause a small efficiency loss while cruising at fast speeds. But those single-digit percentage differences in efficiency don't actually matter if you're only using it for a couple of days out of the year, because that's less than the savings most people would get from being able to use grid power for all but your longest trips. On the average, even if it costs 5x as much for those three days, you're probably ahead. For my driving patterns, I'd be ahead even if it cost me 10x as much.
But obviously, different people have different driving patterns, and some people will benefit more or less from those various tradeoffs. This why options are good. And for people who benefit significantly from an EV over a hybrid, there's nothing fundamentally preventing the manufacture of rentable range extender trailers for the EVs. When you add up the numbers, lots of folks will still be way ahead with that approach.
If the generator is optimized to produce power at the standard voltages for charging cars, it would be approximately as efficient as existing hybrids, except for the extra wind resistance and rolling resistance involved. For something that you use less than 1% of the time, that's a big win, statistically, and if you have an EV with 300-mile range (or even 150-mile range), nearly every driver will use it less than 1% of the time.
Divide by two, subtract 20% for when the battery is ten years old and has less capacity than it did originally, and this really means that the hybrid will end up using fuel if you live more than about 20 miles from work. And the biggest problem is when you're traveling for any sort of recreation, where you aren't going to be parked for several hours to fully charge a battery. In those situations, a Tesla with 300-mile range works fine, and a Chevy will be using gasoline.
And in the grand scheme of things, we really should move away from ICE-based cars for air quality reasons.
No, not really. A "range extender engine" (i.e. hybrid) is the worst of both worlds. With that design, you have:
The result is that the car in your link can only go a paltry 53 miles on battery. Most days, that's barely half my daily commute. So I'd be running on gasoline about half the time, which would mean I couldn't just charge overnight and avoid stopping for fuel. That basically eliminates the main benefit of an EV, all for the benefit of range that I would use maybe once a year at most.
If, instead, I could just rent a drop-on generator trailer, those headaches and maintenance burdens would be factored into the rental cost, and would be somebody else's problem. And because those costs would be spread out across lots of different renters, the cost to each person would be much lower even after factoring in corporate profits by the rental company.
Perl doesn't typically involve less code compared with using similar techniques in another language languages. Overuse of regular expressions can lead to less code that's less maintainable, but that's the exception that proves the rule. And really, the only thing Perl does differently from other languages is to hide the tens of thousands of lines of regular expression parsing and interpreting code that are needed to make them useful. The code is still there, making the software utterly huge when you look at the complete picture.
That's actually really easy to solve, at least in principle. It involves a gasoline-powered generator with a moderately large gas tank on a small, rolling trailer that hooks over your car's trunk or to a trailer hitch or whatever. In an ideal world, if every car company took electric cars seriously, you'd be able to rent a standard generator trailer at Home Depot or Wal-Mart or whatever for the weekend, and every car would have a 220VAC charge cord hidden in the trunk specifically for that purpose.
I agree with everything on your list except continuous integration. What makes CI a nightmare is that so many CI systems basically eat themselves from the inside out, randomly, causing everything to stop while somebody wastes half a day to debug the CI system. But when it works, CI is a godsend. It makes it easy to know exactly when things started to fail (tests, building, etc.), which makes it much easier to pin down the causes for some types of problems. (Obviously for building, this is trivial, but for test failures, it isn't, necessarily.)
Likewise. OOP is an interesting design pattern, but not when taken to the extreme. Far too often, people use inheritance where an "if" statement in a couple of methods and an initialization-time flag would have sufficed, and the result is invariably unholy.
I don't agree, however, that functional programming is an improvement. Functional programming is a migraine. In my experience, it usually causes things that are relatively trivial in procedural programming to turn into mounds of code. Everything that's bad about OOP is also bad about FP, just in different ways.
The goal should always be to produce less code, to the maximum extent possible, and both of these paradigms tend to do the opposite—particularly in the hands of beginners, but not exclusively so.
No matter what you do, there will always be outliers on one side, the other, or both—situations you couldn't predict that result in something being uncrackable when it should be crackable or vice versa. What I think most users want is the ability to choose one way or the other without having seemingly minor decisions come back to bite them in the backside (e.g. turning on two-factor only to find out that doing so unexpectedly prevents certain types of password resets).
What this means is that every behavior that has recoverability impact needs to be explained clearly to the user, and where possible, there should be no interdependencies between these settings. This also means that there should be a mechanism for people to add third-party trust into the system. For example, a kid should be allowed to add trust to his/her parents' account, allowing anyone with access to their account to gain the ability to request a device-present password reset in some way. This should be enabled by default on phones owned by kids, and parental controls should prevent it from being removed until the kid turns 18.
The problem is, those sorts of features don't sell devices. They aren't glamorous features that everybody wants to work on. They're additional effort that, unless mandated by law, probably won't ever happen. And if we start allowing lawmakers to meddle in crypto, there's a nonzero risk that they'll want to be implicitly added to that trust in some nefarious way unless the design deliberately makes it impossible for that to happen. This, in turn, means that adding those features is particularly challenging, making them even less likely to be implemented.
To be fair, the iPhone in question lacked the secure enclave. The techniques to crack into it would not work with newer hardware. It is still an open question whether other techniques could compromise current hardware—though to be fair, that is always the case with new technology up until the point when somebody comes up with a way to break it, so I guess that isn't really saying anything. :-)
Statistically speaking, the best approach for consumers is when the government owns a nonprofit corporation and allows that nonprofit corporation to manage the infrastructure. Example: TVA. This approach takes profit out of the picture and makes it a zero-sum game, while not allowing needed work to get tied up by government bureaucrats who think they need to stick their finger into every pie.
Wise municipalities would add a 4-square-foot prefab box tunnel with ports every couple of hundred feet so that whatever needs to be run in the future can be run without digging up the streets.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
If one gives me six lines written by the hand of the most honest of men, I will find something there to hang him.
—Cardinal Richelieu
I never said extinction. I said dramatic population reduction. The previous eruptions didn't occur in a society where 7 billion people were consuming approximately as much food as we are capable of producing technologically.
The ash cloud from a Yellowstone eruption would be expected to blanket most of the U.S. In affected areas, crop yield could fall to near zero overnight, and farmers would end up starting over. Given that the U.S. produces over 40% of the world's soybeans and corn, and 13% of the world's wheat, if those three numbers plunged, it would wreak havoc on an already stressed agricultural system. There's a good chance you would see significant famine and death.
Was that before or after California's plastic bag ban caused a whopping 46% increase in deaths from foodborne illness? Why in the world would anyone sane use a reusable canvas bag for carrying food? Ridiculous.