rootnod3

Or why you shouldn't....

I am not contesting that stackoverflow isn't bad in many regards, but to equate that to massive PRs or code changes done via AI slop is a different level. At worst, you might get a page or two out of stack overflow but still need to stitch it together yourself.

With LLMs you can literally ask it to generate entire libraries without activating a single neuron in your nogging. Those two do NOT compare in the slightest.

Another difference: stack overflow tells you you are wrong or tells you and do your own research or to read the manual (which in a high percentage of cases is the right answer). It doesn't tell you that you are right and proceeds to hallucinate some non-existent flags for some command invocation.

Difference: companies are not pushing their employees to use stack overflow. Stack overflow doesn't waste massive amounts of water and energy. Stack overflow does not easily abuse millions of copyrights in a second by scraping without permission.

"I have seen some people be quite successful with this."

Wait until those people hit a snafu and have to debug something in prod after they mindlessly handed their brains and critical thinking to a water-wasting behemoth and atrophied their minds.

EDIT: typo, and yes I see the irony :D

Sorry, but why would including the prompt in the pull request make any difference? Explain what you DID in the pull request. If you can't summarize it yourself, it means you didn't review it yourself, so why should I have to do it for you?

It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires.

Seriously, long term thinking went out the window long time ago, didn't it?

Ok, now assume you start relying on it and let's assume cloud flare has another outage. You just go and clock out for the day saying "can't work, agent is down"?

I don't think we'll be out of jobs. Maybe temporarily. But those jobs come back. The energy and money drain that LLMs are, are just not sustainable.

I mean, it's cool that you got the project knocked out in a month or two, but if you'd sit down now without an LLM and try to measure the quality of that codebase, would you be 100% content? Speed is not always a good metric. Sure, 1 -2 months for a project is nice, but isn't especially a personal project more about the fun of doing the project and learning something from it and sharpening your skills?

I don't think the chess analogy grabs here. In chess, you play _against_ the chess computer. Take the same approach and let the chess computer play FOR the player and see how far he gets.

Might be a weird suggestion but here we go: - use whatever diff tool you used before LLMs came around and actually review the code? Just a suggestion. If people claim they always examine the full output at the end before they commit it, then why not fully review it using the tools used before the dawn of LLMs?

Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?

Maybe unpopular, but papers should be in n markdown flavor to be determined. Just to have them more machine readable.

It's my goto for new languages, but Gameboy instead of Chip8. It covers good parts of new languages when learning them.

Yes. The AI companies for the token usage.

My first manager at Amazon was like that. Loved him to pieces. He didn't micro-manage, he didn't even fully care about the scrum. Just said "I can see the ticket status myself. If you are blocked by something, need any info or resource, I'll hunt it down for you, otherwise you keep cooking".

Famous last words of empires. I doubt that if current situations continue that the US will in any sense be still thought of as the reserve currency.

Count how many services you have that are not already defined by the system itself in its order? So, remove core system services. System itself should already make sure that USB starts after PCIE and all that.

So go and count all the services that are not base install and tell me how many you have.

Still daily driving an old x220 and a T480. Last time they were actually decent. You can pry them out of my cold dead hands.

I wish they'd make something like the x220 again.

Best practice would be to pack the service into a jail and then use `ractl` to monitor I/O. Could also then monitor the VNET socket of the jail for network stats.

Or you just grab the PID and get it through that. A bit more manual, but composable.

Here's an idea for LLM makers: allow for a very rigid and structured Claude.md file. One that gives detailed instructions, as void of ambiguity as possible. Then go and refine said language, allow maybe for more than one file to give it some file structure. Iterate on that for a few years and if you ever need a name for it, you might wanna give it a name describing something that describes a program, or maybe if you are inclined enough....a programming language.

Have we really reached the low point that we need tutorials on how to coerce a LLM into doing what we want instead of just....writing the god damn code?

The just released FreeBSD 15 for example as a major release is supported until end of 2029, how much more LTS support do you want?

The minor point releases are close to a year in support. And that is only talking base system. Packages and ports you can also easily support yourself with poudriere and others.

As for backwards compatibility: FreeBSD has a stable backwards compatible ABI. That is why you can run a 11.0 jail on a 15.0 host. With zero problems.

Other way around is what doesn't work. You can't run a 15.0 jail on a 11.0 host for example. But backwards compatibility is definitely given.

[1]: https://www.freebsd.org/releases/15.0R/schedule/

Do we now need https://unkilledbygoogle.com?

Spin up a VM, may that be locally or a cloud VM, throw an OpenBSD or a FreeBSD. If you are into mail servers, static http etc then OpenBSD might be your jam. Or try FreeBSD and Jails. Jails are absolutely fantastic.

Ditch the LLMs (not insinuating that you use them, but just in case), try to use the Handbooks and the man pages.

If you ever feel the need that you have so many interdependent services that you need something more complex than RC, then you might have an actual architectural problem to be honest.

It's up to you to say check in your init script if you need to start another service before you.

In terms of uptime or IO and stuff, those metrics are already available. Be that via SNMP or other means. Say you start an nginx in systems, which network and disk usage does it report? Just the main process or all its forks? Same problem in RC.

But that is part of the point. Why in the ever-loving existence should an INIT system provide stats like disk usage? That is NOT what an init system is for.

If you need memory usage or IO usage or uptime, there are so many other tools already integrated into the system that the init system doesn't need to bother.

Init systems should only care about starting, stopping and restarting services. Period. The moment they do more than that, they failed at their core job.

This might came across stronger than meant to, but still holds true.

BSDs are about "keep it simple, keep it single purpose" to a "I can live with that degree". What you get though is outstanding documentation and every component is easily understandable. Prime examples are OpenBSD/FreeBSD PF. That firewall config is just easy to grok, easy to read up on and does 99.999% of what you ever need out of a firewall.

Isn't the whole point of AoC to NOT use AI? Even says so in the FAQ

Addendum to my other reply: it comes down to the "not invented here" problem which always invites weirdly complex solutions to problems that don't exist.

Linux is "just" the kernel and every distro invites new solutions to perceived core problems whereas the BSDs have a whole base system that comes from one source, reducing the chance of a systemd popping up there. Both approaches have their ups and downs.

It autodiscovers the dependency chain or shit like that? If you got 500+ services that need to be orchestrated you honestly have a very different problem.

I love the simplicity of RC scripts. Easy to understand, easy to debug, it just fucking works.

Simplicity is king, because it's understandable. A behemoth like systemd feels like it requires a PhD.

Systemd also runs 100% against the Unix/Linux philosophy of composability and single purpose.

SBCL is an absolute beast. I think only surpassed by LispWorks, but SBCL is a miracle machine. Even without type annotations it usually performs well enough.

It is unnecessarily complex to begin with. On top of that, the maintainers are historically not the most open to criticism and try to aggressively push the adoption. So much so that Gnome for example now has very strong dependecies on systemd which makes it very difficult to adopt Gnome on non-systemd systems unless you wanna throw a bunch of patches at it. This hard coupling alone is something that I wouldn't want to rely on, ever.

My personal choice is always Common Lisp. Absolute swiss army knife.