Not my area of expertise, but egui may suit your use-case better than the usual candidates.
- 0 Posts
- 20 Comments
Joined 4 months ago
Cake day: June 6th, 2025
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
4·19 days agoAs a Rust dev who has to target Windows, more support for Rust from MS is very relevant and important to me.
“Target Windows” presumably doesn’t involve writing drivers. How would WDK FFI wrappers help you exactly in that context, and what non-trivial support is MS actually providing?
Maybe you mistook this community for !opensource@programming.dev?
No, I didn’t. Any language community can easily become a corpo spam one if you don’t put some rules in place to filter direct and indirect ads.
Let’s analyze this “news” story as an example:
- Microsoft published trivial unsafe NDK FFI wrappers and tooling awhile ago (not new, not impressive, not news).
- Microsoft publishes an ad in their blog mentioning the published wrappers, and using a lot of marketing talk, with a random trivial
LookasideListsample wrapper sandwiched in between. The realLookasideListimplementation is of course neither available, nor is it implemented in Rust (If it was, you would be going through two layers of FFI to connect Rust to Rust, which would be even more stupid). Below that random sample code is this note:
Though we believe this wrapper to be sound for the purposes of the team that developed it, it requires further review and testing before we can publish it as the “official” wrapper for these APIs. Thus the above should be considered a possible look at what Rust abstractions for our kernel mode might look like, and not final code.
In the long term, as we make design decisions and finalize our wrappers, our intent is to publish these wrapper crates on crates.io as first-class members of the Rust ecosystem.
- Then independent “news” sites pick up on these low-in-technical-substance ads, and consume the well crafted marketing section titles like “The next steps: going from unsafe Rust to safe Rust”. So we end up with the title here “Microsoft is turning Rust into a first-class language for developing secure Windows drivers”. When in reality, almost literally nothing happened (yet). And even the premise and promise is all about making safer bindings to (presumably) non-Rust code we will never see.
For me, corpo ads with no “relevant” code is boring (or in this case, no new code at all, unless you count the sample list binding). And I can’t imagine I’m alone here.
For me, posting every single pull request from the Asterinas repo would be infinitely more interesting, and infinitely more relevant.
Adding rust FFI bindings to a part of a closed-source system doesn’t magically make anything “secure”.
And ads shouldn’t be allowed here, unless real fully functional code (not just bindings) is made available. Such ads should go to !technology@programming.dev or wherever.
Only looked at the
Cargo.tomlfiles.- (pet peeve) Considering there is (presumably) no compatibility concerns, why not use an efficient binary format instead of JSON?
- Not checking in
Cargo.lockfiles, and using=dependency versions forPhoenix_Desktop, is a bit odd!
84·25 days agoPeople stopped taking Brian seriously when he helped create Go. That was pre-Rust.
Even the “talking points” here seem to be re-used from “Go vs. X” ones. Also, his experience speaks of someone who only tried Rust pre-v1.0.
Anyone who actually knows Rust, anti- or pro-, knows that what he said (partially in jest) is factually wrong.
Feel free to prove otherwise, especially the part about the performance of Rust programs. Don’t be surprised if he simply didn’t pass
--releasetocargo build, a common pitfall for someone in the “hello world” stage of trying Rust.And this is why appeal to authority was never more fallacious, considering we live in a world where Dunning-Kruger is a universal reality.
man 7 hieris much older than linux itself. The 1994 start date in the article is not doing the history of the tradition justice.It would have been weirder if the creepy “init system” (with its 58 executables and counting, 52 + 6 arg0 links) dictating the future of that tradition didn’t raise some eye brows.
2·28 days agoWhat’s wrong with it
- It’s a random crate no one uses.
- You’re not even really “using” it. You are just importing a re-export of
reqwest, which is what I expected you to immediately notice after I brought it into attention. You can obviously just remove it and usereqwestdirectly. - Still, trusting a re-export is not a trivial matter. The random author of the no-name crate could replace the original
reqwestwith something malicious, or bad in some other way, in a v0.1.1 release. That (theoretical) release will be picked up after acargo updatecall, or whenCargo.lockis not checked, which is the case by default with libraries.
How did you find that crate?
Why do you think you need it?
Can you explain the rust-fetch dependency?
Why Peter Thiel though?
It was a (failed) joke about your user-name.
How much “vibe coding” is involved?
And are you Peter Thiel by any chance 😉
4·1 month agoThought it was on my end.
Change your mirror!
I’ve been using the repos relatively frequently, and never noticed anything.
I also just tested my mirror of choice with a random big package.
https://mirror.dogado.de/archlinux/extra/os/x86_64/libreoffice-still-24.8.7-5-x86_64.pkg.tar.zst
All good!
reflectoruses https://archlinux.org/mirrors/status/json/ to get mirror status info, and caches it under~/.cache/Reflector/. So as long as that end-point works, reflector should work.I just grabbed a copy and pasted it at http://0x0.st/Ki3Y.json.
Anyone can grab that JSON data and use file:// URLs so they are never out. e.g.
curl -L https://archlinux.org/mirrors/status/json/ > /tmp/mirror_status.json # or if down, use pasted json curl -L http://0x0.st/Ki3Y.json > /tmp/mirror_status.json # and then reflector --url file:///tmp/mirror_status.json ...But, as you noted, this has been mostly a nothing-burger from a user perspective anyway. Other than the homepage being unavailable on occasion, everything else has been mostly available just fine as you can see from https://status.archlinux.org/.
I didn’t notice https://gitlab.archlinux.org/ going down either.
BTW, and as a general rule of thumb, NEVER take specific technical advice from these editors. They don’t actually know much, and this is me trying to be nice.
Take for example:
For AUR disruptions, it’s a bit of a pain if you’re not a regular git user, but you cloned packages directly from the GitHub Arch Linux mirror. To do this, use the command:
See that link ;) At least he got the command below it correctly, somehow.
You are in a thread where a user is having a problem because of the push for flatpaks, and because of some distros like Fedora crippling their packages and providing objectively worse alternatives on purpose (because they don’t want to risk
RHIBM getting sued). If the user was using some sane community distro like Arch, the user would have never come to realize that such unnecessary issues even exist.As for flatpak hate specifically, see my ramblings here.
Users are better off using a “freeworld” ffmpeg package, or not using Fedora at all. The cisco decoder is shit.
your life will be better if you stop using both flatpaks and openh264.
2·1 month agoThis is such a excellent unexpected original comeback, I will give you a chance to do another one.
How to extract the content of a flatpak
Which is something you presumably want to do because you don’t want to use
flatpak/ostree.The first step of course, is to install
ostree. 🤨Then, via this very official method:
ostree init --repo=repo --mode=bare-user ostree static-delta apply-offline --repo=repo some.flatpak ostree checkout --repo=repo -U $(basename $(echo repo/objects/*/*.commit | cut -d/ -f3- --output-delimiter= ) .commit) outdirThis official solution looks very reliable.
The impenetrable building blocks
Searching vulnerability databases will obviously prove futile. Like the below sample entries (search limited to CVSS>=9.0 and Age<90d)
[CVE-2025-7458] Critical - SQLite - Integer Overflow ↳ Priority: MEDIUM | No exploits | Vuln Age: 15d (RECENT) ↳ CVSS: 9.1 | EPSS: 0.0003 | KEV: ✘ ↳ Exposure: 12 | Vendors: sqlite | Products: sqlite ↳ Patch: ✔ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘ ───────────────────────────────────────────────────────────────────────── [CVE-2025-6965] Critical - SQLite - Buffer Overflow ↳ Priority: HIGH | EXPLOITS AVAILABLE | Vuln Age: 29d (RECENT) ↳ CVSS: 9.8 | EPSS: 0.0005 | KEV: ✘ ↳ Exposure: 13 | Vendors: sqlite | Products: sqlite ↳ Patch: ✔ | POCs: 1 | Nuclei Template: ✘ | HackerOne: ✘ ───────────────────────────────────────────────────────────────────────── [CVE-2025-49796] Critical - libxml2 - Denial of Service ↳ Priority: MEDIUM | No exploits | Vuln Age: 57d ↳ CVSS: 9.1 | EPSS: 0.0013 | KEV: ✘ ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘ ───────────────────────────────────────────────────────────────────────── [CVE-2025-49794] Critical - libxml2 - Use After Free ↳ Priority: MEDIUM | No exploits | Vuln Age: 57d ↳ CVSS: 9.1 | EPSS: 0.0013 | KEV: ✘ ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘ ───────────────────────────────────────────────────────────────────────── [CVE-2025-4517] Critical - Python tarfile - Path Traversal ↳ Priority: MEDIUM | No exploits | Vuln Age: 71d ↳ CVSS: 9.4 | EPSS: 0.0015 | KEV: ✘ ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘ ─────────────────────────────────────────────────────────────────────────libxml2andsqliteare in the dependency tree ofostreeitself of course. But really, nothing to see here.
Just the common “hate” talking points.
Because it’s more inconvenience than help for users who are average or above, and have no interest in using that technology.
If app developers start distributing binaries as flatpaks exclusively (examples of this already exist), then just extracting those binary packages alone is a chore (involving obscure(ish) steps starting with creating an empty ostree). It’s the kind of knowledge that is so useless you immediately erase it from your memory, which is what I did.
Also, one look at the dependency tree of flatpak, or even just ostree, and you quickly realize how much of a joke the “security” claims are with all that attack surface (think the xz in systemd drama and multiply it by a 100).
Can Flatpak itself be sunset with some bullying?
The first thing forcing an option does, is depriving that option the ability to know what it could achieve on pure merit.
Or to avoid ad hominem accusations:
No code. Don’t Care.
And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.