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.

The timeline you're presenting matches what I recall, also. Nice!

That tidbit about .S vs .a is a lovely detail. "A Research Unix Reader" has other cultural details called out that're similar - https://doc.cat-v.org/unix/unix-reader/A.Research.Unix.Reade.... Two of my favourites are the idea that originally a shell script couldn't be part of a pipeline ("programs that were likely to read from shell scripts, especially sh and ed, were made to read their input one character at a time. It was impossible to pipe into a shell script because the standard input was already dedicated to the script. For the same reason a program in a shell script could not take input from a terminal except when given the terminal’s real name.") and this note from the man page for sort v1:

> A bug note in join(1) declares, ‘‘The [field-specification] conventions of join, sort, comm, uniq, look and awk(1) are wildly incongruous.’’ Although these programs are often used together, they remain, like American weights and measures, sturdily eccentric.

I remember thinking that commands were weirdly unsimilar as I was first learning them; it took this many years for me to see one of the early authors wrote an oopsie about them :)

C wasn't _later_, but perhaps you're misrecalling when Thompson had his Berkley sabbatical?

The quickest source I can find this moment for my claim is an interview with Ken Thompson in IEEE magazine called "Unix and Beyond: An Interview with Ken Thompson". Here's the quote, "At one point, I took BCPL from Martin Richards at MIT and converted it into what I thought was a fairly straight translation, but it turned out to be a different language so I called it B, and then Dennis took it and added types and called it C." You can read the whole thing at https://ieeexplore.ieee.org/document/762801 (or https://www.cs.princeton.edu/courses/archive/spring03/cs333/... if you prefer plain text).

When I write the newsletter, I'm _fairly_ sure one of Thompson's big interviews on YouTube has him call this out more clearly, but if I'm misrecalling I'll be sure to write exactly what I can figure out and where I'm sourcing the ideas from.

The specific Dennis Ritchie essay that I was referring to, though, is https://www.nokia.com/bell-labs/about/dennis-m-ritchie/portp... - "Portability of C Programs and the UNIX System". He coauthored it with Stephen Johnson, who can count Yacc amongst his many contributions to Unix.

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 :)

Sadly, this one's a myth. If you check the wikipedia page for Bug as an engineering term (https://en.wikipedia.org/wiki/Bug_%28engineering%29#History), its usage is traced back to the 1870s.

Sort of? It definitely does what's needed, but it also removes any additional environment variables that were set, unless they're in your shell initialisation files.

I'm not trying to persuade that these tools are essential or anything, just highlighting that there's a few small details some take care of that're fairly nice.

You're not wrong, but there's a small detail that your shell function doesn't solve for: unloading the environment variable once it's no longer needed.

If you maintain one shell per process-that-needs-a-secret-in-the-env then it doesn't matter, but if you're using long-running shells then direnv can load and unload env vars. It also gives you a nice little heads-up that it loaded/unloaded variables.

I've never even _heard_ of Documenters Work Bench. Looks like it cost about 2 thousand in the late 80s - https://www.nokia.com/bell-labs/about/dennis-m-ritchie/licen...

Any chance you've got any other older unix nuggets that come to mind?

I’ve been reading the 1977 Bell Labs Journal that collected everything written about UNIX up to that point. Seeing how much of its history was intimately tied to text processing and document layout was really mind-bending. I’d always assumed writing programs was Good Enough, but it was only once Unix started being used for real business at AT&T by laying out patent filing documentation that they got money for the PDP-11, which turned out to be a very important development.

It’s in reading that stuff that I grew To appreciate troff, nroff and the whole runoff family, and how CTSS was really astonishingly influential.

Author here. I don't know if we'll be writing shell scripts in five years for our jobs, but I do know that spending a few minutes writing sed makes me feel connected to my tribe of linuxy people with a love of unix history.

I also know that thinking about pattern matching is fun, it's a little puzzle solved with a skillset that transfers to other cli tools.

Post also opens with a classic interview question I've used for years: no ls on the box, five ways to list the directory tree you're in. A handful of answers at the bottom :)

