How fun, this should go on a ‘Best of the Fediverse’ type post or something.
How fun, this should go on a ‘Best of the Fediverse’ type post or something.
Man I really miss the design language of the S8/S9
I’ve learned this information a while ago and I’m still upset.
Seems like every time I stop watching a YouTuber for a while, I come back later and whoops! turns out they did something awful! 🙄
otherwise it goes in the landfill
Ah, well in that case, fair enough.
I’ve done my fair share of ridiculousness to keep free crappy hardware running.
I will say, try running Alpine Linux on a container.
I’ve managed to extract some usefulness out of a borderline e-waste Android tablet running some flavor of Jelly Bean, so outdated you couldn’t connect to most websites due to bad TLS certs, by running a Alpine Container on it.
Alpine was the only distro I found that could run up-to-date software on such a ancient version of the Linux kernel, everything else failed to work at all.
You avoid buying them precisely because of this.
Without a shred of doubt.
Fuck the Play Integrity API.
Okay, and now find a messaging app that supports RCS that isn’t Google or Samsung messages.
Being stuck to 2 apps, one of which is OEM exclusive sure defeats the point, now doesn’t it?
Correct!
I put a little Home icon on mine using NerdFonts.
If you are using ZSH or Fish you can do much more
I fucking hate GPU companies for always removing SR-IOV from their consumer cards
And RCS on top of not being available in a lot of places, is a closed standard, no matter how Google tries to spin it.
I’m glad Meta seems to be keeping most of the junk they have on Insta/FB away from WhatsApp*
^*so ^far
0% fixing the multitude of crippling crashes and bugs that plague the software making it unusable for daily computing.
You say this in the comments of a blogpost where they are precisely doing that
Wdym??? Are you not excited for Corporate Soullessness: The Movie???
Best thing I did was change my shell prompt so I can easily tell when it isn’t my machine
This seems like such a useless feature, I really wonder how they can justify wasting engineer hours like this
Read also: Naomi Wu and the Silence That Speaks Volumes by Jackie Singh
For me too, however I would like to get a diff before confirming the merge.
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.
And people wonder why I root?
It’s really maddening having to root just to get a say on what is happening on your device, isn’t it?
Anyway, what app do you use to control the broadcast receivers?
Holy shit! This is the first one of these things I’ve seen with SATA slots