News for hackers. Stuff that matters.

eminence32

Re:MXC - a sandboxed code execution system on Friday October 09, 2026 @08:34AM (#50019598)
A little off topic, maybe, but I've been having great luck with wasmtime and wasm32-wasip3 for writing sandboxed plugins. The tooling is pretty nice when you write plugins in rust, but I don't know what it looks like for other languages right now.

wasip3 is not stable yet, but it has a lot of nice changes (compared to wasip2) for integrating with async code

Luckily there's a lot of people who write prototype code, toy projects, and other "non-production" code that can experiment with a new project like this
Re:Fearless SIMD v1.0 is here on Thursday September 24, 2026 @07:33PM (#49838217)
rust has been around for a while and has collected a large number of crates (many of them abandoned). So new crates need to adopt new and clever names
Re:Malicious Rust crate Arrayref runs a build-time payload on Thursday August 20, 2026 @06:02PM (#49380856)
Well, but as a system admin, I might not have cargo installed even if my users have it installed in their home directory. So a simple non-Cargo command (like find) has a lot of advantages for me
Re:Malicious Rust crate Arrayref runs a build-time payload on Thursday August 20, 2026 @12:55PM (#49377178)
> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.

I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache?

I personally appreciated having the `find` command:

* It very clearly indicates where to look (my cargo registry cache)

* It very clearly indicates what files to look for (a list of wildcards)

* It's something that I can easily review and then copy/paste into my terminal

* I can very easily adapt it to my particular environment (perhaps into a `fd` invocation if I'm on Windows, or perhaps adapt it to scan all home directories on my system), or feed these file names into some other vulnerability scanner

Re:Show HN: SIMD Viterbi Decoder in Rust on Wednesday August 05, 2026 @12:01AM (#49178431)
Could this library be used decode signals from a GOES satellite downlink? goestools uses libcorrect for this and building a rust version might be fun.

[1] https://github.com/pietern/goestools

Pelicans and bikes can be in the training set without them training for this specific benchmark.
There's been some new features in the past few years. But you're right that the general pace of new features is slow. There's only about 0.8 developers working on the game.

However, if you're the type of person that likes to work on spreadsheets to calculate profit margins and market trends, Prosperous Universe is worth checking out.

Re:Grit: Rewriting Git in Rust with Agents on Tuesday June 09, 2026 @10:43PM (#48470715)
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
Re:Claude Opus 4.8 on Thursday May 28, 2026 @04:30PM (#48315019)
I bet someone shares this link every time you post about bicycles, but since I didn't see anyone share it yet in this thread, I'll take the opportunity to do so:

https://www.gianlucagimini.it/portfolio-item/velocipedia/

Turns out even humans can be pretty bad at drawing bicycles :)

Re:Android now stops you sharing your location in photos on Monday April 13, 2026 @08:48AM (#47751222)
> But it is just so tiresome that Google never consults their community. There was no advance notice of this change that I could find. Just a bunch of frustrated users in my inbox blaming me for breaking something.

I get it. This unequivocally sucks. It's a clear loss of functionality for a group of people who are educated about the advantages and disadvantages of embedded EXIF data. But I don't honestly think Google could have consulted their community. It's just too big. So when the author says:

> Because Google run an anticompetitive monopoly on their dominant mobile operating system.

I don't think the problem here is that Google is anticompetitive (though that's a problem in other areas). I think it's just too big that they can't possibly consult with any meaningful percentage of their 1 billion customers (or however many Android users are out there). They may also feel it's impossible to educate their users about the benefits and dangers of embedded location information (just thinking about myself personally, I'm certain that I'd struggle to convey they nuances of embedded location data to my parents).

I will note that Google Photos seems to happily let you add images to shared albums with embedded location information. I can't recall if you get any privacy-related warnings or notices.

> It might be true that you'll never fix a given bug, but shouldn't there be a record of the "known defects", or "errata" as some call them?

Yes, fully agreed. But closing a bug doesn't preclude that. A closed bug isn't refutation or denial of a defect. It's just an indication that there is no plan to fix the bug. Not every bug system works like this though. My bug tracker works like this, and I should have more clearly described what a "closed bug" is in my earlier posts.

I used to think that there is no harm in keeping the bug open. I think if you honestly feel that you have the time and resources to go back to the bug and fix it, then by all means keep it open.

But I find that sometimes I can tell from experience that the IR is not actionable and that it will never be fixed. Some examples:

* There's not enough info to reproduce the issue and the user either can't or won't be able to reproduce it themselves. Intermittent bugs generally fall into this category. * The bug was filed against some version of the software that's no longer in production (think of the cloud context where the backend service has been upgraded to a newer version).

Sometimes the cost to investigate a bug is so high relative to the pain caused that it just closed as a WONTFIX. These sometimes suck the most because they are often legitimate bugs with possible fixes, but they will never be prioritized high enough to get fixed.

Or sometimes the bug is only reproducible using some proprietary data that I don't have access to and so you sometimes have no choice but to ask the bug filer "can you still reproduce this?".

Computer systems are complicated. And real-world systems consisting of multiple computer systems are even more complicated.

I don't work at Apple, so I can't comment on that. But that doesn't always help. There's been plenty of times where I have a full HAR file from the user and I can clearly see that something went wrong, but that doesn't always mean I can reproduce the issue. (I recognize a HAR file doesn't represent the complete state of the world, but it's often one of the best things a backend developer can get)
I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test.

When I close an old bug that is not actionable, I do feel bad about it. But keeping the bug open when realistically I can't really do anything with it might be worse.

Re:Nano Banana Pro on Thursday November 20, 2025 @10:19AM (#45993500)
> Generate better visuals with more accurate, legible text directly in the image in multiple languages

Assuming that this new model works as advertised, it's interesting to me that it took this long to get an image generation model that can reliably generate text. Why is text generation in images so hard?

This is obviously just a research project, but I do wonder about the next steps:

* After exploring an learning about a virtual world, can anything at all be transferred to an agent operating in the real world? Or would an agent operating in the real world have to be trained exclusively or partially in the real world?

* These virtual worlds are obviously limited in a lot of important ways (for example, character locomotion in a game is absolutely nothing like how a multi-limbed robot moves). Does there eventually need to be more sophisticated virtual worlds that more closely mirror our real world?

* Google seems clearly interested in generalized agents and AGI, but I'm actually somewhat interested in AI agents in video games too. Many video games have companion NPCs that you can sort of give tasks to, but in almost all cases, the companion NPCs are nearly uncontrollable and very limited in what they can actually do.

Just run your AI calculations on your favorite Cryoarithmetic Engine, no problem.
Relevant links:

https://www.fns.usda.gov/snap/ebt/retailer/retailer-notice/r...

https://www.fns.usda.gov/snap/fr-022124

> Coupons shall be accepted for eligible foods at the same prices and on the same terms and conditions applicable to cash purchases of the same foods at the same store except that tax shall not be charged on eligible foods purchased with coupons.

Obviously lawyers are going to be involved in interpreting these rules. But as a lay person, I wonder: a store cannot charge a different price to someone who is buying food with a SNAP coupon. But for someone who has SNAP benefits, but isn't using a SNAP coupon to buy food (you know... because the government isn't funding the program), do these rules still apply?

FWIW, I've used KeePass for years and have never used its browser integration...
I remember vividly a childhood experience when a car I was in ran over a dog -- it ran towards the side of the car and went under the rear wheels of the car. I'm not sure there's any reaction time (human or otherwise) that would have prevented that from happening.
Re:What we talk about when we talk about sideloading on Tuesday October 28, 2025 @06:50PM (#45740320)
> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per year "developer program" free in order to use the devtools to test the app on your physical device.

If Google is also blocking preventing you from loading your own software onto your own phone with adb unless you pay a free, then this would be a very important thing to call out explicitly.

Re:Notes on Switching to Helix from Vim on Friday October 10, 2025 @12:42PM (#45540905)
I really enjoy Helix, but I can't install it everywhere, and so I end up going back and forth between Helix and Vim depending on what machine I'm working on. This puts a lot of pressure on my muscle memory -- I often type a vim keybinding while in Helix or a Helix keybinding while in vim.
I'm not an android developer, so I'm missing some context and key information. But I have a question: When Google is asking developers to "register" their apps as part of this new program, are they just trying to keep a mapping from some code signing key to a government ID? Or are they trying to do a code review process that is similar to submitting to an app store?

I know both are objectionable in their own way, but these two scenarios are quite different and I want to understand this better.

Some years ago, "iroh" was supposed to a replacement for ipfs. However since then, they (very smartly, in my opinion) dropped those ambitions and are just focused on being a high-quality library for anyone writing a P2P app (like ipfs).

I often see projects attempting to be a universe tool to solve every possible problem, and I think the iroh folks were smart to scale back and narrow their focus

Re:Photon transport through the entire adult human head on Tuesday June 17, 2025 @01:34PM (#44301604)
First paragraph of the "4. Discussion and Conclusion" section

> We speculate that the participant’s fair skin and lack of hair were significant factors that reduced the attenuation of light to feasibly detect a signal. In addition to the participant wherein a signal was observed, the experiment also included trials on seven other subjects. The details of the subject pool are as follows: two females and six males; 25 to 35 years old; 14.5 to 15.5 cm head diameter; Fitzpatrick skin types: 3 type I, 4 type II, and 1 type V; hair types: 1 bald, 4 short and light-colored, and three dense and dark-colored. We did not observe any significant time-correlated signals above background noise for the seven other subjects.

Re:Canyon.mid on Sunday June 15, 2025 @12:09PM (#44283054)
I remember this media player from back in the day :)

Looking at it now, I love how they used a scroll bar as the UI widget to represent playback progress.

Re:Create and edit images with Gemini 2.0 in preview on Wednesday May 07, 2025 @01:38PM (#43918542)
This seems neat, I guess. But whenever I try tools like this, I often run into the limits of what I can describe in words. I might try something like "Add some clutter to the desk, including stacks of paper and notebooks" but when it doesn't quite look like what I want, I'm not sure what else to do except try slightly different wordings until the output happens to land on what I want.

I'm sure part of this is a lack of imagination on my part about how to describe the vague image in my own head. But I guess I have a lot of doubts about using a conversational interface for this kind of stuff

Re:Japan unveils first solar super-panel on Tuesday April 29, 2025 @10:28AM (#43833169)
> Panels to the east of you get sunlight earlier in the day and panels to the west of you get it later in the day.

I sometimes think about a sci-fi world in which there is a globally interconnected power grid, so solar panels in daylight India can provide power to Spain. And then when the sun shines in Spain, it can generate solar power for California

> /ˈkaɪpər/

Wikipedia has long included IPA pronunciation info for pages about people and other things, which is hyperlinked to a handy guide. But I recently discovered something useful and not entirely obvious:

If you over your mouse over each letter in the IPA pronunciation, you'll get a tooltip describing the sound of that specific letter.

Older »