Subscription only link.

Hmm, I don’t really think this counts as user space. This is a kernel configuration parameter. User facing for sure, so a bit of gray area perhaps.

Maintenance is not free? They still have to test it at the very least.

data=journal is just one mode of journaling. Not the entire feature.

Journaling all of the data is very expensive and slow and no one was using it.

Metadata journaling as always the main feature and is still present.

You weren’t using this. No one was. That’s why they are removing it.

On our own?

No, the journal is not deprecated. Only data journaling is.

Metadata is still journaled and is what most people have been using all this time.

They are not removing the journal.

The metadata journal is still there. Most people are not journaling their data, it’s too slow.

You’re supposed to (hate it).

I didn’t mean fixing them. Just categorizing them. Eliminating duplicates. Marking some as ‘won’t fix’, etc.

Who was saying it was otherwise? Containers are not virtualization and never have been.

Can you use an llm to triage the other llm’s bug reports? Fire with fire.

Qobuz told them that their api is private and only available to paying developers. I assume qobuz threatened legal action.

Then why did you post here if you’re not willing to discuss it here? It seems you just want everyone to agree with you. Sorry to disappoint.

I did read it. It’s not that long.

I still don’t know what problem you are trying to resolve that doesn’t already have one or more solutions.

You listed one issue, specific to gaming and cheating, that was simple human error and miscommunication that I don’t believe would be solved by what you are proposing.

What other examples do you have? You seem to be starting with an assumption that everyone knows and agrees what the problem is without truly stating it.

The Linux kernel, and most userspace libraries already have a contract to maintain backwards compatibility. Some developers may choose to ignore this or make mistakes and break this contract. Again I do not believe that adding some new compatibility layer will fix this.

I’m sorry, but your article seems very hand wavy to me and doesn’t have enough detail on how it would work. What you are proposing seems huge. I can’t imagine enough people buying in to the idea to get it off the ground.

You picked a particularly rare example. Meaning it was a combination of unexpected use case and 10+ years of deprecation happening to coincide at the wrong time and place.

Even if you had your supposed compatibility layer in place human error or misunderstanding is still going to cause issues like this from time to time.

The DT_HASH issue was specifically NOT an api breakage. It was some apps consuming some internals without keeping track of changes. Yes, they technically broke backwards compatibility. But those apps weren’t supposed to be using that field for a long time.

I think you’ve gotten a really bad read of my article. We know the typical Linux stack has problems with libraries failing to maintain backward compatibility

We do? I certainly don’t. Which libraries? That’s likely not a generic Linux issue. That’s more probably a specific issue with those specific libraries or distros.

I think you need to be much more specific if you think anything is going to come from this. I have no idea what recent issues you are referring to.

At least skip the Reddit link and post the source…

https://parallel-minds0.github.io/An-Open-Letter-on-Linux-Compatibility/

From a quick skim, I think the author doesn’t really know that much about how Linux and its various components and libraries actually work. Though it seems they are loosely proposing somebody new compatibility layer?

And what is this supposed NT compatibility promise?

The Linux kernel has maintained strict backwards compatibility at the user space level for ages.

Individual libraries are versioned and can be kept around for as long as anyone likes.

Package management and dependencies might be a bigger problem, but I would guess a manageable one?