Unified theories are more attractive, but every new way of looking at physics (that accurately models reality) is one more potential avenue of insight into the fundamental nature of our universe. This is definitely an exciting discovery, though I do not share their enthusiasm for boiling all of reality down to particle interactions with geometry, rather than statistics.

The Copenhagen interpretation of QM is a disgrace, and any self-respecting scientist should be ashamed to support a theory that hides reality behind a veil of statistics, and uses that as an excuse to cease the pursuit of truth. As useful as QM is for calculations, mainstream physics has been stuck in a rut ever since, with the persisting complacent acceptance of enshrined theory. The same applies to nonsense like BCS theory, even though it isn't nearly as useful as QM.

There is no solid basis for the existence of particles in the first place, much less that the universe is fundamentally statistical in nature. Hopefully, simplifying our understanding of "particle" interactions will help illuminate a world without particles and rubbish like wave-particle duality. It seems a far more rational conclusion that that the wave and quantum nature observed emerge from a reality with a fundamental wave nature, rather than the spectacular contortions necessary with particles.

Wandering a but further off topic, Dr. Johan Prins also developed a very compelling and useful model of superconductivity, which is based on a wave nature of electrons. It dispenses with non-locality, and replaces it with unified waves. Boson "particles" no longer merely share the same energy state, they may merge into a unified wave, or split into quantum--as defined by boundary conditions. (shared electrons in orbitals, photons in lasers, BEC condensates, neutron stars, etc. would follow the same logic; waves constrained by boundary conditions.) It is both predictive and supported by evidence, yet sadly, no one has attempted to verify the results or even consider the theory as far as I know. Apparently, you must not stray too from the accepted dogma, even while other evidence mounts and the prevailing theory continues to fail. More epicycles and such...

There are no satisfactory workarounds, and never will be. The crypto needs to be handled within ZFS or it becomes an over complicated and inefficient mess. (As you are probably aware.) Consider a ZFS mirror on top of two disks encrypted by the OS; even though the data is identical, it now needs to be encrypted twice on write, and decrypted twice on scrub. For ditto blocks, multiply the amount of crypto work by another two or three. There are now (at least) two keys to manage and still no fine granularity access. Adding more vdevs to the pool only exacerbates the problem.

Copy on write transaction oriented filesystems like like ZFS are the natural place for crypto, as constructing a nonce is trivial; simply append the transaction ID, block offset, etc. It couples perfectly with stream ciphers like Salsa20 (or XSalsa20 for the extended 24-byte nonce), and offers the possibility of extremely fast, flexible, and efficient crypto. There is no expensive key setup required and no need to generate ESSIVs. No need to use expensive crypto modes on top of conventional block ciphers, which require multiple encryptions or other expensive operations like GCM. Furthermore, Salsa20/ChaCha is not only highly secure and trustworthy, but extremely fast, simple, and elegant.

After all of the work of hammering a square peg into a round hole with conventional full disk encryption, performance of Salsa20 in ZFS/HAMMER/btrfs would rival hardware accelerated block device crypto and be useful on a far greater array of hardware. (Typically it should even surpass it, as redundant crypto operations are eliminated.)

There is ongoing work on ZFS crypto at https://github.com/zfsrogue/zfs-crypto, though I'm not sure how it is progressing. Having zfs-crypto integrated would be very useful, not only for efficiency reasons, but for the simple and flexible key management. While there are alternatives to a number of other features that ZFS offers, none of them come close to offering the flexibility and convenience of ZFS.

It is worth mentioning that this issue is exclusive to solid fuel reactors. With fluid fuel, the problematic gasses just bubble out, and require no special attention. There are no safety issues with rapidly cycling a LFTR or other molten salt reactor. In practice, they will only be limited by how fast the turbine can spin up and down, and the reaction will follow suit.

I think you are somewhat unfairly overlooking kerberos authenticated NFS, and that is the only sensible way to use it. Better yet, with encryption and integrity protection as well.

Yes, selling something you can't provide is asking for trouble. If many people are saturating gigabit links 24/7, the pricing needs to allow for that. However, transfer caps and violations of net neutrality are not the answer.

The best solution is to advertise honestly, and the FCC should enforce this. Connections should be sold by minimum guaranteed rate, and maximum burst rate, with all else neutral. If there is any prioritization, it should only be among a customers own packets, at their request. This is easily done with guaranteed bandwidth available, and without any violation of network neutrality or impact on other users.

