morning_gelato

Here is a white paper released by Fervo that describes what they've done in more detail: https://eartharxiv.org/repository/view/5704/

I think carbon-intensity (gCO2eq/kWh) is a much more important metric than the use of specific generating technologies. Looking at the data [1], Germany has one of the dirtiest electrical grids in western Europe.

[1] https://app.electricitymaps.com/zone/DE

> Synthesizing h2 from methane is also done by electrolysis

Most hydrogen is currently synthesized from steam reforming of methane [1], not electrolysis.

[1] https://www.energy.gov/eere/fuelcells/hydrogen-production-na...

>This shows that Nuclear power might actually be a hindrance towards an electrified future, as governments have historically put to much faith in it, which was ultimately unwarranted, instead of investing in renewables.

Historically the countries that invested in nuclear and hydro have been most successful in lowering the carbon intensity of their energy sector. Looking at the data, Germany does not appear to be nearly as successful as France. In 2021 France's electricity averaged 68 gCO2/kWh, and Germany averaged 364 gCO2/kWh.

https://ourworldindata.org/grapher/low-carbon-share-energy?t...

https://ourworldindata.org/grapher/carbon-intensity-electric...

Yes, for example Switzerland uses two of their nuclear power plants for district heating [1][2]. China has also started using it for district heating in Haiyang [3].

[1] https://en.wikipedia.org/wiki/Beznau_Nuclear_Power_Plant#Ref...

[2] https://www.world-nuclear.org/information-library/country-pr...

[3] https://www.nucnet.org/news/city-of-haiyang-first-in-country...

> Nuclear power plants are not "carbon free." They have significant operational needs (indirect emissions), making them of the most expensive sources of electricity available today, and by some estimates their indirect carbon footprint is enormous

The United Nations Economic Commission For Europe released a report in 2021 on the life cycle emissions (including construction, operation, and decommissioning) of various power generation options and found nuclear to be the lowest overall at 5.5 gCO2eq/kWh [1].

[1] https://unece.org/sites/default/files/2021-10/LCA-2.pdf

> Demand is usually the highest when PV output is also the highest

Not quite, the mismatch in timing between solar generation and energy demand has been called the "duck curve" [1][2]. Peak demand is normally in the evening when people are done with work [3].

[1] https://www.energy.gov/eere/articles/confronting-duck-curve-...

[2] https://en.wikipedia.org/wiki/Duck_curve

[3] https://www.eia.gov/todayinenergy/detail.php?id=42915

Current geothermal technology requires very favorable geological conditions which significantly limits where it can be deployed. If EGS turns out to be both safe and viable it will mean that geothermal power plants can be widely deployed across the globe. I believe this research is also in the public interest as we want clean highly-reliable power, and EGS is one of the few technologies that can potentially provide that.

There's no evidence that they are being used to breed plutonium. In fact the BN-800 burns a mixture of uranium and plutonium to reduce their weapons stockpile.

> the economics for fast reactors have never worked (not even in Russia or China)

Russia currently has two sodium-cooled fast reactors that are producing power, the BN-600 and BN-800. They also have another sodium reactor under development, the BN-1200. BREST-OD-300, a lead-cooled fast reactor, is under construction as well.

From what I've read[1] it looks like we should be able to use nuclear fission for a significant amount of time (>1000 years). This would involve using uranium and thorium as well as breeder reactors.

[1] https://whatisnuclear.com/blog/2020-10-28-nuclear-energy-is-...

Realtek does contribute directly to the kernel, but I think it depends on which internal team is handling the device support. For their PCIe 802.11ac and 802.11ax wifi cards Realtek devs wrote and upstreamed rtw88[1] and rtw89[2] respectively.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

It does not appear that this particular electricity shortage is caused by moving away from fossil fuels. The coal plant shutdowns mentioned in the article were outages (2 unplanned and 1 planned) [1] rather than permanent closures due to an energy transition.

[1] https://www.nasdaq.com/articles/kazakhstan-rations-power-aft...

I think Dell and HP offer somewhat comparable sites.

Dell: https://www.dell.com/en-us/shop/partsforyourdell/index HP: https://partsurfer.hp.com/search.aspx

Why did you omit the response you received from a netty developer that showed a large performance improvement[1]? Focusing entirely on the few cases where people report regressions and ignoring all of the reports of improvements isn't a good way to make an objective assessment.

[1] https://github.com/netty/netty/issues/10622#issuecomment-701...

I think we are in agreement. I was responding to the comment that stated "BTRFS delivers „classic“ RAID1 and more/better.", which is what I am disagreeing with. Requiring that mount options be changed whenever there is a drive failure (despite having sufficient redundancy) is definitely an anti-feature in my book.

I would argue btrfs does not deliver "classic" RAID1. Last I checked if you lose 1 disk in a 2 disk btrfs RAID1 setup and then reboot, it will be unable to mount the filesystem until you change the mount options so that it is set to 'degraded' mode. This is very different from other RAID1 setups (e.g. hardware raid controllers, mdadm, openzfs), and a big problem if you don't have lights out management or fast physical access to the machine.

