Programming

17476 readers

220 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

205

The US government wants devs to stop using C and C++ (www.theregister.com)

submitted 1 week ago by lemmee_in@lemm.ee to c/programming@programming.dev

91 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] nous@programming.dev 34 points 1 week ago (8 children)

They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

I don't even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.

[+] wewbull -6 points 1 week ago (7 children)

The Rust kernel devs are ...

...asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.
...asking maintainers to accept code into their subsystem whilst being told, you don't need to know Rust to an expert level...trust us. Cross language interfaces always have nuance and make good attack vectors. Understandable that maintainers are cautious.
...creating quite a lot of hassle for no a lot of improvement. Systems are only as resilient as their weakest components. The cross language interface is always going to be weak. Introducing a weakness to get improvements probably only succeeds at making the whole weaker.

[–] sukhmel@programming.dev 7 points 1 week ago (3 children)

What's the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don't quite understand what it even is about

[–] wewbull 14 points 1 week ago (1 children)

Having binary blobs linked into your kernel is a maintainability nightmare. You're allowing a third party to link their buggy drivers into the heart of your platform. It breaks any security model you have, and brings with a bunch of bugs that are impossible to debug.

Nvidia were the worst offender and it culminated in this:

https://arstechnica.com/information-technology/2012/06/linus-torvalds-says-f-k-you-to-nvidia/

[–] sukhmel@programming.dev 1 points 1 week ago (1 children)

Got it. I agree that their drivers are (were?) of exemplary bad quality

But I don't think that it is realistically possible to drop all the proprietary firmware blobs, and if it's not maybe it's better to not actively sabotage something to 'avoid those being feasible'?

[–] Vilian@lemmy.ca 2 points 1 week ago

Firmware don't link to the kernel tho, and the kernel functions aren't stable so a firmware today would stop working tomorrow because a function was refactored(and all the code in the kernel that depend on that function) for performance or security, and the binary can't be refactored so it become useless

load more comments (1 replies)

load more comments (4 replies)