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.
What I've seen more than anything else is that Kubernetes built an ecosystem (of contributors and users, but also of companies invested in its success) that none of its competitors could or would. There was apparently a faction within Google that believed open-sourcing Kubernetes was a mistake because Google would have made more money keeping it in-house, but in terms of the success of the project I think it was entirely the right call, as was creating a foundation to maintain and promote it. Look at the history of its competition:
* 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.
Tom Segura has a standup bit in one of his specials about cop reality shows, and how people think talking to the cops is going to work out great for them. "Lawyer up. You can't handle that s**. Everybody's like, 'I'm gonna talk to the cops, and straighten this whole thing out.' You're gonna do 25 to life. Have fun with that, man."
> When you read plenty of papers you aren't going to read them again to cite them.
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.
What people currently refer to as "generative AI" is statistical output generation. It cannot do anything but statistically generate output. You can, should you so choose, feed its output to a system with actual operational capabilities -- and people are of course starting to do this with LLMs, in the form of MCPs (and other things before the MCP concept came along), but that's not new. Automation systems (including automation systems with feedback and machine-learning capabilities) have been put in control of various things for decades. (Sometimes people even referred to them in anthropomorphic terms, despite them being relatively simple.) Designing those systems and their interconnects to not do dangerous things is basic safety engineering. It's not a special discipline that is new or unique to working with LLMs, and all the messianic mysticism around "AI safety" is just obscuring (at this point, one presumes intentionally) that basic fact. Just as with those earlier automation and control systems, if you actually hook up a statistical text generator to an operational mechanism, you should put safeguards on the mechanism to stop it from doing (or design it to inherently lack the ability to do) costly or risky things, much as you might have a throttle limiter on a machine where overspeed commanded by computer control would be damaging -- but not because the control system has "misaligned values".
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."
> I wish I could hammer one thing through the skull of every "AI SAFETY ISNT REAL" moron: if you only start thinking about AI safety after AI becomes capable of causing an extinction level safety incident, it's going to be a little too late.
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.
It’s also already becoming an issue for open-source projects that are being flooded with low-quality (= anything from “correct but pointless” to “actually introduces functional issues that weren’t there before”) LLM-generated PRs and even security reports —- for examples see Daniel Stenberg’s recent writing on this.
"...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."
Given that part of those "safeguards" were enshrining weird AI doomer logic in a federal agency's mission and trying to put a doomer in charge of enforcing it, some of them could use dismantling.
My vague recollection is that that concern was that the etcd store (specifically the keys pertaining to the Vault pod spec) could be modified in some way that would compromise the security of the encrypted Vault store when a Vault pod was restarted. It's been a long time since I remember that being a live concern though, so I've mostly recycled those neurons...
Not necessarily (although that doesn't necessarily mean I think this is OK). Payment-card-based verification is a longstanding method of doing prima-facie verification like this. When you give your credit card, you give your billing address and typically your phone number -- if the postal code is a US address and the phone number is a US area code and everything else is consistent with that, that might be all the KYC required. If you appear to be a foreign national operating outside the US, they can flag that and require additional paperwork only then.
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.)
Analyst consensus I've seen on long-term price has been floating around $32-34 per share. Take that with as much salt as you think it needs but it's at least interesting that it's within shouting distance of (but not over) the IBM offer.
Almost all the talk I saw internally, from well before to well after the license change, about competitors "taking advantage" of our open-source versions was about TFC competitors like Spacelift, Scalr, etc. and Terraform OSS. The Vault competitor mentioned most often was Akeyless but for reasons less like the TFC competition. I saw IBM Cloud Secrets Manager mentioned maybe once or twice.
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.
> was always told early on that although they supported vault on kubernetes via a helm chart, they did not recommend using it on anything but EC2 instances (because of "security" which never really made sense their reasoning).
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.
Vault's client-based pricing was (is) the worst thing about selling it. When I was there, nobody in sales liked it except the SEs and account reps dealing with the largest customers (and those customers loved it because it actually saved them a substantial amount of money over other vendors' models like per-use or per-secret). All the customers except those very largest ones hated it. The repeated response from those who believed in the client-based pricing model, to those of us pointing out the issues with it, was essentially "if your customers don't like it, they must not understand it because you aren't doing a good enough job explaining 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.
One of the reasons I left when I did was that it was starting to get really obvious that an acquisition was likely and I desperately did not want my work e-mail address to end in oracle.com.
* Red Hat wasn't ever "in financial trouble" -- their revenue line was up-and-to-the-right for a ridiculous number of consecutive quarters. Even when they missed overall earnings estimates, it was rarely by much and they still usually beat EPS estimates for the quarter.
* 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.
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.