How could someone demonstrate the safety of these systems if their very association with those systems is a sufficient reason for you to doubt them? If the research and experiments of nuclear engineers, scientists, and regulators from around the world cannot be trusted to develop or assess the safety of fission reactors, why does this change with fusion? I also have not seen evidence that anyone is attempting to suppress information about nuclear safety. Overall nuclear power has an outstanding safety record and ranks among the lowest deaths per TWh of any energy source (and this includes Chernobyl)[1][2].

For the record the HBO series on Chernobyl, while a good show, greatly exaggerated parts of the story. There was no threat of a megaton-level thermonuclear explosion that would destroy Kiev or make huge parts of Europe uninhabitable from the melted core coming in contact with water. The soviets did know about the RBMK's propensity to have a runaway reaction, and the rest of the world never allowed those types of reactors to be built.

[1] https://www.statista.com/statistics/494425/death-rate-worldw...

[2] https://ourworldindata.org/grapher/death-rates-from-energy-p...

With modern reactor designs the inherent safety mechanisms mean that humans are not in the loop to reduce reactivity or remove decay heat.

Here's an example from Argonne National Laboratory:

> In the first test, with the normal safety systems intentionally disabled and the reactor operating at full power, Planchon's team cut all electricity to the pumps that drive coolant through the core, the heart of the reactor where the nuclear chain reaction takes place. In the second test, they cut the power to the secondary coolant pump, so no heat was removed from the primary system.

"In both tests," Planchon says, "the temperature went up briefly, then the passive safety mechanisms kicked in, and it began to cool naturally. Within ten minutes, the temperature had stabilized near normal operating levels, and the reactor had shut itself down without intervention by human operators or emergency safety systems."

https://www.ne.anl.gov/About/hn/logos-winter02-psr.shtml

What's a scenario where passive safety systems, say those of a HTGR with TRISO fuel, fail and cause it to go prompt critical? I'm genuinely curious about this, as everything I've read suggests this is essentially impossible due to the design of the reactor, fuel, and coolant.

Why is the runaway scenario unavoidable for nuclear fission? Pressurized water reactors for example have negative void and temperature coefficients, and from what I've read about potential future reactors designs (e.g. high temperature gas reactors and some of the molten salt reactors) passive/inherent safety is a major selling point.

I thought it went: USB 3.0 (5Gbps) == USB 3.1 Gen 1 == USB 3.2 1x1, and USB 3.1 Gen 2 (10Gbps) == USB Gen 3.2 2x1.

Yet the article states:

>Accordingly "USB 3.1 Gen 2" became "USB 3.2 Gen 1x1" and "USB 3.1 Gen 1" was renamed "USB 3.2 Gen 2x1".

Either way, this article gets the point across that USB has turned into a complete mess.

Here's a post from one of the OSv developers on performance compared to Linux in 2020 [1]. It paints quite a different picture compared to those benchmarks from 2013.

>While ideally a unikernel like OSv could provide better performance than traditional kernels because of things like lower system call and context switch overhead, less locking, and other things, there are many things working against this ideal, and resulting in disappointing performance comparisons:

1. Most modern high-performance software has evolved on Linux, and evolved with its limitations in mind. So for example, if Linux's context switches are slow, application developers start writing software which lowers the number of context switches - even to the point of just one thread per core. If Linux's system calls are slow, application developers start to batch many operations in one system call, starting with epoll() some 20 years ago, and culminating with io_uring recently introduced to Linux. With these applications, it is pointless to speed up system calls or context switches, because these take a tiny percentage of the runtime.