Selling by guaranteed rate has the advantage that there is a hard relationship between what is offered and what is purchased. If customers purchase more, the ISP must build more--rather than arbitrarily oversubscribing their networks. This incentive to invest in infrastructure is completely missing today. Since most people won't be using 100% of their allotted bandwidth, the excess can be divided fairly.

This would work great for google, offering something like 50Mb/s guaranteed and 1Gb/s burst. The minimum guaranteed bandwidth that cable and phone companies can provide would certainly look pitiful by comparison, but would be an honest reflection of what they can actually provide, rather than the meaningless "up to" numbers.

Unfortunately, it seems that JVM based languages are still limited by the lack of unsigned types. What a remarkably stupid decision to omit them.

Contrary to what you might think, carbon is actually safer at those temperatures. Under neutron bombardment at low temperatures, the Wigner energy can build up, and that is the source of the problems. However, at the operating temperatures of molten salt reactors, solid graphite is quite safe. (You can purchase graphite crucibles good to 2500C.) There is further discussion here.

The ultimate goal of our endeavors should be to produce wealth for human beings, not mindless jobs, nor backbreaking labor. If tedious and burdensome tasks like agriculture, manufacturing, and mining can be done by machines, all the better. That should free up people to do other things, including not slaving away for 40-60 hours a week. Increases in productivity are always a good thing--the problem is in the distribution of wealth, or rather the utter lack thereof nowadays. As jobs inevitably evaporate, we need to find new and better ways of doing this.

One particular area of productivity deserves special mention. Virtually all of wealth is derived from energy, yet energy has no intrinsic value. It is purely an input, so energy generation should be done as cheaply and efficiently as possible, as it compounds the cost of everything else. It is asinine to make it into a jobs program, yet that is exactly what Obama has done with his recent proposal.

You mean Xenon poisoning? That problem doesn't exist in an MSR, as it bubbles out and doesn't build up. Just one of many ways in which MSRs are inherently superior.

Pebbles still trap volatile fission products and poisons, and could pose a problem if damaged. Moreover, they magnify the waste stream with graphite, and make reprocessing virtually impossible. As with other solid fuels, they can not be burned completely, and require long term isolation. Of course, they also require an expensive fabrication process up front as well. All considered, I'm not sure why so many people find them attractive, when fluid fuels are so clearly superior.

Aside from the apocalypse, that is one of the things I worry about. Shills are bad enough today, but imagine if they could be deployed programmatically; just about any form of online speech could be drowned out with ease. That is assuming that the government/corporations aren't already using AI to accomplice pervasive censorship.

Before this gets out of hand, we need to head it off by deploying peer to peer communications systems with a pervasive trust model. This doesn't necessarily preclude anonymity or AI participation, but they would have a significantly more difficult time of gaining trust in the first place.

I think the 40% slower than vp8 was for playback. However, encoding speed also has to be reasonable, or there will be no content. With youtube, google may have a good head start if they succeed in getting others on board.

Of course, but if the presented videos are any indication, it looks quite good. It doesn't have to be perfect. As long as it is significantly better than h.264 and close to h.265, it should find widespread use. Opus is also an excellent audio codec with very low latency, which will make this a good option for real time communications.

Once the bitstream is frozen and the codec is open, you are free to use it as you like. The code is already available under a BSD-style license, though I do expect that a formal standard will be forthcoming. The availability of hardware should also provide incentive not to break compatibility in future versions.

I don't see how having the MPEG LA in control of any standard is a better option. The primary difference is that developers are free to incorporate this into applications without the trouble and cost of licensing. That directly benefits users, so perhaps you should care about royaltys and patents. The x.264 project is great, but it is limited in that respect.

From the q&a afterward, it is mentioned that average vp9 quality is within 1% of h.265, but it didn't sound like h.265 was anywhere near ready to roll out, with the only available option being a horrifically slow reference encoder. As for speed, they claim it is about 40% slower than vp8, which is twice as fast as h.264. As such, vp9 should handily outperform h.264 in software.

The open source and royalty free vp9/opus combination sounds like an very compelling option for the html5 video tag, and may become a de facto standard before h.265 is widely deployed. Hardware support for vp9 is also in the works, so if the codec lives up to the claims, there no longer appears to be any good reason to put up with the MPEG LA.

One of the best ways you can help the compiler folk is with an orthogonal and sensible architecture. Furthermore, consider that generating good code is a problem that must be solved for every language, so starting with a good ISA makes for a lot less work.

The ZFS code is actually very readable and well organized. The choice of an alternate layering model is logical and useful. That said, I would not be surprised if the NTFS source is truly a horror to behold.