Most telecom companies in the Netherlands seem to be experiencing outages. Interesting timing with the ongoing NATO summit in The Hague.
#netherlands #outage #NATOsummit
#netherlands #outage #NATOsummit
Qaz
@qazcetelic
- 7 Followers
- 93 Following
- 903 Posts
jonny (good kind)Just seeing that they are threatening Wikipedia's tax exempt status. The one good thing on the internet, the one healthy way we have of interacting with information.
https://www.theverge.com/news/656720/ed-martin-dc-attorney-wikipedia-nonprofit-threat
Julian OliverGlad to share a fun weekend project, a powerful #Meshtastic node in a waterproof & rugged case, for use in comms blackout situations/emergencies. It allows for texting across the mesh with a smartphone.
It also has an offline WiFi network serving both the Collapsible wiki, and simple usage instructions.
The solar panel trickle-charges a roomy LiPo that should give more than a week of cover, with phone charge port behind it. Has spare antenna (orange rope is for lifting the baseplate out)
1/3
Asahi Lina (朝日リナ) // nullptr::liveI think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem.
I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.
Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?
Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?
Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?
calcifer 🧯Please stop demonizing “AI”; the stuff you have a problem with isn’t AI research or AI tech, it’s a very small subset of that domain that (a)has ethical issues with training data sourcing and (b)is being horribly misused/way overly trusted
AI research is valuable and important, and MOST of it doesn’t have these problems. It’s doing things like increasing the reliability of cancer screenings, helping astronomers make better observations, improving assistive technology, accelerating medical research, etc.
Not all AI is “train a chat bot” or “train an image generator” for nefarious or stupid purposes
Mr. BitternessApple QA seems to have been asleep at the wheel for the Sequoia release.
Sure, the 15.0.1 release now makes the stateful firewall UDP aware, so you can use exotic things like DNS with the firewall blocking unilateral incoming connections. At least there was a workaround for that.
How about unix datagrams, though?
Did you know that a simple userland rust program that attempts to use Unix datagrams to connect to themselves will panic the entire OS?
🤦♂️
Orhun Parmaksız 👾Two weeks after the initial release, I'm excited to announce the new version of **Binsider**! 🎉
🕵️♂️ A TUI for analyzing Linux binaries.
🗡️ Swiss army knife for reverse engineers.
➡️ What's new: https://binsider.dev/blog/v020/
🦀 Written in Rust & built with @ratatui_rs
⭐ GitHub: https://github.com/orhun/binsider
#rustlang #tui #ratatui #binary #analysis #linux #reverseengineering #hexdump #opensource #terminal #commandline
From Jason Gunthorpe, maintainer of 5 Linux kernel subsystems:
IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.
Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".
(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)
I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...
Someone on Reddit was making a bunch of nonsensical comments about the Rust-for-Linux story and... and apparently it turns out that they were looking at Alyssa's DCP driver for the display hardware, which is written entirely in C, and has absolutely nothing to do with Rust, but they thought Alyssa and I were the same person and somehow conflated everything together with my Rust-for-Linux work??????
How do you even look at a 100% C driver and think it has anything to do with Rust?!?!?!
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.