skydhash

> What we are discussing here is: is it acceptable to accept poor code quality and trade it off with delivery?

I found that people that lean towards the latter also favor profits over customer satisfaction. Then they will try to defend themselves with a black and white view “it’s either this scrap or no delivery”.

I also don’t understand the need for a monorepo. Just publish your deps. Your projects can just download the latest. Or there can be some monitoring so that they don’t lag too far behind. The monorepos I interacted with always make things messier with CI and testing.

> Why do you care, it's not like anybody's shoving it down your computer

They are trying to get in every opensource projects, increasing the burden of maintainers. And once a ban is announced, they’re here protesting.

> I am one of those people that reinvents the wheels because external ones don't fit my use cases

That’s OK, but I’ve yet to see someone articulating what exactly doesn’t work in the old product. It’s always “Let’s rewrite or reinvent 90% of it, then add a minuscule variation”. The variation may be interesting, but the reinvent is what’s make it untouchable as no one (including the author) has time to ensure things are right.

A patch or a plugin is ok, but not a whole new project with dubious claims.

> Now teams can build lots of stuff that works great, except it's the wrong things.

That used to be called "time wasting". If you want to build software that will be used, you need to interview the users. Maybe a few things does require research to nail things right. But most software are user-facing, the research side is about optimization.

> Most things are becoming the understand the problem "shape".

Then should we be so reluctant about "trialing" invented solutions. It's the same thing with most AI projects, they're trying to justify the project after the facts while being very reluctant to get user insights.

> However, a lot of productivity is going into things like that. Have you always been bothered by the limitations of Grafana? You can generate another dashboarding solution that works best for you. [...] The browser sandbox is limited? Make a desktop app, make a language, make an OS, make a kernel.

This is one of the core reason that I dislike the LLM hyping. People are just reinventing stuff and when you ask them, it's actually a very subjective reason. Ok, anyone can do what they want with their time, the issue is that they want people to follow in their steps.

Not saying that you need a novel idea to be worthy, but those random projects have no guarantees behind them other than some cursory testing. All software have bugs, but I can't interact with something that is randomly built.

I don’t trust them for privacy. I like them for the lack of annoyance. All their competitors seems to want to hinder any activity I want to do. Ads, nagging, notifications, … It’s basically a mental tax.

And a lot of C/C++ library are incredibly mature, so no need to update your code every 3 months just for dependency updates.

> But also because humans aren't all that great at code review when it comes to correctness and security. Part of the problem is that you don't have access to the author's mental model for non-trivial changes and have to reconstruct it, otherwise your understanding of the program logic will be inadequate.

Code review is not really about correctness and security. We have testing and other verification process for these. Code review is about idea discussion mostly and correcting a few stuff that may have slipped through the author's initial review.

Your PR wants to change the software in some way. My review is to comment on how you've implemented that change, like did you miss some areas where you needed to change, does your description is actually what is happening (either a cursory reading or through testing), or are you doing some unnecessary change.

IMO, the initial reading shouldn't take more than 10 minutes. More than that (so a big diff) it should have been discussed upfront, and the design agreed. If it's an important area, a more careful reading should be done about the tests and relevant stuff.

But generally, if a review takes more than 10 minutes, there's some failure of communication going on (reviewer not apt to understand the change, big diffs that should have been discussed outside of the PR, obtuse code,...)

There's a wide spectrum between specs upfront vs trial and error with the codebase. Somewhere in the middle sits the whole MVP and iterative building, where you start with a smaller codebase and fill it up. Basically exploiting the fact that a lot of concepts, while interconnected, are modular and can be tackled on their own. Like how the design of the brakes and the engine in a car, while related, are mostly blackboxes in regard to each other.

People that do trial and errors lacks direction and their code is often fragile, especially with evolving situation. Because their have failed to grasp the deeper truth of the domain. The usual signs are tightly coupled code and code churn.

> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development.

I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible.

> Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it

I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering.

> and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.

A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.

> How will they know if an LLM wrote the code? They won't

They don’t need to know. The policy is not a linter that will scan each PR. Just like the law does not monitor everyone 24/7 for criminal behavior. It’s enough that the rule is in place and it’s enforced when they catch an infraction. No need to be perfect as long as it lowers the pain.

The bottleneck they feel during coding is the lack of knowledge. Knowledge of the technical platform and knowledge of the deeper implications of the task’s requirements.

I’ve mentored juniors and the common trait is that they rush to code without understanding, then they spend days trying to fix things. Coding will seem like a real bottleneck for them.

> but staying aligned with it, knowing what it does and whether it does what you meant

That’s the old “Programming as Theory Building” stated by Peter Naur. Writing code, once you learned a language and a few libraries has always been easy and can be made easier by using tooling. Having a good understanding of what has been written and what needs to be added is the difficult part.

