> 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.
Tridge in his blog post describes people as "foaming at the mouth"?!
Did you see the picture in the article where the user posted a picture of them strangling the maintainer? I think “foaming at the mouth” is probably gentler than how I would characterise that.
IMHO, the whole episode is just embarrassing. I have no doubt he’s just trying to do the right thing. You can disagree with the tactics, but the vitriol is outrageous. rsync is a gift to the world and we should be grateful and mindful of how much it has been quietly woven into the fabric of computing. rsync is taken for granted. 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.
I do hope you see the irony of accusing people of armchair psychology and then hitting us with the five stages of grief.
I trust rsync (which handles critical data on my system) because I know a veteran of 40 years wrote the code it runs. If I see code like the one above posted by the OP, that the author wouldn't have written, I start to pay attention. When I then read the blog post of him saying that he'd "rather go sailing than fix rsync issues", I start to question whether the software is still written in a way I can trust and where it's going quality wise.
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), it's that a bot wrote crappy code and I wasn't even aware I was running it and now don't know to what standard this project is held.
Which is part of the problem with all of this nonsense right now - everyone is running off of emotion and not looking to see if what is being said is actually true. Which is somewhat ironic, considering the message of the article.
> 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.
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.
And the press-release [0] sounds like Ferrari had very limited creative control:
"Introducing a team from outside the Ferrari Design Studio led by Flavio Manzoni invited a new perspective and cross-fertilisation, enabling a new design language to be introduced."
"LoveFrom was given the creative freedom needed to define the design direction of the project from the outset, translating this design language into an authentic Ferrari experience."
> 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
Yeah, when I had the 48K Speccy I bought this and a shoot em up called Chronos, which wasn't by any means an amazing game (not bad for the £1.99 or £2.99 I paid for it, mind), but it was blessed with incredible intro music, which I think might have been another Tim Follin special.
It's not to say amazing results from the 48K beeper were impossible, but you had to work pretty hard for them, and you were definitely into wizardry territory.
But, it's also true that the sound capabilities of the 128K machine were a big step up (also worth bearing in mind you had the beeper and the AY chip - you weren't losing the beeper).
Aha - and as if by magic... yeah, I just mentioned that the 128K machine had both the beeper and the AY chip, and this is a great example of them in use together.
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.
Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.
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.
This needs a small tweak to work on macOS, where git uses the POSIX version of grep (which doesn't support `\b`). You need to use the Perl Regexp option by switching -E with -P:
Word boundaries are one way to address that, but they require you to list all the inflections (and you missed “fixing”). Another way is to say (?<!de)bug.
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.
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.
reply