> But you don't fire a table saw because it doesn't know when to stop cutting, right?
If I purchased a table saw and that table saw irregularly and unpredictably jumped past its safeties -as we've plenty of evidence that LLMs [0] do-, then I would [1] immediately stop using that saw, return it for a refund, alert the store that they're selling wildly unsafe equipment, and the relevant regulators that a manufacturer is producing and selling wildly unsafe equipment.
[0] ...whether "agentic" or not...
[1] ...after discovering that yes, this is not a defective unit, but this model of saw working as designed...
> But that's the thing: the table saw has safeties. Someone put them there.
You noticed that I mentioned that this hypothetical table saw has poorly-designed, entirely inadequate safeties? Things like Opus treating the data it presents to the user as commands that it should execute [0] is definitely [1] a sign of solid, well-designed safety mechanisms.
You might choose to retort "Well, that's because the user isn't running the tool in the mode that makes it wait for confirmation before doing anything of consequence!". In reply, I would point in the general direction of the half-squillion studies indicating that a system whose safety requires an operator to remain vigilant when presented with a large volume of irregularly-presented decision points (nearly all of which can be safely answered with a "Yes, do it.") does not make for a safe system. [2] It -in fact- makes for a system that's designed [3] to be unsafe.
You might also choose to retort "That's never happened to me, or anyone that I know about.". Intermittent failures of built-in safeties that happen under unpredictable circumstances are far, far worse than predictable failures that happen under known ones. I hope you understand why.
[2] I would also -somewhat wryly- note that "An AI Agent that does all of your scutwork, but whose every decision you have to carefully scrutinize, because it will irregularly plan to do something irreversibly destructive to something you care about." is not at all the picture that "AI" boosters paint of these tools.
I'm not sure that HN vote count is a good indicator of interest? HN alerted me to the existence of the intro post. I read the intro, noticed that it was one in an ongoing series, and have been checking your blog for new installments every few days.
I suspect that if you'd not broken up the post into a series of smaller ones, the sorts of folks who are unwilling to read the whole thing as you post it section by section would have fed the entire post to an LLM to "summarize".
> time that anti-terrorist units use to track you down.
Speaking from the perspective of a USian, I wish Federal law enforcement was that hypercompetent. (If they were, perhaps folks would stop to question the ever-broader expansion of 24/7 surveillance of ordinary folks.)
The distressingly-complete Panopticon that has been built over the past several decades [0] makes it really easy for them to get you when they know to search for you, specifically. History (both recent and not-so-recent) has shown that if they don't know who they're looking for, or don't even know that they should be looking for anyone, they're just godawful.
[0] ...and whose continued construction is vociferously cheered on by folks on all sides of all of the aisles...
To play devil's advocate, it's not inconceivable that machine learning may eventually allow well-heeled governments to finally realize the dream of finding needles by building sufficiently large haystacks, or at the very least coerce otherwise unruly citizens into compliance based on the belief that it is able to do so.
> ...or at the very least coerce otherwise unruly citizens into compliance based on the belief that it is able to do so.
I would argue that that day is already here, and has been for quite some time. (What makes this worse is that some agents of the State also believe that they have this capability, which results in profoundly unjust and substantially damaging results.)
> ...it's not inconceivable that machine learning may eventually allow...
Sure. I agree. It may eventually allow. There's no question about that. The thing is that 'cowl' was referring to the situation right now, not the one in some unspecified distant future.
As to law enforcement policy; as we mechanize [0] our policing and law enforcement, we must put additional constraints on the people who police and enforce the laws to keep the harm they can do to uninvolved innocents to a minimum.
Our laws already recognize the need for this: ask yourself why -in the US states that have such laws- nonconsensual audio recording of telephone (and other such) conversations is not permitted, but taking notes by hand is always acceptable. [1]
[0] Electronic machines are machines, too, you know!
[1] "You can't prove that someone took notes by hand, so it's pointless to try to stop it." is not a counterargument... you can't prove that unless you find the notes, just as you can't prove that someone recorded the audio of the conversation without finding the recording.
> I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory.
Firstly: If that user has explicitly disallowed access to a particular directory in a system-wide filesystem access control dialog, the intent to prevent access to that directory seems completely clear. In cases like this, it seems fine to me to have a "Grant read/write/list permissions to this directory? [Once] [Forever]" dialog that this access attempt causes to pop up.
Secondly: Directories with XY3 or XY1 permissions are not unheard of. If you want programs to be able to access a directory but not be able to list its contents, that's what you'd do. Perhaps you don't want people to be casually able to read the metadata on files in that directory. I have a vague, distant, and extremely unreliable memory that tells me that this was a technique used by some *nix mail or print spooling software way back when, but... "extremely unreliable memory".
This configuration would probably cause most GUI file pickers to shit their pants, but there's absolutely nothing that says that you need to have either 'r' or 'w' privs to a directory for a GUI file picker to actually function. Nearly every one of them that I've used contains a text box that you can use to punch in path components and filenames.
> It's most Americans having better shit to do than running a truck of fertiliser and oxidiser into a pylon.
FWIW, it's most people having better shit to do, regardless of nationality (or lack thereof).
But, yeah, anyone who takes a few weekends to understand how large-scale infrastructure works and consider why it's possible for nearly all of it to remain untargeted by saboteurs inevitably develops a resistance to the "Lots of Bad Guys are trying to kill us all the time, so we must enact $AUTHORITARIAN_POLICIES immediately to prevent them and keep us safe!!!" type of argument.
My favorite example of this is the realization that a terrorist attack on a crowded TSA security checkpoint over the holidays would likely result in at least as many casualties as bringing down a commercial aircraft, with similar if not better odds of success (assuming, of course, the aircraft wasn't successfully used as a missile).
Same goes for concerts, sporting events, political rallies, and at least historically, shopping malls. Yet if anyone were to suggest a prohibition against carrying liquids in containers larger than 100 mL to the Indy 500, race fans would riot, despite a far larger and denser population than any aircraft.
Yeah. Everyone with half a brain who wasn't on their knees gagging for more of the sweet "Homeland Security" money was saying things like "If an attacker makes it to the TSA checkpoint, you've lost." and "The fact that no one has attacked the massive crowds at a checkpoint or other public gathering is yet more proof that this is all extremely expensive theater.".
> ...if anyone were to suggest a prohibition against carrying liquids in containers larger than 100 mL to the Indy 500, race fans would riot...
I'm not sure of that at all. Fans of other sports seem to have gleefully swallowed all sorts of "security" restrictions [0]. I don't see why Indy 500 fans would be signficantly different. Cut the price of water in half along with the change in "security" policy, and I bet many folks [1] will cheer it as a great convenience.
[0] That -totally coincidentally- happen to make the folks running the event significantly more money.
[1] Are these folks actually robots operated by PR firms who are hired to astroturf "positive sentiment" for unpopular changes? Who can say?
I bet colos will plug a KVM into your hardware and give you remote access to that KVM. I also bet rachelbythebay has at least one article that talks about the topic.
> ...can't scale if you suddenly had a surge of traffic.
1) If your public server serves entirely or nearly-entirely static data, you're going to saturate your network before you saturate the CPU resources on that laptop.
2) Even if it isn't, computers are way faster than folks give them credit for when you're not weighing them down with Kubernetes and/or running swarms of VMs. [0]
Yeah. I got bored a couple of hours after I posted that speculation and found several other colo facilities that mentioned that they'd do remote KVM. I'd figured that it was a common thing (a fair chunk of hardware you might want to colo either doesn't have IPMI or doesn't have IPMI that's worth a damn), but wasn't sure.
You (the person paying to co-locate hardware) don't buy the KVM that the colo facility uses. The colo facility hooks up the KVM that they own to your hardware and configures it so that you can access it. Once you stop paying to colo your hardware, you take your hardware back (or maybe pay them to dispose of it, I guess) and they keep the KVM, because it's theirs.
k8s doesn't really weigh you down, especially if tuned for the low end use case (k1s). It encourages some dumb decisions that do, such as using Prometheus stack with default settings, but by itself it just eats a lot of ram.
Now using CPU limits in k8s with cgroups v1 does hurt performance. But doing that would hurt performance without k8s too.
> k8s doesn't really weigh you down, especially if tuned for the low end use case (k1s).
Sorry, what "k1s" are you referring to? The only projects with that name that I see are either cut-down management CLIs and GUIs that only work with a preexisting Kubernetes cluster, or years-old abandoned proof-of-concept/alpha-grade Kubernetes reimplementations that are completely unsuitable as a Kubernetes replacement.
The only actually-functional cut-down Kubernetes I'm aware of is 'minikube'. Minikube requires -at minimum- 2 CPUs, 2GB of RAM and 20GB of disk space. [0] That doesn't fit on either of the machines 'nrdvana' was talking about... not the "tiny ... digital ocean droplet", with its 1CPU, 1GB of RAM, and 25GB of disk space [1], nor the "tiny linode" (which has roughly the same specs [2]).
Given that it's not at all uncommon for discarded laptops to have 4 CPUs, 8GB of RAM, and like 250GB of disk, eating 1/4th of the RAM, (intermittently) half of the CPU power, and roughly a tenth of the disk space just for Kubernetes housekeeping kinda sucks. That's pretty damn "heavy", in my judgment. So. Do you have a link to this 'k1s' thing you were talking about? Does it use less than 2 CPUs, 2GB of RAM, and 20GB of disk?
There are a couple of things here: first off, minikube isn't tuned for low resources, it's a full k8s packaged for developers. Second, it doesn't burn much CPU at all unless you blew it up and it's churning pods. Third, try to remember that you're running a tool that provides most of what you need to run a service, it's not a bare VM, it comes with reverse proxy, tons of tools, and cluster management.
Basically those minimal specs let you actually run quite a lot of stuff on that minikube, they're not just for the management system.
k0s needs roughly 500MB RAM and 1.5GB drive to run a controller+worker. Can probably pare k3s down to that as well.
And I repeat, this gets you single pane cluster management across all your laptops, reverse proxy, DNS, resource shaping, namespaces, etc. Only big problem with it is that adding distributed storage is quite heavy and unstable (longhorn) or really heavy (ceph), so storage management might need to be manual which is a pain in k8s.
You noticed that I said "(intermittently) half of the CPU power", yeah?
> Third, try to remember that you're running a tool that provides most of what you need to run a service...
I already get everything that I need to run a service with old-ass systems like OpenRC+netifrc or -hack, gag- systemd and its swarm of dependencies. "Run a service on a *nix box" is a thing that we've had pretty well nailed down for decades now. It is -after all- how the services that run Kubernetes get run. Do note that you're talking to someone who does Linux system administration both as a hobby and professionally.
> Sorry I meant k0s. Off by one error at 3 am.
Sure, no problem. Shit happens.
So, k0s? Compared to minikube, the official minimum spec tables [0] indicate that -if you colocate the controller and worker- it cuts the CPU and RAM needs in half, and cuts the disk space by a factor of ten. That's nice, but that's still an eighth of the RAM and (intermittently) a quarter of the CPU of our hypothetical-but-plausible castoff laptop. That's still a lot of resources. And compared to what it costs you, you don't get much. If we were talking about some big, bad, mutually-untrusted-multitenant situation, it could be worth the cost, but -despite what folks like the CNCF might like you to believe- that's not the only scenario out there.
Also Mirantis is responsible for k0s? [1][3] After their rugpull with their Openstack distro way back when, I don't trust that they'll keep maintaining and providing complex stuff that's free to use for long enough to make it worth making a critical part of one's business. (Yes, this has absolutely nothing to do with its resource usage. I'm absolutely not bringing it up to support that argument in any way. I "just" thought it important to mention that I don't trust that Mirantis's free stuff will continue to be free for long enough to safely build (more of?) your business on.)
[1] From [2] "Mirantis offers technical support, professional services and training for k0s. The support subscriptions include, for example, prioritized support (Phone, Web, Email) and access to verified extensions on top of your k0s cluster."
[3] As additional evidence, the only two humans on the first page of commits to the k0s repo are Tom Wieczorek, whose Github profile indicates his affiliation with Mirantis [4], and Jussi Nummelin who is very, very obviously a Mirantis employee. [5] I tried to look at the complete Github contributor list for the k0s repo, but it simply wouldn't load. [6] But, I'd be shocked if this wasn't Mirantis's totally-functional-but-still-pet project that intends to more than make up the cost of development and maintenance with support contracts.
Hey I'm not arguing that you in particular shouldn't use old tech for fun. Heck serve your emacs written internet website via nc from your Amiga for all I care.
I'm just pointing out that it's easy and sufficiently efficient to run k8s on old computers, which makes running homelabs quite easy and also allows projects such as the OP to really shine. You seem to really enjoy telling me how bad it is that k8s needs 0.05 CPU and 500MB of RAM to run but the thing is it will scale horizontally a lot, and also presents the APIs you'll be expected to know in a devops job in 2026.
No, it's not right. When put in context, the quote claims that that manner of speaking is used because the speaker has an unwarranted belief that they've done something absolutely incredible and unprecedented. In actuality, the manner of speaking is being used because the intended audience of the article is likely to have little-to-no knowledge of the technical details of what the speaker is talking about.
For example, if the article was aimed at folks who were familiar with the underlying techniques, the last two paragraphs of the "Enforcing Determinism" section would be compressed into [0]
Each FCM is time-synced and runs a realtime OS. Failures to meet processing deadlines (or excessive clock drift) reset the FCM. Each FCM uses triply-redundant RAM and NICs. *All* components use ECC RAM. Any failures of these components reset the FCM or other affected component.
But you can't assume that a fairly nontechnical audience will understand all that, so your explanation grows long because of all of the basic information it contains. People looking for an excuse to sneer at something will often misinterpret this as the speaker failing to recognize that the basic information they're providing is about things that are basic.
[0] I'm assuming that the time being wildly out of sync will indicate FCM failure and trigger a reset. [1] I'm also assuming that a sufficiently-large failure of a network switch results in the reset of that network switch. If the article was intended for a more technical audience, that level of detail might have been included, but it wasn't, so it isn't.
[1] If it didn't, why even bother syncing the time? I find it a little hard to believe that the FCMs care about anything other than elapsed time, so all you care about is if they're all ticking at the same rate. I expect the way you detect this is by checking for time sync across the FCMs, correcting minor drift, and resetting FCMs with major drift.
> ...but in my world that excuse runs out waaaaaay before 15 months.
I expect the combination of
Yes, we should've migrated away sooner, we never had the capacity to do so and hoped Bunny would just get their shit together.
and
The loss rate isn't enormous in percentage terms, but it's consistent and ongoing.
means that detecting and dealing with the loss is substantially less work than moving away. [0] I expect that Management is fully aware of what's up and is making the call here.
[0] "Just" add a retry if the post-upload verification step fails! Sure, it's slower, but it works, right??? mournful sob
> in effect you've basically hamstrung green sources of energy around the country by being very smart for your own state.
> The question is, should you be allowed to this.
"...you've basically hamstrung green sources of energy"?
Well, after we stop growing corn to feed exclusively to cars and start using solar panels deployed on that land to harvest electricity for cars and houses and everything else that runs on electricity [0], if we're still short on power we can have the discussion you're itching to have.
[0] The immediately relevant discussion starts here <https://www.youtube.com/watch?v=KtQ9nt2ZeGM&t=1930s> and runs through to about 38:29, but the entire video is very, very well worth watching. If you intend to watch more of the video after ~38:29, I very strongly recommend that you start from the beginning.
Tis a pity that a sober, thoughtful discussion that has as one of its conclusions «The notion that you'll be left behind if you don't learn how to use LLMs _now_ just doesn't make any sense.» [0] didn't get "traction".
[0] In case the marks didn't make it clear, this is paraphrasing, rather than a direct quote.
If I purchased a table saw and that table saw irregularly and unpredictably jumped past its safeties -as we've plenty of evidence that LLMs [0] do-, then I would [1] immediately stop using that saw, return it for a refund, alert the store that they're selling wildly unsafe equipment, and the relevant regulators that a manufacturer is producing and selling wildly unsafe equipment.
[0] ...whether "agentic" or not...
[1] ...after discovering that yes, this is not a defective unit, but this model of saw working as designed...
reply