I think for every line of code I’ve written, I spent 2 to 5 hours reading specs and docs. Creating software is always about understanding. If you’re thinking too much about syntax and libraries symbol, you’re just at the beginner phase of coding. Like thinking about grammar when learning a second language or being hyperaware of the car as a beginner driver.

> If human coders become the bottleneck in the chain, the solution is obvious and there's only so much protection anyone can do.

Which chain? It’s not like there’s much productivity going on. There’s a lot of activity for very little impact.

Banning does not imply verification. The policy is just a warning. So now you know, if they suspect that a PR is AI-generated, then there may be further consequences. I don’t think someone is going to apply a stamp on each PR.

The most egregious examples are always lazy (big diff, lengthy descriptions, weird phrasing,…). Now there’s a section in the policy to point to for the quick rejection.

> When people use words like “chatbot” to talk about their AI use and can’t really name basic things like the model they were using, it reveals a wide chasm between the people who are deep into understanding how to use these things and those who poke at easy options every few months and then look for ways to confirm their priors instead of trying to understand how other people are getting value.

While the latest and newest should be needed for greater capability, the average should be enough to give a glimpse pf what is possible. Like a basic netbook is enough to enjoy computing, no need to purchase the latest supercomputer.

If you need to switch your setup every quarter or so, it’s not a tool, it’s a rat race.

Humans are not immortal and cannot spend all their time into review (especially unpaid). Even today, there’s so much knowledge around that you have to be specialist of a narrow domain to get to the frontier. Even in computing which is just approaching a century of existence.

> It just looks like the same old vile maxim, all for ourselves, and nothing for other people.

  We have no choice, we must tax the common people.

  The Uprising (2026)

And some do require design thinking. Like sndio or alsa, drm, caddy, … With no domain expertise and technical knowledge, a lot of software are out of scope.

The calls are intrusive because a lots are not actually needed. You can send all the context needed in the first message and then I can reply with the exact answer later on.

I don’t mind if it’s something urgent or you need an answer now. Or just want to do small talk (very close friends). But if it could be a message, just send one.

Unix file protection with owner/group is OK too. But would you create additional users and groups for running software? With OpenBSD’s pf, you can add network rules for each user.

You may need a general knowledge in device and device drivers in Linux (the BSDs behave the same but follows a simpler approach). Basically the naming scheme is based on the driver name with numbers and letters appended for device ordering. So sda1 means scsi disk (sd driver), a for the first one, and 1 for the first partition. Linux added a few folders and scheming for better interactivity.

/sys is powered by sysfs, which is actually a database as file and folders. OpenBSD doesn’t have it (and /proc too), so if you need to interact with kernel objects, you need to use C and the system library. But on Linux, you can do a lot with basic read and write on files.

I tried using various configurations tools and to this day, unless it’s needed for a project, my strategy is “don’t bother”. When I use a program for a while, I backup the config somewhere and perhaps write a few notes, but my daily setup vary enough and last enough that I wouldn’t replicate it.

My mac setup hasn’t been replaced since 2021 or something, and it was copied from my old mac. I have a dotfiles git repo, which I drag around and have multiple branches for my daily driver. For temp setup, I just copy files and edit.

> but nobody in decades thought to make this information accessible to the programmer

Isn’t this implementation details, and an information already available caller side. It would be like returning the filename for a file handle. The more extraneous details in an API, the less flexible it is.

> But, in 2026, I don't see why for native code everyone shouldn't be programming in Rust / Swift / other modern memory-safe flavor for any new production use. Zig if you want faster compile times, I guess.

Because C is very simple (unlike Rust) and works everywhere. Zig is not yet stable. Go and Swift are under the governance of tech companies.

The true appeal of C for me is the standard and how it applies only to the language. You can easily take a project from 2 decades ago and port it to a current platform. Lot of current ecosystem is way too fussy about tooling to do this.

> It's not something people want or care about, it's just a tedious detail.

It’s not something idiomatic, but indexing in C is syntactic sugar. Not sure why they allow it in the syntax, but forgetting that arrays are pointers and not special type is just asking for bugs.

> C is wonderfully simple at times.

Yesterday, I watch a quick video[0] where Matthew Butterick was comparing book sizes and their appeal. “The C Programming Language” was my second programming book (after one about JavaScript 1.x) and I still remember it fondly. Easy to start with (with CodeBlocks on Windows and gcc on Linux) and the concepts were nicely explained. The book were also very nice.

[0] https://www.youtube.com/watch?v=W-ryv6TwQvM

> Who gave the AI access to huggingface when it hacked it?

The LLM doesn’t run on thin air. Someone did launch a tasks and the result was this. “We were playing russian roulette” is no excuse when someone died.

The terminall bell is just the representation of ascii for 7 (decimal) or Ctrl+G. I believe all terminal do support it, although most emulators allows to make it a visual effect instead of a sound. And they usually send a notification to the desktop environment or windows manager.