It is absolutely baseless to claim that any kind of content associated with LLMs (to the extent that is required for a Lobsters submission to gain a vibecoding tag, i.e. not much at all) necessarily or likely fails the topicality check.

Nothing I said could possibly be construed as making this argument. You get zero credit for building up a strawman just to tear it down.

score 1 · canonical

Lobsters has gotten much more content free, and I don’t think the problem is people posting coding projects built with AI,

From the topicality guidelines:

Some rules of thumb for great stories to submit: Will this improve the reader’s next program? Will it deepen their understanding of their last program? Will it be more interesting in five or ten years?

I find the “project I made with LLMs” posts to fall short of these topicality guidelines. Specifically I find it annoying that half of the LLM fans here will tell me that everything current will mean nothing in 5-10 years while the other half just post LLM output of the day projects. I find it hard to see how both can be relevant to my software development.

Most of the LLM output of the day projects fit much better into these off-topic examples:

… entrepreneurship, management, news about companies that employ a lot of programmers, investing, world events, … personal productivity systems, …

score 5 · canonical

I think this is another case where we need a term for “forking without forking”. The behavior of Anthropic here is that of someone forking a project. They want the same basic implementation but they want to control the future direction. The term forking has a legacy of being tied specifically to a source control action and that doesn’t quite fit. Saying Anthropic forked Mononoke would give some people the wrong impression. However the pre-DVCS impression of forking seems to apply to this and other code duplication by LLM vendors:

Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking.

https://en.wikipedia.org/wiki/Fork_(software_development)

I’m a terrible marketer but “slopforking” conveys an ickiness that matches how I feel when I read about these projects. Like eating gruel :)

score 2 · canonical

This is true but I find it almost entirely irrelevant. Everyone’s code review practices are skewed by their incentives. Therefore “code review” is not one thing and very little of it is objective.

When accepting the code from a human-submitted patch set, Linus loses none of his own productivity when rejecting the code. One of his super powers is having almost no specific productivity goals for the kernel code. He has plenty of productivity goals related to the kernel development process and he would certainly see a change-less release cycle as unproductive. However there has been no lack of supply on the change side for 30 years. When he is reviewing the code of an LLM, in the pursuit of some code production goal of his own, the quality bar for him accepting the code is lower. How much lower is an open question. However I think it is beyond debate that the demands of code review for others is drastically different than code review for our own ends.

Critically, rejecting a human-submitted patch has a long term productivity benefit in many cases. Each of those rejections is a chance for Linus to not just make the engineer better informed about the kernel but also more familiar with the processes and values of the kernel project. I think it is safe to say that no one has become a subsystem maintainer without having many patches rejected. When Linus rejects a code generation from an LLM there is barely even a signal of positive intent to discard it. The code just goes unused.

score 1 · canonical

100% Pages like this make me miss the constraints of plain text mailing lists and usenet.

score 2 · canonical

Are you saying that one of Red Hat and Debian is not POSIX, or not “proper Unix”?

Almost. I’m saying that the default bash behavior that Red Hat ships is:

• Irrelevant to POSIX (which I understand is part of your point).
• Is not UNIX, at least by the definition of OG

Then you will get different behavior on Red Hat and Debian, because on Red Hat /bin/sh is bash, and on Debian it’s dash.

Yes. I agree with that. Someone also pointed out in this thread that echo is not what POSIX-adherants use, for the same reason as noted in that HN thread. POSIX doesn’t help you because it doesn’t claim to help you.

My comment re: the UNIX certification was only in relation to my experience on Apple. You’re right that they didn’t need to patch it to satisfy POSIX. They needed to do it to satisfy OG. It’s not that bash changed between v3 and v4 or v5. It’s that bash v3 on macOS does not work the same as bash v3 on linux.

podman run --rm -it --entrypoint /usr/local/bin/bash docker.io/bash:3 --posix -c "echo 'a\nb'"
a\nb

podman run --rm -it --entrypoint /usr/local/bin/bash docker.io/bash:4 --posix -c "echo 'a\nb'"
a\nb

podman run --rm -it --entrypoint /usr/local/bin/bash docker.io/bash:5 --posix -c "echo 'a\nb'"
a\nb

It looks like their patch wasn’t so much a source patch as likely defining:

config.h.in
68:/* Define DEFAULT_ECHO_TO_XPG if you want the echo builtin to interpret
69-   the backslash-escape characters by default, like the XPG Single Unix
70-   Specification V2 for echo.
71-   This requires that V9_ECHO be defined. */
72:#undef DEFAULT_ECHO_TO_XPG

score 1 · canonical

Apparently it’s not a bash version difference. It is an Apple patch in order to make make macOS into a proper unix: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified/answer/Terry-Lambert

score 1 · canonical

I understand the pain points when it comes to trying to adhere to POSIX. I don’t do it myself. I think shell differentiation is good. I think the benefits of non-standard features outweigh portability.

I think there might be something in your example that is clear to you but not to me. The last line claims that POSIX doesn’t save you but if you opt into POSIX it does, even in bash.

What I was envisioning, bash invoked as /bin/sh behaves like the other shells you mentioned:

/bin/sh --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin26)
Copyright (C) 2007 Free Software Foundation, Inc.

/bin/sh -c "echo 'a\nb'"
a
b

It’s somehow detatched from the actual POSIX opt-in behavior though because:

/bin/bash --posix -c "echo 'a\nb'"
a
b

score 1 · canonical

Right, but how is that program evaluated by bash when it is invoked as sh?

score 1 · canonical

I don’t see the high contrast filter in effect. If anything I see social division between people who push every discussion into “give it to AI” or “here is a copy of what Claude says” vs others who have grown tired of every conversation moving in that direction and giving up on group discussions.

score 1 · canonical

Sure, you can coax better prose out of the machine. However it seems like your argument boils down to “defaults don’t matter.” Are you intending to argue more than that?

score 1 · canonical

Team Fallout: the opposite, actually; now we have way more time to talk architecture and product future; coding doesn’t distract too much anymore

This has been the exact opposite of my experience. There is no more time, just more unreasonable expectations for productivity. In the few cases where there is more time, my teammates mostly use it to privately entertain some fanciful “that would be cool” ideas that are pretty far afield from the team’s product.

score 1 · canonical