Excellent book. I also recommend his recent "Legal Systems Very Different From Ours". It really makes you wonder to what extent our law may be in a local minimum.
Skimming the book there are number of issues which stand out.
With regards to 'selling the schools', in many places the charter school money just goes to tax exempt private landlords the charter school is leasing the building from without any substantial increase in benefits for students.
The section on taxes ignores state and local property tax and portfolio effect caused by deductions and expenses in federal income tax.
The chapter on money seems bad. Money is credit not a commodity. The simplest way to create money is through an equity loan not issuing gold certificates for gold bars. When someone wishes to take out a loan in 1M new-dollars on security of an estate worth 1M USD, the new dollars are a new unit of currency initially issued at a 1:1 ratio to USD which then floats.
The U.S. colonies did not originally have any gold. Issuing public money on security of estates allowed the colonies to provide a medium exchange for farmers without precious metals, raise revenue from interest payments without taxes, and economically develop despite mercantilist policies by Great Britain. During revolutionary war and war of 1812 the U.S. printed money and treasury notes to pay for existentially necessary expenses because taking out large loans in external currency which could not be paid off within 20 years or inflated was considered unethical to future generations.
Gold standard has caused lots of problems historically. Just going back to gold standard and depending upon private banks for money is not really solution. If a country does not have gold and residents are not allowed to domestically provide money as a public utility, on ideological grounds that anything 'public' is bad, this could prevent a country from developing if foreign lenders decide they can gain more through usury than by financing productive development, and could also prevent a country from financing defensive war during invasion.
> On Linux, the answer is pretty obviously no. Linux file descriptors are stored in an array of structs that has its capacity bounded to INT_MAX, so any negative int would either be considered nonsense (if treated as negative) or be higher than INT_MAX (if it was bit-reinterpreted as an unsigned value).
> The Single UNIX Specification explicitly says that open can't return a negative file descriptor, and says in the page for dup2 that you should get EBADF if you try to claim a negative file descriptor.
> Unfortunately, their description of file descriptor allocation never explicitly says that the negative range is out of bounds, but open references this algorithm while simultaneously claiming that it never gives a negative result.
> Also, Wikipedia says it can't be negative, but they don't give a source on that particular claim (urgh!).
-1 was picked as a conservative choice that's enough for the common case of Option.
Very interesting video of Brian Beckman talking through some of the differences between airplane simulators and racing (car) simulators and why tires are harder:
Flying cars are interesting because they have the potential to partially make obsolete the natural monopoly of roads. Governments are heavily involved in natural monopolies (possibly for good reason) but I worry that that involvement may crowd out innovative private organizations that would otherwise have the incentive to bypass the natural monopoly. I wonder what other innovations are being stifled in the same way.
As far as flying cars go, they sure are loud. But cars are fairly noisy as well -- in cities the roads are often very close to apartment buildings.
You run into the natural monopoly of airspace instead.
There's more room up there, but owners of the land beneath and users of other aircraft alike have a vested interest in the skies not being a free-for-all, and sure enough it's government agencies stepping into the air traffic control and regulation breach.
Natural monopolies are physical monopolies. There's literally only so much room on the Earth's surface. So to the extent that anything is being stifled here, it's because two objects can't occupy the same space at once, not because governments have anything to do with it.
And the challenges airplanes face are very physical as well. It's not really the government's fault if no one proves ever capable of making flying cars safe enough for the airspace above cities to be full of them. At some point it's just an intractable engineering challenge and the limits of human ability.
Personally, I'm doubtful that flying cars will ever be a reality in our lifetime, but the only possible way I envision them ever working is if they're 100% autonomous and owned and operated as a fleet.
> But cars are fairly noisy as well -- in cities the roads are often very close to apartment buildings.
And that’s an actual issue that should be addressed (electric cars are awesome on this point, you also have different road material that can absorb more sound).
Adding more noisy vehicles is making the situation worse.
GPS and LEO satellite internet are very different. GPS is meant to be received by near-omnidirectional antennas anywhere on the planet. Starlink satellites will place multiple spot-beams acting as cells and customer receivers are high directional as well.
Jamming Starlink would require satellite tracking and high gain antennas. And you would have to have separate jammers for each spotbeam that the starlink satellite casts on the ground.
If we held satellite operators liable for damages from collisions, they may be incentivized to acquire insurance against collision events. And underwriters would incentivize satellite operators to reduce that risk by giving lower premiums to operators that use collision avoidance systems like drag sails and/or propulsion.
Similar to safety with fission energy, this is not something where you want to apply financial incentives, because you don't want companies to take that risk ever. People may say: "If it goes wrong, I guess my company goes bankrupt. But it's unlikely enough that'd I'd take that risk." - like they're gambling at a stock exchange or something.
If anything ever goes wrong and something like the Kessler syndrome occurs, humanity will be so monumentally screwed you'll have trouble putting a dollar amount on the amount of damage done. No amount of insurance is going to make it right. It will be a large setback for humanity as a whole.
What you want to do is: Have companies follow the precautions you dictate and ensure compliance before they're allowed to launch.
"UL standards for satellites" sounds like a pretty presumable scenario. Extrapolating how the UL standards are currently used in the industry, private space corporations may even refuse to launch the satellite, provide or accept services if it's not certified.
The trick of switching the implementation of owning_ptr and constraint_ptr based on a compile flag is very neat.
Is there any risk of the compile flag influencing which object owns the reference, and therefore causing a kind of "heisenbug" where it doesn't crash during the safe mode but still has dangling pointers in the fast mode?
Thanks! We stand on the shoulders of giants, this method has been in use in the wild for a while, and Gel introduced it back in 2007.
Behavior will be the same in all three modes. There is however a chance that testing and development didn't cover a certain code path, and we would trigger unsafety in production, similar to unsafe blocks in Rust. When one encounters unsafety in Vale, they'll be able to just re-run in normal mode to instantly identify what caused it.
Normal Mode is very conservative (halts early when a constraint ref becomes dangling, rather than when it's dereferenced), so combined with test coverage, it can give high confidence in safety, and is strictly better than even C++ and ASan.
If that's not enough, Resilient Mode has zero unsafety, and with the optimizations we'll be using (nonatomic RC, Lobster's algorithm, immutable region borrowing, bump calling, etc) should be incredibly fast in practice, possibly on par with Rust and C++, and exceeding them in certain cases, with bump calling.
