#netherlands #outage #NATOsummit
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
Glad 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
I 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?
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
Apple 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?
🤦♂️
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?!?!?!