Ephera

To point it out for folks unfamiliar with Rust, I consider this comment borderline misinformation.
I don’t know in what world the Rust compiler is considered unreliable. In my experience, it is one of the most reliable toolchains across all programming languages.
The Rust compiler is slow, because it does so many more checks than the C compiler, which is what these devs want. This is also barely relevant while actually developing, because then incremental compilation kicks in, which makes subsequent builds rather quick.
And Rust binaries are primarily larger than C binaries, because it does not use dynamic linking of dependencies. In the kernel, you cannot use dynamic linking anyways, because you need a running kernel to have a filesystem from which to dynamically load these.

I believe, the solution to that is more parks.

Linus has also declared Rust as basically inevitable before, since more and more kernel maintainers retire and not many young devs learn C anymore, at least not to a proficiency where you can handle kernel development.

You mean Gitea? Forgejo is a fork from it, maintained by a non-profit, so preferrable to most folks.

At $DAYJOB, we’re currently setting up basically a way to bridge an interface over the internet, so it transports everything that enters on an interface across the aether. Well, and you already guessed it, I accidentally configured it for eth0 and couldn’t SSH in anymore.

Where it becomes fun, is that I actually was at work. I was setting it up on two raspis, which were connected to a router, everything placed right next to me. So, I figured, I’d just hook up another Ethernet cable, pick out the IP from the router’s management interface and SSH in that way.
Except I couldn’t reach the management interface anymore. Nothing in that network would respond.

Eventually, I saw that the router’s activity lights were blinking like Christmas decoration. I’m guessing, I had built a loop and therefore something akin to a broadcast storm was overloading the router. Thankfully, the solution was then relatively straightforward, in that I had to unplug one of the raspis, SSH in via the second port, nuke our configuration and then repeat for the other raspi.

They are working on a new touch keyboard: https://invent.kde.org/plasma/plasma-keyboard
But yeah, no idea when it’ll be ready.

Well, I happen to be lucky enough that this particular project is actually developed as part of my dayjob. And the other projects, if I’m honest, are just projects I developed to scratch my own itch and then uploaded onto Codeberg with a libre license. I haven’t really announced them anywhere, except to a few colleagues, so I basically never get suggestions there.

But yeah, this project being part of my dayjob kind of makes it even more clear-cut that I’m not going to put in extra time to develop features that no one currently sponsors…

Apparently, the name is derived from “jetstream”, so it probably is supposed to be pronounced like cheddar. But a German who does not know that would probably pronounce it as Yetta, yes.

Got a comment last week on one of the open-source projects I’m contributing to. We have an issue open, documenting that we’d like to support a certain feature, and this person clearly took quite a bit of time to pull together information, which gets us over the first major hurdle for this feature.

But also, this feature is really not the highest priority to us right now. Really had to stop myself from promising that we’d look into it in my response, because it is still quite a bit of work to actually make it a reality. I’m still new to all this, so I still have to learn to not feel bad about it. If they want to scratch their own itch, they’ll have to scratch it in full. That I’d review their code before merging, is honestly already quite a bit of effort put in by me for something that I don’t care to solve right now. That I take time to respond is basic decency, but still also uses up time. Really, I had not understood before, how much work it has to be for maintainers with an actually active community.

I have no idea, if it’s any good, but apparently this exists: https://content.luanti.org/packages/JALdMIC/aw_personaje_anthro/

I believe, you could in principle use any Blender model, although I’m guessing, they’d need to match in terms of animations. I’m not deep into either Luanti modding or Blender, so not sure how it works together, but here’s some documentation describing it: https://docs.luanti.org/models/using-blender/

Android, Chromium.

The problem is that:

1. Google puts in more development power than anyone else. Any forks we’ve seen so far are only really soft forks, as in they only apply a few patches on top of what Google puts out, rather than taking the project in a new direction, because you’d be behind pretty quickly.
2. These projects establish platforms that have shitty decisions baked in. For example, the Android dev tooling has Google ads/tracking as one of the built-in UI components, which is why even if you patch the OS, the apps will still be shitty. To actually change this stuff, you’d need a majority of users to switch to your fork and stay there for a few years.
3. Partially, it’s only financially viable for Google to develop these projects, because they have those Android ads or benefit from a web with less tracking protection. This makes it extremely unlikely for any other organization to be able to splurge a similar amount of money, which brings us back to a fork just being unlikely.

And so long as a fork is unlikely, Google can do shitfuckery quite similar to proprietary projects.

You don’t need to always be of the same opinion for it to be much less loaded than Linux politics…

Yeah, really happy about this. $WORKPLACE uses Ubuntu and the Snap is just mildly broken in multiple ways. The .tar.bz2 works, but we would have had to script the download + creation of the .desktop file. We successfully procrastinated doing the latter long enough, that Mozilla fixed it.