assuming you still have it, it wouldn't be the worst idea to update the pic to something without chromatic aberration and motion blur. the wiki pic is probably the worst of the bunch compared to others on google image search :)
If any legit museum, or attorney involved with Fourth Amendment issues, would like it, please contact me at nagle@animats.com. It's just sitting around.
I bought it on eBay years ago, out of curiosity, and fixed it. I built a little control box to go with it, with a phone dial and a 9V battery, and found a source of paper tape and ink. So it can be demoed. If it ever is used in a court appearance or legislative testimony, that would be better than it sitting in a box.
Yeah I find the phone-taken images much worse than camera-taken even despite the astonishing number of megapixels and amount of technologies promised in the phones nowadays. Sadly most people don't buy the camera because it's too expensive and you need prepare yourself to take it with you (so the most photos are taken instantly with the phone)
I was nerd-sniped by the above link (which I've added spaces to, to keep it from being truncated) and thought "Huh, since when does Wikimedia Commons use tracker barf?" So I found the page for this image:
then copied the full-size image's link... and sure enough. I guess they want to keep tabs on sites that hotlink their images and don't even practice good link hygiene.
It's possible to do a large amount of AI-assisted work, then do a second/third/fourth pass to break it up into a reviewable stack of self-contained PRs. But it takes time, and there's no such thing as one-shotting it. And it's basically impossible to continuously rebase manually without burning tokens. The way to merge the stack is more-or-less "stop the world".
However, I have yet to see how this will play out with upstream contribs:
Isn't it just great how a decision made by some genius in Microsoft decades ago caused so much confusion and mess. Even on Windows 11 the default is to hide extensions, because, geez, wouldn't want to confuse people with change after decades of it being like that.
Although, was the hiding something that the Mac introduced?
The idea of the last part of the filename (after the period) determining what program is launched to handle the file is odd anyway...
I wonder if the Windows spyware infrastructure measures what % of people turn off extension hiding..
> The idea of the last part of the filename (after the period) determining what program is launched to handle the file is odd anyway...
I challenge you to suggest a better solution - the best that Linux came up with is a giant database of all magic numbers known to God and praying that something matches... sometimes it does, and sometimes it even matches the correct program.
But relying on them to tell the OS what type a file is, or allowing them to change the extension, isn't good either. lena.jpg doesn't become lena.pdf by changing the last 3 letters of the filename..
It gets really complicated when you get into overlapping file types, like with ISOBMFF. An .mp4 can also, simultaneously, be a valid .3gp because those are profiles of ISOBMFF. On the other extreme, JPEG is secretly two different incompatible formats (JFIF and Exif), and a video file with a different codec in the same container, or even a different track layout, might as well be a different format.
Some file formats, eg png, require a particular file header in order to be considered valid. This is true regardless of your operating system, be it windows or linux. If that is hidden information, then it is hidden regardless of which operating system you're on. On windows, if I have a png named .doc, then there is absolutely no way to determine that it is a valid png and could be opened with my image viewer with standard tools. On linux it will recommend you open the file with an image viewer regardless of the file extension. That seems to me like significantly less hidden information.
> On windows, if I have a png named .doc, then there is absolutely no way to determine that it is a valid png
And that's a good thing. Imagine receiving a file called "very_funny_cat.png" and Linux realizing that while it's not a valid PNG image, it is a valid ELF executable.
The sane option would be to change the file explorer to have a column/field of "What type of file we've detected it is". We already do this for directories. Nowadays we just rely on naming convention that the last 3 letters of the name identifies correctly what the file format is.
Right, linux should instead go by the normal extension for an elf, which is no extension... instead this problem is solved by prompting the user if they want to execute the program.
The mac started out without using extensions at all, the type was embedded in the metadata. That's still possible now, but it's largely derived from extensions first. I believe Finder shows all extensions by default. It certainly does in details mode.
That really is a superior way of doing things too. Or at least it would have been if that metadata were transferred with the file itself in all protocols.
Being stuck on versions of PHP published >= 8 years ago isn't a valid excuse anymore, with AI and static analysis tools available IMHO. And even if you really don't identify using CVE-ridden, unsupported, ancient software to handle customer data as a critical business risk and insist on riding the burning train instead - well, then you've lost all right to poke fun at the legacy PHP versions you're stuck on, because the pain is entirely self-inflicted by your org.
Codex is freakin hot-to-trot to churn out test coverage for every single thing it implements, and some of it is very esoteric and highly prescriptive (regexes for days) BUT .. after a while, it dawned on me that LLM-driven test coverage is less about proving “code correctness” (you’re better off writing those tests yourself alongside them), and more about just trying to ensure that whatever gets bolted on stays bolted on. For better or worse, obviously, since if you bolt on trash, trash you shall have.
Wholeheartedly agree, but in fairness, I trust the tests of the best AI models more than those of the average human developer. There's a lot of people around that combine high diligence with complete intellectual laziness, producing tons of useless tests.
Actually no, cancel that. I realise now that I trust AIs more than the average developer, period. At this point they do produce better code than most people I've dealt with.
however, if you have SVGs already, compare those without rasterizing them first, then if that fails rasterize & odiff the baseline and new on-demand. this way you dont waste a ton of space storing a bunch of binary [possibly evolving] pngs in git.
Claude: "Hold my beer."