gwynforthewyn

I don't see how you get to the conclusion that the original commenter thinks people are being gullible.

I look at the original comment and it doesn't say anything about gullibility. It expresses frustration that there's an influx of people interested in the field of Reverse Engineering but aren't digging deeper to where the answers are. I read the comment as being more similar to the complaints of the Eternal September, when an existing culture got permanently swamped by people who wanted to interact with the tools of the culture but didn't realise there was a process to learn first.

For myself, I'm glad there's an influx of people interested in technology and being able to grasp at the tools that can deliver outcomes. I don't love seeing people appearing that want to tell me that deeper understanding is dead, not because it does me any particular daily harm but because I think there's still a lot of value in understanding the details of a topic which summaries tend to gloss over. I've been feeling this for a long time, though, it's not related to LLMs but to a culture of knowledge more fixated on soundbites than on getting at the truth of things.

In this case, I see the original commenter reflecting my own concerns, but that's so often the way: we see things as we are, not as they are, which may be colouring my read.

Reasonable minds can disagree, of course, and I respect that we may just be reading the comment quite differently.

> Swarms of RE-hopefuls are now using tools they don't understand to work on projects they don't understand

I mean, that’s just a statement of fact from the grandparent, no? I don’t see it as gatekeeping; are you focusing on some other part of the comment?

I think someone who’s aware of how to do Reverse Engineering being tired of those who’re making mistakes but advertising the output of those mistakes as legitimate discovery is pretty normal. I remember when I was learning FreeBSD that I’d show up in the mailing lists thinking I’d found bugs, but really I hadn’t read the docs well enough, and people were direct with me that I needed to do better if I threw the word “bug” around. It’s just normal peer feedback.

I would respectfully submit that trying to treat Anthropic’s models’ nonsense alarmism like it is legitimate output is closer to gaslighting. At best, the output shows that the majority of people have an alarmed tone.

I've been reading the old Unix papers; it's great learning technical details, but I'm drawn to the glimpses of the people and community and Doug McIlroy's "A Research Unix Reader" is a set of great insights into them.

I write my paper overviews by hand and human-brain. I don't say that to be elitist, but because I work hard to make these readable and digestible.

I do ask an LLM for a review pass. What I want to know is where my typos are and when have I started a thought that doesn't quite wrap up, I'm not looking for prose rewrites. Two passes from the reviewer and I'm done finding it useful.

There’s a little irony about the example you picked of the GPL, just because in the US the output of an LLM cannot be covered under copyright. The GPL works as an assignment of rights under copyright.

This is, of course, tangential to your point.

Literally 50 years of engineering history and culture cares about whether code is good. There are libraries worth of books about it, not as a means to an app but for its own beauty. Just read “The Elements of Programming Style”, for example.

Do what you want, write apps with AI and don’t review code, it doesn’t impact me. The claim that no one cares about good code is demonstrably false, and that’s all I’m objecting to.

Sorry the SSL cert was down for a few hours.

I was running letsencrypt on my homelab k8s cluster to renew the certificate, but I tore the cluster down a few months ago because I was moving home and haven't stood letsencrypt back up yet.

Namecheap only sends email alerts about non-automated renewing certificates; because the cert renewal was automated, I didn't receive any alerts. Everything's fixed now!

I've been getting a little heartbroken seeing some of the "replace every tool with AI" enthusiasm on social media, so I wrote up two simple lessons I learned because I write stuff by hand.

I realise everyone's welcome to their own toolchain; LLMs are fine. I just want to write about the kind of thing I value, and how it helps me to connect to the broader Unix community.

I <3 the BSDs, and they're the reason that the quote from "A Research Unix Reader" stuck in my memory! I started on the linuxes, pre-systemd by many years, and remember system v init levels seeming straightforwards but weird. When I switched to FreeBSD and saw /etc/rc.local, it made far more sense to me. I never even _thought_ about what 'rc' might mean, though.

Seeing the quote from Doug McIlroy many years later lodged in my brain as answering a question I didn't even have, and I've been looking for a good reason to use it ever since.

There's a lot of cool small details like that in so many early white papers about Unix; I'm looking forwards to working through a good number of them over the next 12 months. I think next I'll look at Dennis Ritchie's paper on the impact of migrating Unix from assembly to C. It may give me good opportunity to cover the B->C change as background, which is fascinating to see.

I'm the writer of this essay.

My subject is some details surrounding the first white paper that Bell Labs published about Unix was "The Unix Time-Sharing System". I wrote what Ken Thompson was doing in between the end of Multics but before he found the "little used PDP-7" that he wrote Unix on, the difference between opening files on Multics and Unix, and what the "comfile" mentioned in the paper is.

I wrote this without AI involvement; I follow Unix history because I love knowing what the history is and what I can learn from it, and I love showing others these sorts of cool details.

I'd love to hear any feedback you might have :)