vilunov

I'd go further and state that "ecosystems" are evil as they erode competition. It should be easy to change products independently of each other, e.g. I should be free to choose between Apple iCloud or Google Photos for storing my photo library. Instead I'm forced to experience what you already mentioned: integration preferences on different platforms, network effects and so on.

Only direct product properties should drive users' choices, everything else just raises the market entry barrier for potential competitors.

Oracle stopped distributing JVM for 32-bit Windows after Java 8. Minecraft was using Java 17, and there were other 32-bit distributions for it, but I couldn't find a 32-bit distribution of Java 21.

Godot editor, a desktop app, is made in Godot itself afaik

It provides an opinion of select engineers of that company, not insights or even general opinion of engineers. I work with Scala, I understand it very well, but I would still prefer to use a different language. Nevertheless, a vocal group of engineers at my company will always keep all criticism down to a minimum.

Even in this post lots of points are invalid and/or survivorship bias. Scala 3.3 recently introduced a breaking change in their type resolution (fortunately we don't use Scala 3), cats-effect migration is painful and drags on for a long time (years), sbt is slow and hard to understand.

I feel like many of these things are a source of confusion, including headers and status codes. Others are not really are for free even with HTTP, e.g. load balancing, this is still very much service-specific.

UDP-based HTTP/3 could be considered a better transport protocol in the future with its multiplexing and lack of HOL-blocking, but right now it's still worse than TCP on stable connections

This might have been true some years ago, but I cannot agree with it now. There is a well-written IRCv3 spec, which I was following when implementing my own IRC server. I also tested it with several clients and I found out that core functionality and official extensions are pretty consistent. Bugs that I encountered always were a misinterpretation of the spec either by me, or by the relatively new IRC client that I was testing with, but they are fixed now.

The encoding is almost always UTF-8, I never encountered anything else on any network I used.

Yes, some networks may be stuck in the past, that's unfortunate, but the modern IRC is pretty good. Also custom extensions are not a problem since the capability negotiation was introduced.

Personally, after implementing an IRC+XMPP server myself I became very disappointed by prevailance of HTTP-based protocols in everything. All software is so browser-based and/or browser-driven nowadays that HTTP became de-facto the only transport-layer protocol. This is just an additional abstraction and overhead over TCP/UDP, which we cannot remove at all.

People had very different assumptions about the Internet and security. What was a federated protocol back than wouldn't be considered now. If that hypothetical evolution of IRC had happened, then I'm sure a s2s IRC protocol would emerge, but that's not a protocol problem, it's more fundamental than that.

It would have to influence the c2s protocol as well, e.g. the identity is tied to the service provider and it has to be communicated to other clients somehow to avoid collisions.

IRC is not a federated protocol, so this is not a big problem. Yes, it's a "relay chat", but in the end all servers of a single network must trust each other, and that means they are being run by a single organization and it's just a mechanism for horizontal scalability. This is not the same as XMPP, which has a federation s2s protocol, but each service provider can use a custom server protocol for horizontal scaling.

It doesn't work with mesa, does it? I'm using the new nvk driver and it shows me no GPU to monitor.

Tauri is not that much different from Electron honestly.

Then don't do it in unit tests and write an integration test.

This is still not a conflicting requirement. Rust relies on implicit bounds, that is said in the linked document, and the "universal" quantification there is not really universal, it in fact has a requirement. It's not present in the syntax, but it's present in the type system. The algorithm in the compiler loses that requirement and fails to reject invalid programs.

Rust has many cases when it introduces implicit type-level properties, another one is async-fns with its lifetimes and marker-traits such as Send.

Automated algorithms based on user-generated flagging or subscribers count is not an excuse for censorship and bans

The ventilation in rooms was absolutely terrible, especially in building H. Rooms in K and U had windows which could be opened, but even that didn't help much. It's not much of a surprise that many people become sick after FOSDEM.

You are right, but most of what you mentioned is not UI and its UX.

I'm not living with rose tinted glasses, I mentioned search and UAC in my original message. This is not enough to warrant criticism of Win 95 clones. I bet you could add search to Serenity without changing the look and it would still be called a Win 95 clone.

We haven't improved much since Win 95 in terms of desktop OS UI/UX. Could you remember any substantial UI improvements between Win 95 and Win 11? Local search, improved UAC and a shitload of ads.

> another "systemd" developer

What does that mean?

That, and also that it has to be installed globally with the absolute path of `/nix/`. Sure, you can change it, but the packages won't work then.

This substitute manufacturer has to be financially motivated to do so, i.e. there should be enough potential customers

I'm getting a 0-byte response by the link, here's another one: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Unless they become bankrupt and no new modules will be released. It's hard to place faith in the future of a company like that, especially when I need a powerful CPU right now.

I have tried it, and I feel like this is not a good toolkit for desktop apps. It's great for embedded hardware with custom interfaces such as vending machines, car on-board PCs, screens in public transport, but it does not have that native look-n-feel on desktop, at least not out of the box.

> And it’s straightforward to switch to jemalloc, which often improves on the system allocator.

It is true that jemalloc is much better than the standard malloc, but it still suffers from memory fragmentation, although typically a program can run for much longer with it.

> It’s the operating system’s job to manage fragmentation in the allocator, right?

No, not really. The operating system does nothing with the memory space of the process, other than providing syscalls for giving the process more pages.

> Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust?

What some thicker runtimes such as JVM do is that 1) they track all pointers present in the data used by the program and do not allow programs to cast them to raw integers (or back); 2) they can defragment the heap by moving the memory chunks around to fill in the gaps and at the same time they rewrite all pointers that point to moved chunks so that they still point to the same data.

That's because a single org controls all three messengers and they can develop them to converge to the same message format and to the same encryption mechanism. At the same point Signal or XMPP will use a different format and a different mechanism, making them incompatible with messages from Meta, unless a client with a private key reencrypts them.

Why does "web streaming" require more cookies than legitimate interest?

Encryption makes it practically impossible to transform messages between different protocols, since the cyphertext contains not only the text content of the message, but also formatting, some attributes (e.g. `reply_to`). Even if it were the same, E2EE algorithms also differ between protocols, and you can't reencrypt the message for other protocols server-side.

Close to memory leaks, but not exactly: memory fragmentation. Unlike runtimes with managed memory such as JVM, Rust apps cannot take a pause and defragment the memory heap, which depending on frequency and sizes of allocations sooner or later will lead to your app taking up a huge chunk of memory and not using it efficiently.

It's probably just an unfortunate coincidence. After all, Gemini is a zodiac sign first and foremost, you'd have to specify what exactly you want anyway.