JetSetIlly

> Personal computing is increasingly under threat by government and big corporations, we all need to be vigilant and fight back.

This is a very important observation. This is fundamentally about personal computing and the power to control the hardware and software we use for our work.

I recently reread "What The Dormouse Said", by John Markoff. Superb book that describes the tension between the developers of prototype personal computing on one side and distributed computing on the other. Interestingly, the need for distributed computing was motivated in part by early artificial intelligence research.

What we're seeing today IMO, is the reemergence of distributed computing. We saw it first with storage but we're now seeing it with compute itself. Given that excellent personal hardware has been available for several decades, it seems like madness to change course.

The process is often as valuable as the end result. Sure, you didn't crack the problem, but you gained enormous value in the process. I consider that a win.

Yes, there are definitely trends in which sectors sponsor F1. Most famously perhaps, the tobacco companies. Cryptocurrency was in vogue for a few years. Now it's AI companies.

Is the FIA code available for the teams to inspect, or is it just a binary blob they have to install?

> That is only "nicer" as it allows to evade taxes. (Which some may consider nice)

Card only business can definitely evade tax too and many do.

Maybe not, but the process of creation and the final result will be of interest to other creators. Like any hobby it might seem strange to outsiders but it will be fascinating to those who are part of the scene.

It's more about installation location for me. For these types of projects, I don't even install it. I just clone, build and run from there. I have no idea where the bash script is going to put things.

The albums he did with Jon Anderson are worth a listen too I think.

Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go.

Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.

> The problem isn't this weird gaslighting attempt that we just haven't let Claude in our hearts and souls yet which you seem to have determined is inevitable (spoiler alert, it is not),

I don't believe it's inevitable and in fact, I'm thoroughly against the use of tools like Claude.

My reference to "different stages of acceptance" was only to indicate that people have embraced these things to varying degrees, and it that it seems to be this difference which is causing conflict in discussions like this. (I doubt I will ever fully accept it. A lot needs to change for that to happen).

I didn't really have the "five stages of grief" in mind when I wrote it.

> This is not okay.

Agreed. The way to address it though, is through calm analysis and reason. The emotional language from both groups is not helping.

If there's one problem with Claude et al, it's that it's all happened way too quickly for people to keep up. We're all at different stages of acceptance and I think that's what we're seeing manifest in the various discussions.

> As a long-time open-source maintainer, I find all the second-guessing and armchair psychoanalysis here (not just in this comment, all over HN) about Tridge's motivations, state of mind, and so on incredibly off-putting.

Much of the language from both groups is incredibly off-putting, frankly. Tridge in his blog post describes people as "foaming at the mouth"?!

The rhetoric around this has gotten way too emotional from both groups.

I'm glad I'm just a hobbyist.

Ferrari have long worked with third-party coachbuilders such as Pininfarina. I'm not sure how much autonomy Ive had over the final design, but if it's anything like the relationship with Pininfarina, etc. the design would have been a collaboration.

> Well, that and the fact that after the 48K beeper the 128K was never going to sound less than incredible

Some of the stuff people do with the 48k beeper is incredible though. Tim Follin's tunes for example are basically treating the beeper like a 1-bit DAC, with amazing results. https://www.youtube.com/watch?v=T42WuUpBuHE

That's not enough in this case. The suggested mitigation according to the Dirty.Frag github page is to blacklist esp4, esp6 and rxrpc

Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.

Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles.

Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.

I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.

Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).

Forks can be handled by people cloning the repository and uploading a new project.

I wrote a program similar to this for AmigaOS many, many years ago. I would have been inspired by ZoneAlarm or a program like it.

I've just found it and uploaded it to github. Looking at the code, I can see my horrible C style of the time. There's probably bugs galore.

https://github.com/JetSetIlly/Direwall

If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.

It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.

Some nice ideas but the regexes should include word boundaries. For example:

git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | sort -nr | head -20

I have a project with a large package named "debugger". The presence of "bug" within "debugger" causes the original command to go crazy.

Superb demos this year at Revision. Triplet by Otomata Labs for the Atari 2600 is exceptional

Original release video (probably running on Stella)

https://www.youtube.com/watch?v=aEJ0A8Wvdxs

And a video of it running on Gopher2600.

https://www.youtube.com/watch?v=ixFH22MxqEg

I agree. Dealing with different endianness has never been an issue so long as you're aware of where the boundaries are. A call to htons() or ntohs() (or the 32bit equivalents) was the solution. I would hope all modern languages have similar helper functions/macros.

I agree. The act of coding is when I do my thinking.

I really meant in the coding realm, but it's interesting that it created a bootable floppy. That wouldn't be trivial.

Questions: 1) Which AI platform did you use? 2) Did it create a binary image of the floppy disk (an ADF perhaps)? If not, what form did it take?

> Farting around with Amigas in 2026 means actively choosing to make things harder for the sake of making things harder. Making that choice and still outsourcing the bulk of the craft and creative process is like claiming to be a passionate hobby cook while serving professionally catered dinners and pretending they're your own concoctions.

People wanting to explore the use of generative AI for vintage computers is happening not just for graphics but for code too.

I think in the case of code though, it's still interesting because I don't believe there's been any success yet. I hear of people having success with Claude in contemporary settings but it seems to fare less well when working for older computing platforms. There's a reason for that of course and it's worth exploring.

However, it will cease to be interesting as soon as the first person manages to create something substantial. At the point, the scene should probably shun it for the reasons stated in the quote.

I no longer drink in pubs but in my neck of the woods, the pubs that specialised in cask ale often had lined glasses.

The problem was that many people insisted on the glass being filled to the brim, because they felt they were being short changed. So it solved one problem but created another.

In that case I misunderstood.

It's an interesting idea. I think I prefer the exiftool syntax over what's suggested in the blog. Thanks for bringing it to my attention.

Yes, there are a few tools that do this. Looking at /bin and the softlinks that are there, the various xz tools do it (unxz, lzcat, etc.). Also, vim. vimdiff and view are just softlinks to vim.

The only difference is that those tools have chosen easy to remember names rather than embedding the arguments as metadata in the filename.

As a generalisation of the idea though, the blog post is neat.

Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.

Eternal LLMber