> 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
I believe what's being suggested is that `cargo audit` should be a part of cargo rather than an add on.
You'd obviously already have cargo installed, which means you should be able to run a command against cargo to see if you are currently exposed to any security problems. Even if it's not the current "audit" add on.
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
As someone using bazel at work, the find script was much more amenable to me trying to audit our usage - we don't use cargo, so no cargo cache or cargo audit, but I can still figure out whether a particular package was downloaded.
If you're using a different tool then it falls to that tool to address the same problem. The point is that I shouldn't have to already know that a compromise has occurred and then go looking for it manually. The tooling should automatically start shouting at me very loudly that something happened with one of the packages I'm using.
You could certainly call this crate through a shim in goestools but you'd have to add a Rust dependency. But you could also rewrite goestools in Rust, though it wouldn't be a small undertaking. This crate does have everything you'd need for the forward error correction, at least.
I used the benchmarking binaries that ship with libfec. My own crate has a libfec-compatible C shim, so I can link the benchmark against the Rust crate. The benchmark itself reports time spent for a given number of iterations, so the throughput can just be extrapolated from that.
"How do you find the speed of the Rust version of your FEC vs, the C version?"
translates from "Australian" to "English" as:
"What is the speed of the Rust version of your FEC vs, the C version?
Though it was interesting to know how you do it. I'm interested in the speed, as I once looked into using Rust for a signal processing project, but ultimately went with C++ because the team wasn't familiar with Rust. At the time, it seemed to me that Rust had the potential to go faster.
tldr: My library matches or beats libfec's SSE2 assembly for convolutional codes and pretty steadily beats it in Reed-Solomon. For the convolutional codes, my crate is using a generic, templated decoder rather than hand-written assembly, so it was nice to see that I could match the performance.
> Yes and that would improve its ability to draw SVGs of pelicans on bikes, no?
I would think the opposite because unless people have been hand drawing these with high quality, the training would be on much crappier versions that old AIs have done.
the nature of the test was to see if the models can effectively compose an image of a novel concept outside the training set. If they are trained on it, it ceases to be an interesting test to some extent.
I would urge you to re-read the blog post you are commenting on. It pretty clearly explains how it is an interesting test independently of "see[ing] if the models can effectively compose an image of a novel concept outside the training set".
it's still interesting because there's no pelican-on-bike model, and if you're training a model well enough, then it should be obvious when a model has reached "AGI" or whatever.
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.
One thing I didn't like about it (and briefly experimented with, in a prototype for my own game in a similar vein), was, much like EVE, it's called a “spreadsheet game”, but there's no spreadsheets in the game, or any sort of API bridge that makes doing stuff with the game in an external spreadsheet environment easier. I understand that this may just be part of the appeal of these sorts of games for many people—reading through stat blocks and wiki pages to figure out what numbers and what formulas need to go where to build the Ultimate Spreadsheet for your purposes (though in the end doesn't everyone just use existing Ultimate Spreadsheets created by others, or at least use them as reference?). And trust me, I did have a lot of fun building my Google Sheets infrastructure to coordinate business and production between myself and the three friends I got to (briefly) play Prosperous Universe with me. Also, don't get me wrong, I also enjoyed the subsequent rabbit-hole of learning how spreadsheet implementations actually work, including historical alternative spreadsheet implementations that had a lot of cool ideas like Lotus Improv [0]. But, in the end, I just wasn't having enough fun with Prosperous Universe to keep playing after awhile.
There is a third-party API now: https://doc.fnar.net/ , which collects data through a browser extension that scraps the traffic. This kind of extension is blessed by the devs as long as it does not automate actions.
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.
the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-lib...
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:
On a new model release, you can guarantee two things are in the replies to Simon. One is your link, the other is "surely the models are being trained on this now"
Sure, but no one is trying to force art from most people into about every area in the economy where anyone ever pays for something visual. If you asked professional artists to draw a realistic bicycle, I'm guessing few of them would try to just randomly guess what the mechanical parts looked like
But if you need to draw a bicycle, you wouldn’t pick a random person in the street. You would hire an artist and you’d be guaranteed to have at least a believable one if not a perfect rendering.
No guarantees is why LLM is akin to gambling. Every new context is essentially picking someone out of the crowd.
As an aside, some of the renders have only a single side connection to the wheel and that is a valid bike design, the Cannondale Lefty front fork only has a left leg:
> 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.
> But I don't honestly think Google could have consulted their community. It's just too big.
The thing is, they frequently do. They have developer relations people, they publish blog posts about breaking changes, they work with W3C and other standards bodies, they reply on bug trackers.
But, in this case, nothing. Just a unilateral change with no communication. Not even a blog posts saying "As of April, this functionality is deprecated."
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.
Back in another part of my career I worked a lot with putting Macs on ActiveDirectory. And there was a common refrain from Apple about bugs in that implementation: "works on 17!".
The joke is that Apple owns the 17.x.x.x class-A range on the Internet (they got in early, the also have a second class-B and used to have a second class-B that they gave back), and what engineers were really saying is that they could not reproduce on the AD systems that Apple had setup (lots of times it was because AD had been setup with a .local domain, a real no-no, but it was in Microsoft's training materials as an example at the time...).
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 think asking someone if they can still reproduce an issue is valid. Especially if it was trivially reproducible for them, and now it isn't, that seems like a fine resolution, and the bug should be closed.
But in the other cases, closing the bug seems to me to be a way to perturb metrics. 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?
For your specific scenarios:
- lack of information on how to reproduce or resolve a bug doesn't mean it doesn't exist, just that it's not well understood.
- For the "new version" claim, I've seen literal complete rewrites contain the same defects as the previous version. IMHO the author of the new version needs to confirm that the bug is fixed (and how/why it was fixed)
- I agree there are high cost bugs that nobody has resources to fix, but again, that doesn't mean they don't exist (important for errata)
- Similarly with proprietary data, if you aren't allowed to access it, but it still triggers the bug, then the defect exists
In general my philosophy is to treat the existence of open bugs as the authoritative record of known issues. Yes, some of them will never be solved. But having them in the record is important in and of itself.
> 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.
Bug reports are not known defects, at any kind of scale half of them will be already fixed, misunderstandings, bad data in, or related to an unusual setup.
Closing the bug is a way of saying: sorry this doesn’t look too important and we don’t have time to look at this given the other more important things (bugs/features) we plan to work on.
If it’s closed as stale after 6-12 months (multiple humans will have seen it) OR triaged by a human and marked as won’t fix I think that’s reasonable.
> at any kind of scale half of them will be already fixed, misunderstandings, bad data in,
Here you're referring to a class of bug reports that's uninteresting for this discussion, because they're invalid (i.e. they don't represent an actual bug). We're talking about valid bugs that have not been fixed.
> or related to an unusual setup
Unusual, but ostensibly supported? Then there exists a bug.
What is the use in keeping it open when no one will ever look at it again after it goes stale? It still exists in the system if you ever wanted to find it again or if someone reports the same issue again. But after a certain time without reconfirming the bug exists, there is no point investigating because you will never know if you just haven't found it yet or if it was fixed already.
See my reply to eminence32 - bug tracking serves as a list of known defects, not as a list of work the engineers are going to do this [day/month/year].
The primary purpose is not usually a list of known defects and many ‘bugs’ are not actually bugs but feature requests or misunderstandings from users (e.g. RFC disallows the data you want my html parser to allow).
The people who filed them would disagree and many would vehemently argue that their bug is in fact a bug, and is the most important bug and how dare you close it.
Conversely, what's the harm in closing the bug? (As long as you don't lock or delete it, I agree that's bad.)
People focused on the work often interpret "open" to mean "requires work" and "closed" to mean "no planned work" in which case keeping an unreproducible bug open is dishonest because it falsely implies that someone might continue to work on it.
Whereas people focused on the problem often interpret "open" to mean "not fixed" and "closed" to mean "fixed" in which case closing an unreproducible bug is dishonest because it falsely implies that it's no longer a problem.
Neither seems right or wrong as long as everyone on the project agrees which interpretation you're using.
How is that worse? Leaving it open signals to anyone searching about it that's it's still an issue of concern. It will show up in filters for active bugs, etc. Closing it without fixing it just obfuscates the situation. It costs nothing (except pride?) to leave "Issues (1)" if there is indeed an Issue.
To some people "open" means "not fixed" whereas to others it means "more work planned". I've worked on projects with both interpretations and it's fine as long as everyone is on the same page.
> It costs nothing (except pride?) to leave "Issues (1)" if there is indeed an Issue.
In our case we omit bugs we couldn't reproduce from the issues list due to practicality, not pride -- our software has tens of thousands of unreproducible bugs and having them show up in reports would drown out planned work.
And it's not like anyone deleted or locked the unreproducible bugs, they are either tracked as "open but unreproducible" or "closed because unreproducible". Either way they're still in the database in case more information comes along, but still filtered out of the vast majority of dashboards.
Apple did not say they couldn't reproduce it. Neither did they say that they thought they fixed it. They refused to say anything except "Verify with macOS 26.4 beta 4".
> and even if they are 100% reproducible for the user, it's not always so easy for the developers
It's not easy for the user! Like I said in the blog post, I don't usually run the betas, so it would have been an ordeal to install macOS 26.4 beta 4 just to test this one bug. If anything, it's easier for Apple to test when they're developing the beta.
> the most "efficient" thing is just to ask the user to re-test.
Efficient from Apple's perspective, but grossly inefficient from the bug reporter's perspective.
> realistically I can't really do anything with it
In this case, I provided Apple with a sample Xcode project and explicit steps to reproduce. So realistically, they could have tried that.
I suspect that your underlying assumption is incorrect: I don't think Apple did anything with my bug report. This is not the first time Apple has asked me to "verify" an unfixed bug in a beta version. This seems to be a perfunctory thing they do before certain significant OS releases, clear out some older bug reports. Maybe they want to focus now on macOS 27 for WWDC and pretend that there are no outstanding issues remaining. I don't know exactly what's going through their corporate minds, but what spurred me to blog about it is that they keep doing this same shit.
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)
It always helps. Even if you can't determine the root cause you can at least add an extra assertion check or logging statement at that point so that next time the bug gets triggered you'll at least get more useful diagnostic data and can get a step close. Iterate until you find the root cause.
That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.
Ignorant question, if privacy didn’t matter and they had an atomically identical machine, would there still be plenty of edge cases where it was the printer or the Wi-Fi causing the issue?
In any case I would have said it sounds difficult on every front
I should be more precise. Capturing the system state isn’t too hard. Turning that into a reproducer may be quite hard, because of things like you say. There are certainly a lot of bugs that such a capture would make easier to figure out, but it wouldn’t be a panacea.
> 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?
It’s not necessarily harder than other aspects. However:
- It requires an AI that actually understands English, I.e. an LLM. Older, diffusion-only models were naturally terrible at that, because they weren’t trained on it.
- It requires the AI to make no mistakes on image rendering, and that’s a high bar. Mistakes in image generation are so common we have memes about it, and for all that hands generally work fine now, the rest of the picture is full of mistakes you can’t tell are mistakes. Entirely impossible with text.
Nano Banana Pro seems to somewhat reliably produce entire pictures without any mistakes at all.
As a complete layman, it seems obvious that it should be hard? Like, text is a type of graphic that needs to be coherent both in its detail and its large structure, and there’s a very small amount of variation that we don’t immediately notice as strange or flat out incorrect. That’s not true of most types of imagery.
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.
The end goal is to marry the lessons learned about HOW to learn in a virtual world with a high fidelity world model that's currently out of reach for this generation of AI. In a year or two once we have a world model that's realistic enough and fast enough, robots will be trained there and then (hopefully) generalize easily to the real world. This is groundwork trying to understand how to do that without having the models required to do it for real.
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
reply