a low latency kernel (whatever that means. I’ll get there to figure it out eventually)

It’s a kernel with real-time process scheduling enabled by default.

In normal kernels a process can theoretically block all other processes from running for up to several seconds, which is obviously bad for time sensitive things like audio recordings or controlling a CNC-machine for example.

In real-time scheduling all processes are guaranteed time slices in more regular intervals. This is good for time sensitive things like audio recording, but since there is some scheduling overhead it’s bad for single resource intensive processes or process trees like video games.

You can read more about the difference between a real time and low latency kernel here: https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel

Kemp et al. 2022 - Climate Endgame: Exploring catastrophic climate change scenarios

TL;DR: Societal collapse seems possible, more research is needed.

deleted by creator

Not familiar enough with this particular project to know, but a quick glance at the commit log shows some overlap in commit authors, so I guess there is at least some level of sharing happening, probably just not through merges.

But being familiar with this kind of project in general, the branches will probably never be fully merged even in the future, just doesn’t make much sense because they are server software targeting very different versions of a game client. There are also two other branches, but they “only” diverged by like one or two thousand commits so far.

Besides the cross-posts there is another discussion in
!world@lemmy.world (this link should take you to the community in your app/website):
https://lemmy.ml/post/29400920 (this link will take you to the post on the website I’m viewing it from)
about the link to the Reuters video: https://www.reuters.com/video/watch/idRW057230042025RP1/

Isn’t Karma essentially just the delta between upvotes and downvotes you get with some sort of weighting thrown in?

Because you can very much get that delta on here, it just isn’t visible in the default Lemmy interface. If you look at your account through an Mbin frontend for example you can see the “Reputation points” value in the sidebar: https://fedia.io/u/@wittycomputer@feddit.org

For many European languages and some non-European ones there is the CEFR, so you could look for an “A1” or “A2” level language course in whatever you want to learn. They aim to establish exactly this basic level of communication.

Read the policies yourself

I suggest reading this diff to the FAQs instead, paints a much clearer picture:

https://github.com/mozilla/bedrock/commit/d459addab846d8144b61939b7f4310eb80c5470e

Basically removes all the language about not selling data and some about privacy. Down in the comments someone argues this is due to a narrow legal definition of that language in certain jurisdictions, but that couldn’t sound more like an empty excuse if they tried. Actually all the reactions from Mozilla I have seen on this so far sound like pure corpo PR bullshit to me.

You and i read different things.

Apparently we did.

I hated how he worded them, but his arguments at greppable and understandable are valid arguments that go beyond rust and if he can read it or not or refuses to.

I’m failing to see how Rust code is not greppable unless you don’t speak Rust.

Mixing languages in a part of a project brings complexity and is often a huge ass nono because it makes things unreadable and hard to manage on a large scale.

An argument which I would acknowledge, but if the decision to do this has been made by the group it still is weird to see it blocked by an individual.

He also argues that a c interface exists to connect 2 parts of a system. The person that changes the interface should not have to alter the users of that interface, […] So if he changes the interface, the rust team will need to fix it, specially since they are the minority.

Nobody asked Hellwig to do this, in fact Krummrich said several times they would maintain the interface consuming the C code themselves. They just want one common interface for all Rust drivers, instead of replicating the same code in each driver. Which Hellwig never gives a substantial reply to.

That also doesnt mean he can change it in whatever way without worry, it is an interface change, that needs discussions and approvals ahead of time ofc.

Again not how I’m reading that thread. As Krummrich put it:

Surely you can expect maintainers of the Rust abstraction to help with integrating API changes – this isn’t different compared to driver / component maintainers helping with integrating fundamental API changes for their affected driver / component, like you’ve mentioned videobuf2-dma stuff.

How do you figure?

The only two “technical” arguments I could see were firstly that code should

[remain] greppable and maintainable

which unless I’m missing something boils down to “I don’t speak Rust”, and secondly that

The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this

which unless I’m missing something boils down to “I don’t speak Rust”, because ain’t nobody trying to add any other languages to the Linux code base.

Surely this can’t be the “decent technical reasoning” you are referring to? I have to admit I don’t follow kernel development that closely, but I was under the impression that integrating Rust into the code base was a long discussed initiative having the “official” blessing of the higher ups among the maintainers by now, so it seems odd to see it opposed in such harsh terms by a subsystem maintainer here:

I absolutely support using Rust in new codebase, but I do not at all in Linux.