No they aren't. They're statistical token generators. They do not understand concepts such as "distance from a given location or coordinate point". If you're lucky you might ask it something likely to appear nearly verbatim in its training data, like "Chinese restaurants in Midtown Manhattan", and get back a reasonably accurate list, but it does not understand what a "Chinese restaurant" is, or what "Midtown Manhattan" is, or that one relates to the other in any way other than both appearing statistically associated with another set of tokens when they appear near each other.

* DC/OS was always its own thing and as time went on, eventually Mesosphere was basically the sole maintainer of the underlying Mesos. Very little external contribution.

* OpenShift was different from Mesos and basically maintained only by Red Hat from the Makara acquisition (sometime in 2010 I think) to about mid-2015 (i.e. the point where they ripped out most of the OpenShift-native process isolation and orchestration and replaced it with Docker and Kubernetes). Pre-Kubernetes OpenShift frankly struggled to catch on and again, basically everybody who cared about developing it worked for one company.

* CoreOS was developing fleet in the open but dropped it outright when Kubernetes was released. The phrase I heard there was "We started to say something and Google finished our sentence." They pivoted to Kubernetes for orchestration so hard it was kind of awkward talking to customers who used fleet after that. In theory somebody could have picked it up like Kinvolk picked up rkt for awhile (and later CoreOS Linux as Flatcar), but as far as I know nobody ever made a serious effort to do so.

