overview for PlexSheep

Open Source Infrastructure is Breaking Down Due to Corporate Freeloading in c/opensource@programming.dev

[–] PlexSheep 6 points 1 month ago

I guess we'll need ratelimiting

YouTube widely pushes AI age verification and restrictions in c/privacy@programming.dev

[–] PlexSheep 3 points 1 month ago

Okay that's a win. YouTube wasn't sure for years if I'm 18+ or not and didn't bother me with some shit

USUAL in your country but NOT anywhere else. in c/asklemmy@lemmy.world

[–] PlexSheep 1 points 1 month ago

Ich fucking liebe Sprudel ich trinke den ganzen Tag nichts anderes Sprudel ist so gut ihr habt alle keine Ahnung HAHAHA

Let's Make Sure Github Doesn't Become the only Option - Edward Loveall in c/programming@programming.dev

[–] PlexSheep 2 points 2 months ago

Yes

Let's Make Sure Github Doesn't Become the only Option - Edward Loveall in c/programming@programming.dev

[–] PlexSheep 3 points 2 months ago

Exactly. I'm looking forward to forgejo federation.

Let's Make Sure Github Doesn't Become the only Option - Edward Loveall in c/programming@programming.dev

[–] PlexSheep 2 points 2 months ago (2 children)

Selfhosted ci works well, but the GitHub ci is so fast it's not even funny. At least compared to my selfhosted stuff which is arguably cheap

Let's Make Sure Github Doesn't Become the only Option - Edward Loveall in c/programming@programming.dev

[–] PlexSheep 5 points 2 months ago (4 children)

Not all actions run on it.

Also, GitHub infrastructure is free and really performance, that's why I use it even if I have my own for server.

Also, discoverability. For the projects that I want to show to the world, GitHub is best, since it's most likely people see it there.

But also, the correct answer is Devil's Due in c/risa@startrek.website

[–] PlexSheep 5 points 2 months ago (2 children)

I have never watched a single star trek thing and the only knowledge I have about it comes from you guy's memes

Mods react as Reddit kicks some of them out again: “This will break the site” in c/technology@lemmy.world

[–] PlexSheep 4 points 2 months ago

Its one of the two hard problems of computer science after all

Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings in c/linux@programming.dev

[–] PlexSheep 5 points 2 months ago* (last edited 2 months ago) (1 children)

I found the study: https://doi.org/10.1145/3551349.3559494

It's open access, short, and really well written. Was a primary source of my bachelor's thesis.

Figure 2 for the lazy people:

The results of this study suggest that rust programs can be a bit slower, or nearly match the performance of C programs on x86-64, and that the runtime checks play a big role in this dynamic.

Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings in c/linux@programming.dev

[–] PlexSheep 1 points 2 months ago

It's things like out of bounds checking. I'll go look for the paper and make another reply.

Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings in c/linux@programming.dev

[–] PlexSheep 5 points 2 months ago (4 children)

I have read papers for my bachelor's thesis that compared rust and c on x86-64 in terms of performance. It showed that C is a little or significantly faster, depending on the type of workload.

This is likely due to some runtime checks the rust compiler adds, and modified rust compilers that added less runtime checks led to about the same performance.

However, the performance is still very good for both languages (native machine code being executed), and in the same order of magnitude.

My own measurements for the armv6m architecture with an STM-32 showed that rust may even be faster in some cases, since the optimizing of the rust compiler was better, at least for that setup and for the CRC-32 algorithm.