2. They say a chain is as weak as its weakest link. This is even more true in many-core performance (due to Amdahl's law). Complex software uses many many OS features. If OSv speeds up context switches and system calls and networking (say) by 10%, but then some other thing the software does is 2 times slower than in Linux, it is very possible that OSv's overall performance will be lower than Linux. Unfortunately, this is exactly what we saw a few years ago when ScyllaDB (then "Cloudius Systems") was actively benchmarking and developing OSv: Many benchmarks we tried were initially slower in OSv than in Linux. When we profiled what happened, we discovered that although many things in OSv were better than Linux, one (or a few) specific things in OSv which were significantly efficient in OSv than in Linux. This could be some silly filesystem feature we never thought was very important but was very frequently used in this application, it could be that OSv's scheduler wasn't as clever as Linux's to handle this specific use case. It could be that some specific algorithm was lock-free in Linux but uses locks in OSv, so becomes increasingly worse on OSv with the more CPUs you have. The main point is that if an application uses 100 different OS features - Linux had hundreds of developers optimizing each of these 100 features for years. The handful OSv developers focused on specific features and made clever improvements to them - but the rest are probably less optimized than Linux.

3. Many-core development is hot When the OSv project started 7 years ago, it was already becoming clear that many-core machines were the future, but it wasn't as obvious as it is today. So OSv could get some early wins by developing some clever lock-reducing improvements to its networking stack and other places. But the Linux developers are not idiots, and spent the last 7 years improving Linux's scalability on many-core systems. And they went further than OSv ever got - they support NUMA configurations, multi-queue network cards, and a plethora of new ideas for improving scalability on many core systems. On modern many-core, multi-socket, multi-queue-network-card systems, there is a high chance that Linux will be faster than OSv.

4. Posix API is slow This is related to the first issue (of software having evolved on Linux), but this time for more "traditional" software and not really state-of-the-art applications using the latest fads like io_uring. This traditional software is using the Posix API - filesystem, networking, memory handling etc. that was designed decades ago, and make various problematic guarantees. Just as one example, the possibility to poll the same file descriptor from many threads requires a lock every time this file descriptor is used. This slows down both Linux and OSv, but not giving OSv any advantage over Linux, because both need to correctly support the same slow API. Or even the contrary - Linux and its hundreds of developers continue to come up with clever tricks for each of these details (e.g., use RCU instead of locks for file descriptors) while OSv's few (today, very few) developers only had time to optimize a few specific cases.

So it's no longer clear that if raw performance is your goal, OSv is the right direction. OSv can still be valuable for other reasons - smaller self-contained images, smaller code base, faster boot, etc. For raw performance, our company (ScyllaDB) went on a different direction: The Seastar library (http://nadav.harel.org.il/seastar/, https://github.com/scylladb/seastar) allows writing high-performance applications on regular Linux, by avoiding or minimizing all the features that makes Linux slow (like context switches) or cause scalability problems on modern many-core machines. Initially Seastar ran on both Linux and OSv (with identical performance, because it avoided the heavy parts of both), but unfortunately today it is using too many new Linux features which don't work on OSv - so it no longer runs on OSv.

[1] https://groups.google.com/g/osv-dev/c/0WveOhAsZEU/m/jqHyNs9l...

I was thinking of Copenhagen Atomics' Waste Burner design where they describe their passive walk-away safety features as "Prime minister safety" [1].

> The CA Waste Burner has a set of systems governed by the laws of physics that cannot be overruled by humans, and which will cause the reactor to shut down safely if something goes wrong...This means that operators are not required to watch for alarms and act in accordance. The CA Waste Burner must be able to automatically shut down before any human can react to an alarm and choose what to do. If human action were ever required for operation, other than during startup procedures, then we would consider it a design failure...

[1] https://doi.org/10.1016/B978-0-08-101126-3.00023-3

My understanding is that these reactors are designed to have a lot of passive safety features (e.g. if all operators walk away the reactor will cool itself and go sub-critical), so quite the opposite of what you are claiming.

Small nit but BBR stands for bottleneck bandwidth and round-trip propagation time [1].

[1] https://queue.acm.org/detail.cfm?id=3022184

VSI (now called VMS Software?) just uploaded a webinar talking about their roadmap for OpenVMS, including the new hobbyist program.

https://www.youtube.com/watch?v=4yYmHGp9Z3c

> The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.

The latter file systems were trying to be upstreamed and ultimately did not succeed, I don't know of any interest or attempts at upstreaming ZFS. Their handling of ZFS reminds me how they handle any kernel module that will never be upstream, not because some file system establishment sees it as a threat.

> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.

What/who is the "establishment (and their friends)"?

f2fs from Samsung was added in 3.8, erofs from Huawei was added in 5.4, and exfat from Samsung was added in 5.7. Before those file systems were upstreamed I don't think many people would list Samsung and Huawei as part of the filesystem "establishment".

I've already said that the OpenZFS community is not trying to upstream it, why do you keep thinking that I'm suggesting otherwise?

You continue to conflate support for out of tree kernel modules as being similar to having a separate repository for firmware when they aren't the same thing at all. The Linux developers are not accepting firmware into the kernel at all, so there is no contradiction. The firmware is kept separate, just like OpenZFS is kept as a separate project from Linux. In both instances the user can choose to install an out of tree module such as OpenZFS as well as choose to install firmware on their system.

Furthermore it is not the Linux kernel developers that are packaging and shipping the firmware, it is the various Linux distributions who do that (or not in the case of FSF-approved distributions).

Sure, but that's been Greg KH's stance on pretty much every kernel module that has no chance of going upstream [1].

"Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech)."

Also in the post you are citing, the technical change makes no reference to ZFS [2] or implies that the motivation is to break out of tree modules. The upstream community simply doesn't even consider out of tree projects when making changes. Whether that's good or bad is another discussion, but I don't see anything that's specific to ZFS.

I should also note that to my knowledge, OpenZFS (formerly ZoL) was the only (open source) ZFS implementation that utilized vectorized checksums. At the very least FreeBSD's in-tree ZFS did not have vectorized checksums, as that was listed as one of the features FreeBSD would gain by moving to OpenZFS [3]. So the cited change didn't break ZFS, it just meant those checksums weren't as fast as they used to be.

[1] https://www.kernel.org/doc/Documentation/process/stable-api-...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[3] https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...