We’ve been hearing the drumbeat that these models are already better than $INVENT_A_NUMBER percentage of developers at $SOME_SMALL_TASK for several years. I haven’t seen that it’s actually true yet personally.

What I do see is that the frontier models can get easy stuff mostly right, but they can’t maintain a small codebase such that it behaves correctly across several mutations. When the going requires a lot of context, tests get rewritten to not do anything and features that manipulate similar data get divergent implementations. That’s fine for goofing around personally, but I see vibe coders getting their asses handed to them when they mistake that for a well maintained codebase and try to sell a product.

Please, don’t mistake an impressive technology for a miracle; there will still be people needed to make codebases healthy for a long time to come.

Why would we trust a screenshot from Claude as evidence of how to deal with mental health issues? Surely Claude’s training matter is dominated by magazines and pop-psychology rather than thorough expert research?

This reminds me of when wobbly windows were the big thing in linux. It was good plain fun back then, it seems fun again with this.

Drawing apps do regularly allow for canvas rotation, so I’m sure this’ll turn out to be useful for some class of application that I’m not considering.

I think I'm finally understanding what bothers me in LLM usage: it's the people who just want a nice little human-ingenuity community seeing it get further away from them. I wrote this one for them, so they know they're seen.

We're all in this tooling & community evolution together.

I imagine the author's using OpenSIMH (https://opensimh.org) or something similar, so it'd be an emulated CPU running the userlands.

I have a container that runs a 4.3 BSD userland using opensimh; it's not super hard to set up, just takes a bit of patience and willingness to learn how opensimh works.

Of course it can be that this is the case. There are predictions from the dark matter hypothesis, though, that have been testable. For example, there're some of the asymmetries in the cosmic microwave background that are explained presently by the dark matter hypothesis.

Something that's worth bearing in mind is that "dark matter" doesn't actually mean "totally new never before seen thing" it means "we don't know what this matter is". So, for example, a candidate that wouldn't be super novel but could fit the bill is microscopic black holes. In that sense, the hypothesis is more mundane than it might seem.

Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.

There are reports of industries trying to use these tools to generate as much as possible, sure. There are also people generating bad art and unpleasant prose and using llms to generate nonsense they don’t pay attention to.

I don’t see why that implies that you or I lost interest in tinkering with toys we build. If I want to spend 4 weeks understanding oauth a little better by implementing a client, I still can and I still do.

Automating our builds absolutely didn’t create a cathedral of complexity while nobody noticed. It did mean I can open an Free Software project, read the build file and understand how to build the thing. That’s the opposite of generating complexity.

I worry about our future generations as much as the next person, but this low effort pabulum doesn’t represent the thoughtful industry and hobby that I love.

I had the unusual experience of Claude encouraging me to give up, so I wrote about what I think of that.

That site's so damn responsive! What are you using to build it?

More options in the ecosystem seems better, but I was surprised to see this in the linked vitest docs:

> However, to run tests in CI you need to install either playwright or webdriverio. We also recommend switching to either one of them for testing locally instead of using the default preview provider since it relies on simulating events instead of using Chrome DevTools Protocol.

I keep seeing those "I vibe coded with Claude using this one simple trick..." blog posts. I decided to write a useful one that tells you how I made progress with Claude.

What's the conversation that you're looking to have here? There are fairly widespread claims that GPT-5 is worse than 4, and that's what the help article you've linked to says. I'm not sure how this furthers dialog about or understanding of LLMs, though, it reads to _me_ like this question just reinforces a notion that lots of people already agree with.

What's your aim here, sgt3v? I'd love to positively contribute, but I don't see how this link gets us anywhere.

I've been seeing teammates go from promising juniors to people who won't think, and I've tried hard here to say what I think they're going wrong.

Like the great engineers who came before us and told us what they had learned, Rob Pike, Jez Humble, Martin Fowler or Bob Martin, it's up to those of us with a bit more experience to help the junior generation to get through this modern problem space and grow healthily. First, we need to name the problem we see, and for me that's what I wrote about here.