People who are interested in DOS software might take note of "Pits", a DOS assembler demo from 2024 which features, quote:
- Multithreading (using all hyper-threads / CPU cores)
- Video mode up to Full HD (1920x1080 / 16 bpp)
- 64-iterative ray-casting
- Pure DOS with Protected Mode (no drivers, no DPMI)
Those people should also definitely check out "Mariana" (2024), a 256 byte demo from the same author, using the same techniques, which was even nominated for the Meteoriks Award for that year.
Features:
- Multithreading (using all CPU cores & hyper-threads)
- Full HD / HiColor (1920x1080 / 16 bpp)
- 128-iterative fractal on FPU
- Pure DOS (no drivers, no DPMI)
Meta and Google are entirely advertising-focused companies, with their main revenue coming from being able to put together accurate profiles of people to spam them with campaigning attempts to get them to buy things.
Author of the OP is the VP of the adtech company, with their main revenue coming from being able to put together accurate profiles of people to spam them with campaigning attempts to get them to buy things.
He is not mad because Google can kinda-track users under new system. He is mad because Google can kinda-track users under new system, but his company _won't be able to any more_. Hence all the "cartel" talk.
I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548), one of those links goes to a larger aggregate of bugs reported downstream (https://github.com/void-linux/void-packages/issues/60825). I think it is incredibly rational and sane, given the reputation of vibecoded software as-such (where every professional who loves it is saying "you have to hold it in this very specific way so it doesn't cause bugs, and also you should probably only use it for version 0s so you can map out the domain"), for people to be angry that their load-bearing industry standard backup tool that is very, very well respected is suddenly pulling the rug out from under them because the maintainer wants to "add more features" and is doing it in what is clearly an unsafe way. Also from the timeshift thread:
> not sure if this is just me, but after updating rsync, my cpu usage got so bad during my daily backups that i had to stop timeshift from running forever
Or, phrased differently - People are frustrated and annoyed that the tool they trusted with their backups and data are seeing a huge number of regressions and new bugs that break their entire backup infrastructure, all because the main dev is vibecoding that software. Vibecoding experts like Simon Wilson explicitly state that vibecoding is 'viable' in the sense of "only if you hold the tool in a specific way", and this person is either not doing that, or that statement is untruthful. If you actually read the thread in question and just skim over the argument two people are having, there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software, simply because the software has become immediately untrustworthy in a way that directly harms users and defeats the entire point of the software in question.
I think I would also be mad if I relied on this software for my 500gb+ backups, and I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.
> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548)
There are four actual regressions there. The commits that introduced two of them have been identified, and neither neither of those mentions Claude (or another LLM).
If you look at the actual commits that credit Claude, they are not huge commits (many are a few lines), most are tests and config. This is not vibe-coding.
> there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software
If people are handling such critical data with it they will be testing upgrades before deploying to production right?
> I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.
If a backup failure would cause a $10mn loss then its grossly irresponsible to not test your backups.
I don’t think people really care about rsync or the nuance. They just want to make an insta-reaction, rant about AI, then move on to the next story that raises their blood pressure.
I don't know how deeply you read into it, but people pointed out that Claude rewrote the entire testing stack in Python. Worse than that but it rolled its own unique framework. Every test file will randomly redefine its own `_run_and_capture` function
How could we even check if either human or robot code is working properly if we're not even sure the test suite works?
Also, another user[1] compiled a nonexhaustive list of 7 issues they found introduced because of the changes.
If the 7 issues three are the same underlying issue. Another two at least relate to the same commit and probably the same underlying code. One is not related to a Claude assisted commit. That leaves three that are.
Adding that to the two in the issues further up, that makes a total of five bugs in AI assisted commits.
That may or may not be true, people are justifiably (or not justifiably) angry about a lot of things all the time.
But this was very obviously a brigading attempt. It's a form of online bullying. If it had been about whether the maintainer liked striped socks, nothing else about this would have changed.
Later on the brigade can claim "oh we had a justifiable grievance" to sooth their souls, but what actually happened is what actually happened.
It's all a bit silly and childish.
(To be sure: the balance of fao_'s statement is well reasoned. It's the brigade who are being childish, and I don't think they should be rewarded for that. )
> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding
Hi fao, the issue you linked starts with:
> Rsync 3.4.3 and newer is AI slop, and currently has several open security vulnerabilities and other critical bugs (including some link-related ones) caused by said AI slop:
It then proceeds to link to multiple functional regressions caused by (theoretically) fixes to security vulnerabilities.
This took me about 10 mins to review. It seems that the person who created the issue did not bother to spend 10 minutes to check his own work. Is this "vibe reporting"? What should we say about the irony of employing "human slop" to trash "AI slop"?
Further ironically, the "aggregate of bugs" in void-linux included an issue that was not even about rsync. More "human slop" that you are happy with?
Exactly this. The most salient comment basically said that AI use has increased the cadence of commits beyond reliable testing capacity for what was a stable product in equilibrium. It isn't an issue specific complaint so it wouldn't make sense to only flag one specific issue. In fact you'd fall behind trying to chase the AI moving head. This has everything to do with AI, and isn't a normal issue reporting situation. The other camp seems highly defensive, which reeks of indefensibility.
Gluten-free cooking has come a long way since I was a five year old with celiac eating bread with the texture of cardboard! For pizza check out the America's Test Kitchen's recipe, which apparently gets pretty close (however it might be off, I've never had wheat pizza! haha):
Personally I do a 'lazy pizza' which is just a really basic primitive bread (like how people would have made bread before yeast):
The original recipe was:
- 8oz doves farm self raising flour (or any celiac self raising flour. but doves is the og and the best IMHO)
- 1 large or medium egg
- 1 tsp baking powder
- cold water to mix (alternatively: a cup and a bit of water with 1tsp chia seeds in it, you want them in the water for about 10 - 20 minutes with regular (regular!) stirring. stirring every time they kinda coalesce at the bottom. it should look like frogs spawn by the time you're through.)
Oil pan well, put soft dough in (you want it like. soft enough that it starts to spread just a little. but not so wet that it's spreading a lot. you do NOT want it as dry as a normal non-celiac bread because there is no gluten to hold on to the water). flatten with oily silicon brush, then top. cook at 180°C for 20 minutes or so. You might want to cook it a little before topping if your toppings are cooked already. And honestly, I just eyeball the cooking time based on how it behaves.
The chia seeds help make it a little chewy, which apparently is part of how pizza dough usually reacts, as well as pulling and stabilising any moisture so it doesn't get soggy.
If software engineering wants to progress past being an "art" and be considered an engineering discipline, then it should adopt methods and practices from engineering. First and foremost, one of the universal methodologies is analysis of root cause in faults, and redundancies to avoid that. e.g. the FAA has two pilots for planes, and each system is built in redundantly so if an engineer misses a bolt or rivet, the plane won't crash. intersections are designed such that there is a forcing function[0] on the behaviour of the motorists to prevent fault. Or, to take your tool analogy, nail guns are designed to be pressed against something with a decent amount of pressure before you can fire them.
All of these systems are designed around the core idea of "a human acting irrationally or improperly is not at fault" and, furthermore, that a human can have a bad day and still avoid a mistake. They all steer someone around a possible fault. Hell, the reason why we divide the road into lanes is itself a forcing function to avoid traffic collisions!
So, where is the forcing function in large language models? What part of a large language model prevents gross misuse by laymen?
I can think of examples here and there, maybe. OpenAI had to add guard rails to stop people from poisoning themselves with botulism and boron, etc. But the problem here is that the LLM is probabilistic, so there's really no guarantee that those guard rails will hold. I seem to remember there being a paper from a few months back, posted here, that show AI guardrails cannot be proven to work consistently. In that context, LLMs cannot be considered "safe" or "reliable" enough for use. Eddie Burback has a very, very good video showing an absolute worst case result of this[1], that was posted here last year. Even then, off the top of my head Angela Collier has a really, really good video demonstrating that there's an absolute plethora of people who have succumbed, in large ways or small, to the bullshit AI can spew[2].
I feel like if most developers were actually serious about being an engineering discipline, like we claim, then we wouldn't have all jumped on the LLM bandwagon until they'd been properly tested and had a certain level of reliability. Instead there are a sizable chunk of people saying they've stopped coding by hand entirely, and aren't even reviewing the code! i.e. They've thrown out a forcing function that existed to prevent errorenous PRs being committed! And for some bizzare reason, after about 2 decades of people talking about type safety and how we need formal verification to reduce error, everyone seems to be throwing "reduction of error" out the window!
> I feel like if most developers were actually serious about being an engineering discipline, like we claim, then we wouldn't have all jumped on the LLM bandwagon until they'd been properly tested and had a certain level of reliability
Development can’t be a “serious” engineering discipline because the economics of tech companies doesn’t allow for it. But this has a lot less to do about developers, and significantly more to do with the severe pressure company executives are putting on everyone to use AI, no matter what.
But let’s be honest, many companies have adopted things like root cause analysis and blameless postmortems to deal with infrastructure reliability and reducing incidents. Making systems resilient to human mistakes, making it impossible for the typo to blow up a database, etc. are considered best practices at most places I’ve worked. On the product side, I think it’s absolutely normal to make it hard for a user to take an action that would seriously mess up their account.
The core problem happens when your product idea (say, social media) has vast negative externalities which the company isn’t forced to deal with economically. Whereas in other engineering disciplines, many things are actually safety related and you could get sued over. I’m imagining pretty much anything a structural engineer or electrical engineer works on could seriously hurt or kill someone if a bad enough mistake was made.
That just doesn’t apply to software. There is a lot of “life & death” software, but it’s more niche. The reality is that 90% of what the tech industry works on is not capable of physically harming humans, and it’s not really possible to sue over the potential negative consequences of… a dev tooling startup? It’s a very, very different industry than those other engineering disciplines work in.
But, software engineering has actually been extremely successful at minimizing risk from software defects. The most likely worst software level mistake I could make could… crash my own program. It likely wouldn’t even crash the operating system since it’s isolated. That lack of trust in what other people might do is codified everywhere in software. On an iPhone, I’m downloading apps edited by tens of thousands of other engineers, at essentially no risk to myself at all.
With the amount of AI-generated slop content on the front of HN these days, I'm honestly reconsidering visiting this site in the first place. What's the point? It seems better to curate RSS from existing known-good sources.
The art of essay-writing seems to not be something people here care about any more. If a human didn't bother to write it, why should I bother to read it?! Just post up the bullet points you would feed the LLM, and let the people who want to do so, post it into their own LLMs so they can make the Content and shovel it into their eyeballs by themselves, instead.
Scheme already has hygenic macros, I don't get why you'd vibecode a worse (less battle tested, llm-generated) replacement. I'm not sure why this hit the front-page, to be honest, because it doesn't seem noteworthy or interesting (Anyone and their mother can vibecode something like this in eight hours)
I don't think that this is very hypocritical on the part of the developer holding such views. Typing code has never been the bottleneck, building the mental model has. You need the mental model so you know how the domain and the actual model will interact, which is needed for pre-empting what tests you need, what QA you need to do, etc etc. and the limitations of the system. You can demo this out with a specification but all specifications eventually meet the domain head on, and often with catastrophic consequences, and you still need to do this sort of work anyway when writing the specification.
Fundamentally, LLM do not construct a consistent mental model of the codebase (this can be seen if you, uh, read LLM code,), and this is Bad for a lot of reasons. It's bad for long-term maintainability, it's bad for modelling this code accurately and it's behaviour as a system, it's bad for testing and verifying it, etc. Pretty much all of the tasks around program design require you to have that mental model.
You can absolutely get an LLM to show you a mental model of the code, but there is absolutely nothing that can 100% guarantee you that that's the thing it's using. Proof of this is to look at how they summarise documents, to look at how inaccurate a lot of documentation they generate is, and to look at how inaccurate a lot of their code summaries are. Those would be accurate if the LLM was forming a mental model while it worked. It's a program to statistically generate plausible text, the fact that we got the program to do more than that in the first place is very interesting and can imply a lot of things, but at the end of the day, whatever you ask for it, it will generate text. There is absolutely no guarantee around accuracy of that text and there effectively can never be.
One of the core problems we have in software engineering is the longstanding philosophical problem around creation of cohesive, consistent, objective mental models of inherently subjective concepts like identifying a person, place, etc. Look at the endless lists of falsehoods programmers (tend to) believe about any topic.
You’re right that LLMs specifically have no guarantees about accuracy nor veracity of the text they generate but I posit that that’s the same with people, especially when filtered through the socialization process. The difference is in the kind of errors machines make compared to ones that humans make.
It’s frustrating we’re using anthropomorphic concepts like hallucinations when describing LLM behaviors when the fundamental units of computation and thus failures of computation are so different at every level.
> The difference is in the kind of errors machines make compared to ones that humans make.
There's another difference, and that is that other humans can learn and study that mental model (which is why "readable code" is a goal — the code is a physical manifestation of the model that you, the programmer, has to learn), and then the model can be tweaked and taught back to the original programmer, who can then think of that tweak in the future. Programming is inherently (in most cases) a collaborative art, because you're working with people to collectively develop a mental model and refine it, smoothing it down until (as Christopher Alexander said) there are no misfits between the model and the domain.
I was an LLM naysayer for a long time. During that time I would have agreed with you. Recent experiences have changed my mind. The accuracy I get from models does not suffer from the problems you describe, and many of the issues you're describing are also true, in different ways, of human beings. There's never any guarantee that any of the text you or I produce will be accurate, or that our summary of it will be accurate, but if you ask us to generate text, we will. It recalls that funny meme: "Your job application says you're fast at math. What's 513 * 487?" "39,414." "That's not even close." "But it is fast."
Hmm. I don't see how. I'm poor so the quality of cables I can afford or buy is much worse than the average tech worker — I'm limited to either the cable that comes with e.g. my phone, or some 1.5m cables I bought from Amazon four years ago, and I've never had a flimsy or dodgy USB-C connection, even though those cables were put through hard work while I was homeless (and honestly I'm really, really surprised — they should be breaking by now).
It is a seriously technically impressive demo, if not being the most visually impressive.
reply