* Docker released Docker Swarm shortly after Kubernetes was released -- yet another one-company product. (I still don't really understand why they released Swarm -- for simple workloads, Docker Engine and Docker Compose were enough, and for more complex ones Docker Engine was, at that time, still the sole underlying runtime in Kubernetes. There were already two distinct orchestrators on the market, one from a much larger company with a lot more operational experience running containerized workloads than Docker had. What was their thought process?)

* HashiCorp released Nomad well after Kubernetes but not only was it another sole-corporate-maintainer orchestrator, it deliberately omitted a lot of the basics Kubernetes included like service discovery in an effort to stay simple -- so in very few cases was Nomad alone actually enough to orchestrate workloads (nor was it intended to be, as the Nomad engineers in the ~1.0 days would have been first to tell you). Past a point this made Nomad more work to get running and keep running than Kubernetes was.

The flip side is, I don't think a purely community-developed orchestrator would have won, even with a foundation backing it. It's not the corporate backing that's the issue, it's the lack of diversity in that corporate backing.

But in fact I do exactly that, exactly because experience has taught me that my memory of what is in a paper is fallible and I should at least cursorily review what I'm citing. In a few cases I've even just deleted something entirely because my premise was based on a recollection of what I intended to cite that was subtly wrong enough to fatally undermine my entire thesis.

I'm not saying you have to read an entire paper over completely every time you cite it but at least pulling it up and reviewing the parts that are informing your argument is definitely a best practice.

Nobody talks about a malfunctioning thermostat that makes a room too cold being "misaligned with human values" or a miscalibrated thermometer exhibiting "deception", even though both of those can carry very real risks to, or mislead, humans depending on what they control or relying on them being accurate. (Just ask the 737 MAX engineers about software taking improper actions based on faulty inputs -- the MAX's MCAS was not malicious, it was poorly-engineered.)

As to the last point, the burden of proof is not to prove a nonliving thing does not have mind or will -- it's the other way around. People without a programming background back in the day also regularly described ELIZA as "insightful" or "friendly" or other such anthropomorphic attributes, but nobody with even rudimentary knowledge of how it worked said "well, prove ELIZA isn't exhibiting free will".

Christopher Strachey's commentary on the ability of the computers of his day to do things like write simple "love letters" seems almost tailor-made for the current LLM hype:

"...with no explanation of the way in which they work, these programs can very easily give the impression that computers can 'think.' They are, of course, the most spectacular examples and ones which are easily understood by laymen. As a consequence they get much more publicity -- and generally very inaccurate publicity at that -- than perhaps they deserve."

How about waiting till after "AI" becomes capable of doing... anything even remotely resembling that, or displaying anything like actual volition?

"AI safety" consists of the same thing all industrial safety does: not putting a nondeterministic process in charge of life- or safety-critical systems, and only putting other automated systems in charge with appropriate interlocks, redundancy, and failsafes. It's the exact same thing it was when everybody was doing "machine learning" (and before that, "intelligent systems", and before that some other buzzword that anthropomorphized machines...) and not being cultishly weird about statistical text generators. It's the kind of thing OSHA, NTSB and the FAA (among others) do every day, not some semi-mystical religion built around detecting intent in a thing that can't actually intend anything.

If you want actual "AI safety", fund public safety agencies like NHTSA and the CPSC, not weird Silicon Valley cults.

Comments URL: https://news.ycombinator.com/item?id=44473564

Points: 2

# Comments: 1

https://ludic.mataroa.blog/blog/you-must-read-at-least-one-b...

"...There are fencers that seriously train that can barely score a point on me. I can barely score against the top guy in Australia. That guy can barely score against someone trying to make the Olympics, and that guy can probably barely score against the guy that actually won the whole thing."

This proposed rule looks to me like it basically requires providers to come up with their own verification plans, which may then differ from provider to provider, so as to be "flexible and minimally burdensome to their business operations".

[note for the following: I am not a lawyer. The following is not legal advice. Do not fold, spindle or multilate. Do not taunt Happy Fun Ball.]

The real danger, I think, with things like this is, there's an executive order that was issued, but it further specified a rulemaking process be conducted to determine the actual regulations that define compliance. The link in the title is to the proposed rule. There's nothing that says any amount of prior public input will necessarily influence the details of the final rule, or that rule can't change in the future through another rulemaking process, and if it does the only way to challenge it is either to sue the agency on the grounds that it exceeded its discretion (e.g. by making rules that require unconstitutional things) or that the enabling executive order is itself unconstitutional -- but these kinds of federal cases have a pretty high bar for what's called "standing" (the legal grounds to bring a particular lawsuit): you pretty much have to suffer concrete harm or be in obvious and imminent danger of suffering it to a grievous degree. (This is one reason you hear about "test cases" -- often somebody will agree to be the goat who is denied something, fined, or even arrested and convicted of a crime, so that standing to sue to overturn the law can be established.) Other times, if a lot of potential defendants already have standing, a particularly sympathetic defendant will be selected for the actual challenge. The US federal courts are also deferential to "agency discretion" by default, as a matter of doctrine.

What happens all too often with these things is, the initial rulemaking is pretty reasonable, and the public outrage (if there was any) dissipates. Then three years (or however long) on, the next rulemaking imposes onerous restrictions and strict criteria, and people suddenly (relatively speaking) wake up and find they're now in violation of federal regulations that they were in compliance with last week. (This is one reason public-interest groups are so critical -- they have the motivation and sustained attention to comb the Federal Register for announcements about upcoming rounds of rulemaking on various topics.)

I'm sure IBM Cloud's Vault offering was part of the decision, but from where I was sitting, it didn't look like the reason or even the primary reason.

The reasoning is basically that there are some security and isolation guarantees you don't get in Kubernetes that you do get on bare metal or (to a somewhat lesser extent) in VMs.

In particular for Kubernetes, Vault wants to run as a non-root user and set the IPC_LOCK capability when it starts to prevent its memory from being swapped to disk. While in Docker you can directly enable this by adding capabilities when you launch the container, Kubernetes has an issue because of the way it handles non-root container users specified in a pod manifest, detailed in a (long-dormant) KEP: https://github.com/kubernetes/enhancements/blob/master/keps/... (tl;dr: Kubernetes runs the container process as root, with the specified capabilities added, but then switches it to the non-root UID, which causes the explicitly-added capabilities to be dropped).

You can work around this by rebuilding the container and setting the capability directly on the binary, but the upstream build of the binary and the one in the container image don't come with that set (because the user should set it at runtime if running the container image directly, and the systemd unit sets it via systemd if running as a systemd service, so there's no need to do that except for working around Kubernetes' ambient-capability issue).

> It always surprised me how these conversations went. "Well we don't really recommend kubernetes so we won't support (feature)."

> Me: "Well the majority of your customers will want to use it this way, so....."

Ha, I had a similar conversation internally in the early days of Boundary. Something like "Hey, if I run Boundary in Kubernetes, X won't work because Y." And the initial response was "Why would you want to run Boundary in Kubernetes?" The Boundary team came around pretty quick though, and Kubernetes ended up being one of the flagship use cases for it.

What I thought we really needed was a "starter/enterprise" dual-model pricing structure, so that smaller customers could get pricing in some unit they could understand and budget for, that would naturally and predictably grow as they grew, to a point where it would actually be beneficial to them to switch to client-based pricing -- but there seemed to be a general reluctance to have anything but a single pricing model for any of our products.

* IBM had little to do with Red Hat's maneuvers around CentOS (I worked at Red Hat for several years and still have friends there, and nothing anybody there said publicly about CentOS in 2020 or 2023 was materially different from things people there were saying about it internally in 2012). Some people have tried to blame IBM for a general culture shift but as far as I've seen, every bit of the CentOS debacle was laid squarely at the feet of Red Hat staff by most in this industry -- as it should have been, since most of those involved were employed there well before IBM bought the company.

IBM's reputation as an aging dinosaur was well-earned long before it bought Red Hat, and continues to be earned outside it. That earned reputation was why they bought RHT in the first place: IBM Cloud market share was (and still is) declining and they wanted a jumpstart in both revenue and engineering credibility from OpenShift in particular.