Fixed

Isn't this what the european Cyber Resilience Act (CRA) is about? See https://orcwg.org/cra/ and the work of the Open Regulatory Compliance Working Group in general.

More or less, though the CRA is pretty minimal: it has a few basic requirements and hobby/unpaid open source software is not covered. A company integrating open source software is essentially responsible for covering those requirements themselves.

The company being responsible for the open source components they integrate should solve the biggest dependency problems, though. From a security perspective, it doesn't really matter if a company fixes the bugs themselves or if they pay someone to fix it for them.

https://git.tricoteuses.fr/tricoteuses/a_propos has the French constitution and others (e.g. "Code Pénal": https://git.tricoteuses.fr/codes/code_penal/commits/branch/m...) under git too. They have developed a custom tool to automate this: https://git.tricoteuses.fr/logiciels/tricoteuses-legifrance

This behavior is controled by the AUTO_CD option: https://zsh.sourceforge.io/Doc/Release/Options.html. To enable it yourself:

    setopt AUTO_CD

This sounds a lot like Shape Up from the guys at Basecamp: https://basecamp.com/shapeup

Yes: https://en.wikipedia.org/wiki/Finger_(protocol)

FWIW, LibreOffice automatically inserts an actual Unicode NO-BREAK SPACE when I type ":" at the end of a word (if the language is set for French of course). If I insert an actual SPACE and then hit ":", it even replaces the SPACE with a NO-BREAK SPACE.

I'd be surprised MS Word doesn't do the same. No need for a "true" typesetting solution.

I think the point of the GP is that it inserts NO-BREAK SPACE instead of a NARROW NO-BREAK SPACE. If that's the case, it's a bug.

Relevant: https://jakarta.ee/about/faq/#collapse-1

Yes apparently: https://lwn.net/Articles/901807/

This is not representattive of modern Java, which has much better APIs. Since Java 11:

  public HttpResponse<String> fetch(String url) {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest request = HttpRequest.newBuilder(URI.create(url)).build();
    return client.send(request, BodyHandlers.ofString());
  }

But of course, nobody uses the standard library since it came late to the game, and instead there are at least half a dozen popular HTTP libs commonly used (Apache, Jetty, Spring, OkHttp, Google, etc.). It's not too different from the logging clusterf*ck in Java, where there are now 9 ways to do it, and none of them are compatible with each other.

A few years back we used slf4j for compatibility between Java logging libraries. Have they managed to break it? Or are you after compatibility at a lower level?

Slf4j is definitely the way to go, but it is still VERY hard for typical enterprise devs to get it working correctly, which means that both your own code and then all the dependent libraries are all on the same page w/ regard to what level and format the logs are printed, and to where they're going.

The problem is that even if your own code uses SLF4j correctly as a logging API, and then wires up the correct logging implementation (e.g. Logback, Log4j2, etc), and then finally include the necessary SLF4j "bridge" libraries, you still need to ensure that every 3rd party transitive dependency explicitly excludes Commons Logging, Log4j, etc libraries.

It's a mess, and almost none of projects that I've worked on over the years got it 100% right the first time.

That being said, I see the exact same problem in a lot of the modern Python and Node code that's out there. It just becomes too complicated because there are too many logging options, and when a modern project - in any language - now relies on dozens of 3rd party libraries, then it's likely you're ending up with 5 different incompatible logging implementations in your final runtime, all doing their own thing.

It is a perfect example of the famous XKCD "multiple competing standards."

* https://xkcd.com/927/