I’ve very barely dipped my toes in dbus before, and the option to have something else is on its face attractive (not a fan of XML and the late 90s/early aughties style of oop), but JSON for a system interface?

I mean, Kubernetes shows that yaml can work, but in this day and age I’d expect several options for serialisation, and for the default to be binary, not strings.

String serialisations are primarily for humans IMO, either as readers or writers. As writers we want something with comments (and preferably no “find the missing }” game), so for that most of us would prefer something like TOML if the data is simple enough, and actually Yaml for complexity at the level of Kubernetes—JSON manages to be even more of a PITA at that level.

But machine-to-machine? Protobuf, cap’n’proto, postcard, even CBOR should all be alternatives to examine

There’s wasm if you need to target browsers.

We’ve also recently introduced Coding Challenges to our site! These new challenges represent a new, fun way for developers to level up by tackling captivating puzzles and earning recognition for your skills and creativity. It’s a rewarding way to practice and expand your knowledge with the Stack Overflow community in a space that celebrates diverse and unique approaches.

aka

>pls provide training material for the LLMs for free :pray:

lol. lmao, even

Yeah, I think the fact that the next LTS will be 26.04 is the driver here, I just get the impression that things might get a little rocky and that they might’ve been better off had the next LTS been further into the future.

But it’ll be a real smoke test release, at least. Hopefully they have enough resources to fix the issues that are uncovered, and don’t wind up reverting for the LTS, or with a crummy LTS.

I’m generally an en_*.UTF-8 user (even tried en_DK.UTF-8 for a bit for a reason we’ll come back to), so I don’t have a complete picture of it and would have to go look at the documentation or source for that, but I’d expect

• documentation
• date formats: en_DK.UTF-8 should give you ISO8601-formatted dates, if I can’t have that I at least want DD/MM/YYYY; the US-american nonsense is just plain unacceptable
• sorting: e.g. Norwegian will have …zæøå and expect aa to be sorted as å, the Swedes have …zåöä, the Germans …zäöü, the Turks will want ı and İ sorted and upper/lowercased correctly, and there are some options around how you deal with “foreign” letters and diacritics.
• Probably more stuff relating to LC_* that I can’t think of off the top of my head

but in any case, an ls -l output should be different depending on your locale, and in ways you likely don’t even think about as long as it looks normal.

Yeah, I think those are just lacking in the internationalisation?

People like me, who at most have some reading glasses needs and have their computer set to generally English utf-8 will be likely be fine.

Between that and the uutils-coreutils, Ubuntu 25.10 sounds like it’ll be an interesting experience for users, especially those with accessibility and internationalisation needs.

Having had a look at the archived version linked below, it seems pretty clear that it’s entirely hogwash:

• The referenced init system replacement is called “rye-init”
• The wiki does not have anything on “rye-init” or even just rye
• The only hit on a package search for rye is rye, the precursor to uv
• I find no general search hits for rye-init, except references to the rye mentioned above (as in rye init), and some hits for this article and forum posts with people confused about it.

No, but a bad MS/Windows decision is often a catalyst. I came over to Linux from Windows ME. :)

It’s generally conspicuous consumption, where the main point is to flaunt wealth.

Functional aspects like how well an engine runs or a clock displays time are part of that, as poorly functioning but expensive-looking stuff is generally derided, but you also can get great-working stuff that doesn’t look flashy.

I’ve heard of the year of Linux on the desktop, but I’ve never really heard of the year of BSD on the desktop. Apart from OSX, maybe.

I guess this is the kind of stuff POSIX could’ve helped with, but it seems to be busy mandating buggy behaviour.

Yeah, and Android has had some 16 years of “optimize later”. I have some very very limited experience with writing mobile apps and while I found it to be a PITA, there is clearly a lot of thought given to how to not eat all the battery and die in the ecosystem there. I would expect that kind of work to also be done at the JVM level.

If Windows Mobile had succeeded, C# likely would’ve been lower as well, just because there’d be more incentive to make a battery charge last longer.

Is there a lot of computation-intensive code being written in pure Python? My impression was that the numpy/pandas/polars etc kind of stuff was powered by languages like fortran, rust and c++.

And it powers a lot of phones. People generally don’t like it when their phone needs to charge all the freaking time.

And battery costs, including charging time, for a lot of devices. Users generally aren’t happy with devices that run out of juice all the time.

Yeah, none of that with bat:

λ bat $(type -P bat)
───────┬──────────────────────────────────────────────────────────────────────────
       │ File: /usr/bin/bat   <BINARY>
───────┴──────────────────────────────────────────────────────────────────────────
λ bat < $(type -P bat)
───────┬──────────────────────────────────────────────────────────────────────────
       │ STDIN   <BINARY>
───────┴──────────────────────────────────────────────────────────────────────────
λ

I think most of us would consider that an eclipse bug, but yeah, until it’s fixed it’d make sense to work around it.

Kinda similarly, I have a mostly identical setup on several machines, and on one of them Firefox has a memory leak, which even showed up just recently. It also seems to manifest if I have certain pages open, the most noticeable of which is Reddit.

It’s the kind of stuff I could dig into, buuut it’s just a PITA.

Or bat, which will just print <binary> in those cases

As if anyone cared if they had to wait a total of 3 seconds in a workday.

That depends on when it appears. Some tasks kind of have to feel instantaneous, and there might be a pretty slim margin between okay and frustrating.

But yeah, that’s the kind of savings that mostly matter on the scale of regional or national grid planning.

Most engineers already write bloated, abstracted, glacial code that burns CPU cycles like a California wildfire. Clean code? Ha! You’re writing for other programmers’ academic circlejerk, not the hardware.

It’s interesting that everybody else preaches ‘Write for the human first, for the machine second’.

Yeah, the author seems to lean too hard into the “programming is electronics” model, where the opposing end is “programming is math and formal logic”; most of us take some mixed view. And most of us have higher correctness requirements than what a reasonable effort in memory unsafe languages like C and C++ gives us, so we trade away some machine efficiency. In the authors parlance, most of us aren’t interested in the demoscene circlejerk; we need to make tradeoffs between maintainability and everything else. Write-once code isn’t good enough.

There have been attempts at establishing a third pole of “promptgramming is natural language” or whatever ever since COBOL promised programming in plain English, but the ambiguity of natural language when used to encode a business logic machine means that a “sufficiently advanced compiler” will have to be extremely advanced, on the order of including the manager and the entire engineering methodology.

I’ve been using neovim for years (and the vim family for decades), and I guess with LSP it’s pretty much an IDE these days.