If one has a medium-sized chunk of money to burn, one could try fiber optic cabling. I've personally had -AFAICT- perfect results from Monoprice's "SlimRun AV" fiber DisplayPort cables, and Nippon Labs' fiber HDMI cables. [0] I expect that Monoprice's fiber HDMI cables and Nippon Labs' fiber DisplayPort cables are also fine, but I've never used those, so I cannot comment.

For folks concerned about "dreadfully fragile" fiber optic cables, I do know that the Monoprice cables are durable... a vigorous misadventure caused me to torque the hell out of the monitor-side connector. The connector bent, forcing the case split a bit at the seam. After some counter-bending of the connector and pushing its case back mostly closed, the cable works fine. Given the outward similarity in build quality, I expect that the Nippon Labs cable I have is at least as durable.

[0] Both families of cables drive my "4k" HDR monitor at 60Hz without lossy compression.

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.

[0] <https://old.reddit.com/r/ClaudeCode/comments/1sex28q/opus_46...>

[1] ...not...

[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.

[3] ...whether intentionally or not...

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...

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".

> ...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?

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.)

[0] <https://docs.k0sproject.io/head/system-requirements/#minimum...>

[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."

[2] <https://docs.k0sproject.io/head/>

[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.

[4] <https://github.com/twz123>

[5] <https://www.mirantis.com/blog/authors/jussi-nummelin/>

[6] Github's "Zero nines of uptime" guarantee is rock solid and reliable!

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.

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...

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?

[0] <https://minikube.sigs.k8s.io/docs/start/>

[1] <https://www.digitalocean.com/products/droplets#see-what-you-...>

[2] <https://www.akamai.com/cloud/pricing#title-7ba40063be> [3]

[3] Did you know that Linode got bought by Akami? I didn't!

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.

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.

[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.

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.

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.

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]

3) <https://www.usenix.org/system/files/conference/hotos15/hotos...> (2015)

[0] These are useful tools. But if you're going to be tossing a laptop in a colo (or buying a "tiny linode or [DO] droplet"), YAGNI.

I'd chalk that up to the author of the article writing for a relatively nontechnical audience and asking for quotes at that level.

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.

  The loss rate isn't enormous in percentage terms, but it's consistent and ongoing.

[0] "Just" add a retry if the post-upload verification step fails! Sure, it's slower, but it works, right??? mournful sob

> 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.

Correct. I've presented a _pair_ of examples.

That wasn't exactly what PunchyHamster was saying. PH was saying that putting an untrusted workload in a container doesn't prevent it from scanning (and attacking) your network... so your IP network security is just as bad when that untrusted workload is containerized as when it's not. Containers/sandboxes can provide filesystem segmentation (except when they don't! [0]), but the way they're typically used, they provide zero network segmentation.

I mention in my comment here [1] that it's useful for whatever isolation mechanism you use (even if it's "just" 'a separate minimally-privileged user') to ensure that programs its spawns are on separate VLANs that your router prevents from talking to anywhere other than the Internet.

[0] <https://github.com/flatpak/flatpak/security/advisories/GHSA-...>

[1] <https://news.ycombinator.com/item?id=47690425>