jabl

Oh, absolutely. Music might be a shit career unless you happen to be in the top 0.01%, but it's a fantastic hobby. Being able to play or sing something yourself is immensely satisfying (maybe not so satisfying to your neighbors, but I digress).

I've been wondering if we're going to end up with some kind of backlash against all the autotuning, 'gridification' as this article explains, etc etc., and AI slop as well as deepfakes filling up the interwebs. You can't know what's real anymore. So people will start preferring live performances. Not only live music, but, say, theater/musicals/opera instead of going to the movies, and so forth?

Not saying this as some kind of general "anti-AI" argument or anything. I'm not advocating for the Butlerian Jihad. I find AI a very useful tool, and I used it at work pretty much every day. But for art, which in a sense is a celebration of human creativity, something gets lost if we use AI to generate it, doesn't it?

In defense of the analog simple life I suppose it's possible to be a hermit without sending out mail bombs to people you believe have not seen the light?

Capability-based security might be the bees knees, but how would one retrofit it into an existing kernel without breaking backwards compatibility?

COMMON, ENTRY, and EQUIVALENCE are certainly frowned upon in modern Fortran style, as the language has gotten less error prone ways of accomplishing the problems those features ostensibly solved. But they still exist in the language for backwards compatibility.

To this day some Fortran compilers put large local variables into static storage rather than the stack. Because many old Fortran programs were written with the assumption that all procedure variables were statically allocated, and thus having huge arrays as local variables wasn't an issue.

This kind of code then easily breaks by overflowing the stack if the compiler allocates them there.

But this then doesn't work that well if the procedure is called recursively, or concurrently from multiple threads.

Making this even worse, in a recent Fortran standard (2008?) this was reversed such that procedures must be explicitly marked with NON_RECURSIVE in order to allow the compiler to allocate variables statically. Undoubtedly the right decision given the increasing prevalence of threads as well as recursive algorithms, but a gotcha for compiling old dusty deck code.

I remember helping a research group port some old Fortran code they had to a more modern environment and compiler. Turning on array bounds checking made the program crash pretty quickly. "There can't be a problem with the code as we've published papers with it". Umm, sorry sunshine, that's not how it works.

Conveniently an article just dropped studying the effects of a new wealth tax in Norway. As usual with these sorts of taxes there were a lot of threats that all the high net worth individuals would emigrate to Switzerland or wherever. In reality, it turned out that threat was mostly hot air and bluster. (And of course, you can combine a wealth tax with some kind of exit tax for those that want to take their ball and go play somewhere else.)

https://www.nber.org/system/files/working_papers/w35854/w358...

But yes, you're certainly right that taxing unrealized gains is difficult for many types of wealth. But e.g. property taxes are often already based on some estimation of the market value of said property anyway, so no change there. And similarly publicly traded stocks and such have a clear market value. For other types of wealth, sure there are difficulties, but usually it's possible to do it in some way, be it by estimating the worth somehow or then delaying the tax until the thing is sold or the owner dies etc.

That is true, but on the other hand if you had to pay a hefty yearly property or wealth tax you might not be able to afford it in the sense that your wealth is bound up in the house.

The counter is of course that when you buy a house you should make sure you have enough income and/or liquid wealth so that you can pay the taxes. And if not, move to a smaller house. Of course, opponents of such taxation will then roll out all kinds of grannies living in mansions on meager pensions. Then again, is it fair that this prices out younger people from the property market?

As difficult as they are, I do think we'll need some form of wealth taxation in order to put a brake on spiraling inequality. Yes, call me a fan of Piketty if you want.

Nah, that is mostly about keeping the ordering in mind when iterating (e.g. do you iterate first over innermost or outermost index?). And there are algorithms such as (naive) matrix multiplication where the correct order for one matrix is the wrong for the other one, so plus ca change.

