[-] LiveLM@lemmy.zip 1 points 7 hours ago* (last edited 7 hours ago)

Hey, wanna know something even more awful?
Excel function names are localized.

[-] LiveLM@lemmy.zip 5 points 2 days ago

Best thing I did was change my shell prompt so I can easily tell when it isn't my machine

[-] LiveLM@lemmy.zip 6 points 2 days ago

Hope they support Portrait mode for the perfect commuter time killer

[-] LiveLM@lemmy.zip 7 points 5 days ago

he works in IT

Tell him that buying one instead of harvesting fresh from your local tech company CEO is a total wuss move

[-] LiveLM@lemmy.zip 2 points 5 days ago

Holy shit, this has to be one of the most insane things I've ever learned

[-] LiveLM@lemmy.zip 6 points 5 days ago

Well yeah, I figure when she signed her body up for science she was thinking about Medical Science and not Explosive Device Science...

[-] LiveLM@lemmy.zip 3 points 5 days ago

This seems like such a useless feature, I really wonder how they can justify wasting engineer hours like this

[-] LiveLM@lemmy.zip 6 points 1 week ago

For me too, however I would like to get a diff before confirming the merge.

[-] LiveLM@lemmy.zip 71 points 1 week ago

Full text of the post by Asahi Lina (@lina@vt.social):

I regretfully completely understand Wedson's frustrations.

A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.

When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".

My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".

Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.

One C driver works, so Rust drivers must work the same way.

Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).

To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.

The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.

If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?

Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.

[-] LiveLM@lemmy.zip 18 points 1 week ago

Full text of the post by Asahi Lina (@lina@vt.social):

I regretfully completely understand Wedson's frustrations.

A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.

When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".

My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".

Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.

One C driver works, so Rust drivers must work the same way.

Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).

To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.

The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.

If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?

Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.

[-] LiveLM@lemmy.zip 24 points 1 week ago

Backstabbing your fellow coworkers over a chatbot has got to be one of the most pathetic things I've read recently

866
Erulelation (lemmy.zip)
submitted 6 months ago by LiveLM@lemmy.zip to c/196@lemmy.blahaj.zone
view more: next ›

LiveLM

joined 1 year ago