But speaking of arrays, one definitive advantage of Fortran is that it has built-in multidimensional arrays in the language. Which is very nice when writing code that needs them. In C many people resort to the Fischer-Price My First Multidimensional Array implementation where they allocate each row separately, which is of course horrible. (In C++ you can use libraries like Eigen or Armadillo which use expression templates and operator overloading to have sensible multidimensional array support even if it isn't built-in.)

There are several reasons why Fortran historically has been faster. Many of these are because Fortran is less strict about what the compiler can do so allows optimizations that wouldn't be allowed in C. Such as:

- Procedure arguments are not allowed to alias. Similar to restrict pointers in C99+. This is often critical to allow loops to be vectorized, but the onus is on the programmer to ensure no aliasing or else you get UB.

- Unspecified evaluation order for expressions. E.g. C requires that "a+b+c+d" be evaluated as "((a+b)+c)+d)" and with floating point it can't do it another way due to rounding. Fortran can do e.g. "(a+b) + (c+d)" where each subterm can be computed in parallel, but again at the cost of slightly different results due to rounding behavior for floats.

- Old school Fortran lacked pointers which led programmers to program algorithms using arrays rather than fancier data structures, which cpu's love.

In principle there's nothing preventing a competent C or C++ programmer can reach Fortran level performance. In practice, might be difficult.

Of course, nowadays performance is much about designing for cache hierarchies (see e.g. "Data Oriented Design") where Fortran doesn't have a built-in advantage.

The Royal Navy indeed won many battles "that mattered". Saying that Chesapeake is the only one is just ridiculously ahistorical.

Of course, I can't predict the future. So sure, if we in the future have some magical Star Trek technology that would make space travel entirely safe and ordinary, sure. Won't happen with anything like chemical fuels though, thanks to the tyranny of the rocket equation. And if we have such magical Star Trek technology, surely we'd also have the technology to transmute the waste into safer elements that don't present a long-term radiological hazard (that we in principle know how to do already today, it's just prohibitively expensive for little benefit)?

In the meantime, while waiting for the magical Star Trek future to arrive, I'd much prefer if we'd store the waste we have and continue to generate in a safe and responsible manner. Which, whether we do reprocessing or not, would involve deep geological disposal. If we later come up with a significantly better idea and for some reason have a motivation for doing something, sure, then we can dig it up again and shoot it into space, transmute it, or whatever the idea at that time is.

What I'm saying is that with anything like current day rocket technology, disposing of nuclear waste by shooting it into space is just a laughably insane idea.

Massively larger than the risk getting it from the storage pools to the space launch facility, to the extent it cancels out the definitely non-zero risk of the rocket launch failing?

This is getting very off topic, but this "let's dispose of nuclear waste by shooting it into space" is such an insane idea. In which universe is the risk associated with a frickin space launch lower than a deep underground geological repository?

Apart from the climate crisis, the other huge systemic environmental crisis hitting us is biodiversity and habitat loss. Which is largely driven by land use changes thanks to agriculture. Using large tracts of farmland to convert fuels, fertilizer etc. into biofuels at barely break-even in energy terms isn't defensible in cases where electrification is an alternative.

Bingo. There have been studies on the EROEI (Energy Return on Energy Invested) on corn ethanol, and while results vary somewhat, the consensus seems to be that while the EROEI is positive, it's barely so. Maybe around 1.2-1.5, I don't recall, been a while since I looked into it. That is, to get around 1.5 units of energy in the form of corn ethanol, you'll need 1 unit of energy embodied in fertilizer, diesel fuel for agricultural machinery, natural gas for the distillation etc.

For another approach that has actually been deployed at scale by OpenAI there's MRC:

Blog post: https://openai.com/index/mrc-supercomputer-networking/

Paper: https://cdn.openai.com/pdf/resilient-ai-supercomputer-networ...

Spec: https://www.opencompute.org/documents/ocp-mrc-1-0-pdf

MRC is an extension of RoCE that does out-of-order packet delivery, packet spraying across all available paths using SRv6 routing, combination of ECN and packet trimming for congestion control (so sender-based CC like TCP and unlike Homa).

Numerical Recipes in C is an existence proof of the adage that the determined FORTRAN programmer can write FORTRAN in any language.

(Using FORTRAN here rather than the more correct Fortran to denote the traditional pre-modern (Fortran 90+) programming style.)

What's not mentioned in the announcement (at least based on a quick skim) is that EDG the company is winding down, which is likely the reason why they're open sourcing the front end.

https://en.wikipedia.org/wiki/Edison_Design_Group ref 9: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

> And OTH if you only require 16 bits integer width, there's not much point in picking a 32 bit integer type.

Some common architectures like x86 can suffer from an issue called partial register stalls. So from a performance perspective choosing a 32 bit integer can be better.

The auditor probably doesn't know nor care. "Every windows machine runs antivirus" is a checkbox item, zero thought involved.

My argument was that while waiting for renewables to become cheap, we could have built nuclear instead of fossil capacity and avoided a shitton of emissions. The Messmer plan being an existence proof that such a thing would have been possible.

> We could have standardized the old reactors too.

Yes, but the potential market for GW-size reactors is fairly limited.

Now, whether the market for any of these SMR reactors is large enough that any of them will be able to see any of these supposed economies of scale is a big question.

People have been arguing nuclear is too expensive and soon renewables will be so cheap they will push fossil fuels out of the grid for 30 years, if not more. Meanwhile during those 30 years, while waiting for the price of renewables to drop sufficiently, the world has built massive amounts of fossil power generation and emissions have been going up and up.

That being said, it seems finally solar+wind+storage+a little bit of other stuff is becoming cheap enough that it's starting to make a dent in the emissions. Which is fantastic, don't get me wrong. But it's also sad we've lost decades.

I've been a Ubuntu user for about 20 years, and I file bugs every now and then on launchpad. I don't recall any of them ever being fixed.

Maybe the bugs get traction if you have a service contract?

Best to file bugs directly to upstream, but that of course means you should try it on the latest upstream version and not whatever version ubuntu ships, so it's more friction.

I don't see how installing underfloor heating in an existing house can make economic sense. Additionally in older houses the windows tend to be a bit leaky, so the radiators being under the windows is important to prevent unpleasant cold drafts.

Yes, the heat pump will take an efficiency hit for using radiators rather than underfloor heating. I'd say that's just part of the cost of living in an old house.

My father has a wood burning boiler connected to the same water circuit that heats the radiators as his air-water heat pump. Originally when the house was built it was a wood-oil combi boiler, later on the oil burner was ripped out and the heat pump installed (at that point there were government grants available for replacing oil heating with heat pumps).

It does work well, and when it gets cold in the winter and the efficiency of the heat pump drops, he burns wood. But honestly the system is a jungle of pipes and valves, and the guys who did the heat pump installation were unable to wrap their heads around it. Luckily my father is a handy guy so he was able to do it himself.

But I'm thinking if one were to do something like this from scratch, without the history of the existing boiler already being there and installed, I wouldn't bother with it. Just have a few good old school wood stoves with significant thermal mass (masonry heater or whatever you call them in the US) in the house that you can use to provide extra heat when it's cold, and as backup in case there's an electricity outage.

My father has a Mitsubishi air-water heat pump, generating hot water for the iron radiators in the house. Uses R32 refrigerant, not CO2 as in this article, but still. While efficiency is reduced by the need to have decently high temperatures in the radiators, it's still decent-ish. IIRC he still gets a COP of around 2-2.5 when it's -15C outside.

This is in Europe, might be different on the other side of the pond.

I believe there are propane using split AC systems where propane is used only in the outside unit. The outside unit has a heat exchanger transferring the heat to some glycol-water solution which is what then circulates through the inside unit.