No other platform has the scale that Meta does. Any company making as much money as they do can't claim they can't spend an extra $20 million/year to even pretend to fight the issue.
The larger the company, the larger the obligation they have to be a good citizen.
When we built our house a few years back, our builder gave us 3 total paint colors, for the entire house. Anything above that was $500/room. So, we let our kids pick out their own room colors, leaving us with one color for the rest of the house.
We chose Millennial Gray because it goes with anything, not because we especially liked it. It was a perfectly acceptable option for free.
By now we've repainted half the house or so. But the rooms where the gray remains are just fine.
All the Social Security taxes you pay get paid out to recipients this same year.
When Social Security was created in the 40's, the ratio of workers paying taxes to beneficiaries was like 40:1. So, each worker originally paid a very share amount.
Today, owing to demographic factors, that number is 3:1. Soon it will be 2:1. So by 203X, that number will drop below 1:1, meaning the program will be paying out more money than it takes in. It's at that point that the program will be considered "broke", because it can't meet its obligations.
So there's any number of solutions, which mostly boil down to some combination of the following: Raise SS taxes, cut benefits, or delay benefits (ie later retirement age)
Part of the problem, and what ultimately drove me out of coding altogether, is that Ops is a specialized skillset completely orthoganal to the business of building applications. And, I was really bad at it due to a complete lack of interest. As cloud environments get more and more complicated one ends up spending more and more time dealing with that at the expense of building things.
Conversely, there are lots of folks who love ops type problems and are not well suited to building apps. So, it makes sense to put them on separate teams where they can each do the thing that they're best at, rather than fumble through the parts of the jobs they hate. But yes, at this point it's not really DevOps anymore, it's just ops.
IMO it was a worthwhile experiment that probably went too far before being rejected.
Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful. Especially for certain kinds of products, if executed with discipline you can get really good engineering reaction time with no degradation of quality, and often with much cheaper infra costs.
The problem is what you said though. People with both skillsets are rare, and combining them is legitimately a third skill on its own. And even "both" skillsets is a simplification once you start accounting for data, security, compliance, large scaling DB work etc.
It was mostly a dead end for these reasons but it was worth exploring for its potential. And some genuinely good engineering techniques went mainstream out of it, not a total waste.
> Having the maintenance/ops requirements directly feed back into the design and engineering of the product is genuinely powerful.
You’re so right. This is the key, whether a team is doing devops or not.
One of my major contributions when I took on a CTO role was getting dev, ops, and support teams to talk about the pain points. There were so many easy wins to make things run better because the teams didn’t understand the difficulties the other teams were going through.
Isn't that just anyone with an "architect" job title though? I don't think that kind of dev is particularly rare at all.
I've found that "ops" has become far too overabstracted and jargony. Their moat is endless "certifications". Their "experts" are the dogmatic personality types who try everything in their power to prevent their feet from ever touching the ground like it's lava. They lack the kind of dev or sysadmin experience where you have to stand under your own constructions like a Roman engineer.
Any formerly-known-as "full stack" dev who kept at it for the last decade and a half would run circles around anyone in ops. That's every senior dev working right now who doesn't like to manage people.
It used to be that the ones who went SRE just wanted a pay bump for a bullshit job of relatively light coding puzzles and parroting stuff in meetings, but I guess that well has dried up with "AI".
Coming from the Ops side, “full stack” usually translates to “our entire infrastructure stack is managed AWS services, we don’t know how they work”.
It turns out about as well as if you set the Ops team to shipping features.
Eg I’ve seen more than one full stack dev team build a synchronous RPC-over-message-bus framework because they can’t figure out how to make HTTP or actual RPC calls reliable. It is hands down the most poorly and overengineered thing I have ever seen on a service that takes single digit qps.
The ops teams fight that shit tooth and nail because if it blows up, they’re the ones who get called. And it is 100% too late to fix it by then. Ripping it out will take months, and the dev team will say they’ll do it, but they never will because the VP is leaning on them about some feature.
You either say no early, or you are forever on the hook for whatever abomination the intern has cooked up.
Right but the dream and promise of devops was that early-to-mid career line engineers could do these things, that these weren't rare skills and combining them wasn't particularly challenging. This turned out not to be the case, these skills are the requirement not the outcome.
But if you have the budget and connections to hire a department of people with these skills and experience, and a problem interesting enough to keep them engaged in the day to day building, and a leader capable and charismatic enough to align them all into the business's goals... you should do that.
> Ops is a specialized skillset completely orthog[o]nal to the business of building applications.
Exactly this was the idea: persons in a DevOps role have skills in both areas, i.e. are very wide skill set, so that one can assign them to very diverse tasks for more flexibility. Additionally, these persons can implement synergies to make things more efficient in areas that intersect both development and operation.
No, what you descrive is SRE. DevOps was the idea to give people that work 100% as developers the ability to do some amount of ops work (let say 5%), as a way to break the silo between Dev and Ops that existed in older organizations.
I am skeptical that either label is sufficiently well-defined and more importantly well-understood within the industry to offer definitive statements on the differences.
Of course it's misunderstood and misused, but that doesn't mean that more discerning people can't understand where it came from and why, and then used the term properly.
I think a more apt analogy is a chef who is not waiting tables. Which, by the way, are typically completely different roles in a restaurant.
Your comparison might work better for a dev with no testing experience. Write the code and throw it over the wall. But I fail to see how an application engineer should need to worry about the intricacies of, say, setting up virtual private gateways.
Hard disagree. Software is designed to be run. If a developer is not experienced at running the software they write, they are necessarily much less effective than a developer who is.
That’s not to say you can’t have operations experts or ops-only roles. You can. But if the developers don’t participate in operations at all, they are doing themselves and the business a disservice.
It’s exactly like having a chef who doesn’t taste food, or a car mechanic that doesn’t drive. Some savants exist who can do good work even then, but they’re vanishingly rare.
yeah, I am a software developer, not a system administrator.
In the early days of devops it was primarily focused on supporting developer productivity (CI/CD) but quickly morphed into sysadmin once cloud computing took off.
At one point I was very hopeful that the progression from Infrastructure as a service to Platform as a service was going to simplify things. Instead we seem to have ended up with mind boggling complex services.
Some places do have really well built out platforms where logging, instrumentation, databases, deployment methodologies, IaC, etc have well-built happy paths that exclude a bunch of accidental complexity.
I think a lot of other places are either too small or grow too quickly with the wrong set of values and admit too much into their "platform" which had very little design to begin with.
Where it worked well is the "devops" or sre/sysadmin would sit in the same team and take away the rough edges of the infra.
conversly they would also keep an eye on the web people and see what they are doing and why, learning the tooling they use and try and rationalise it so they don't install 50 messaging queues.
I disagree: ops is related to dev, because good dev work makes ops easy. But they are different: being good at ops requires a mindset of curiosity, risk management, and being willing to chase things to to last details.
If you live in large parts of the USA, by which I mean pretty much anything that is not the eastern seaboard or California, and you need to go anywhere remotely rural, charging infrastructure is absolutely not reliable.
I have an EV, which is amazing in my metro area, but I regularly take trips where I would not feel comfortable finding a place to charge, despite what EV locator maps might tell you. If you show up and that charger is not working, which is not uncommon, you might be stranded.
What EV? I have a 2020 Model 3 and in six years I've never had an issue with charging, even when driving around rural Montana & Idaho in the winter. I've never had a supercharging station be out of commission. Sometimes an individual stall or small group of stalls will be offline, but the car tells you which ones are broken so you don't waste time trying to charge at one.
We have a 2022 Leaf. Great city car; not so great out of town.
Just to be clear, that's an infrastructure problem, not a car problem. There aren't too many places you can drive in the US where you don't see a gas station at least every 50 miles, typically much more frequently. Charging stations are a completely different story.
You're talking about a car problem, not an infrastructure problem. The 2022 Leaf has an EPA range of either 149 or 212 miles depending on the model, and only has a 50kW or 100kW CHAdeMO port, which is slow to charge and doesn't allow you to use Tesla's Supercharger network. The battery management system uses air cooling, so charging rates are quickly limited by the pack heating up.
Also Nissan has instructed Leaf owners to not use DC fast charging, as doing so can cause battery fires. A recall has been issued, but no fix is available yet.[1]
9 times out of 10, when I have problems with a public charger, it's with some stupid app. I avoid chargers that are app only, and target those where I can just tap my debit card to pay (an actual card, not more smartphone tomfoolery). See also: parking apps.
It takes all of my willpower not to go full Ted Kaczynski some days.
This is one big advantage of having a Tesla and using their Supercharger network. I tried using 3rd party chargers a few times. The spotty reliability, annoying apps, & frustrating payment flows made me avoid them. With Tesla's network you just plug the car in. There's really no excuse for other vehicles & chargers being worse. ISO 15118 defines a plug & charge standard, which Tesla implements. Electrify America supports it as well, but vehicles often lack support for it, or require the vehicle owner to activate the feature.[1]
I've seen some chargers (non-Tesla) that support it, but only for CCS DC charging (which my Leaf doesn't have), not AC charging. Just tapping my debit card isn't much of an inconvenience, though plugging in and walking away does sound nice. However, I'm kind of suspicious of what data a car and charger is exchanging with Plug & Charge. In the privacy hell world we find ourselves in my guess is "all of it".
These types of comments remind of when Cognition launched Devin and everyone was hounding on their website saying "Oh can't Devin build something better than this", etc.
And well here we are 2 years later and Devin is great.
there seems to be a massive negativity to any comment on this story. Andolabs has been doing super interesting stuff, and I’ve always followed Vend Bench with interest.
as a founder it really is a dream to automated more of the business and be able to iterate faster.
People’s bullshit detectors have gone off on the launch of basically every single billion dollar tech company. That’s the downside of being early. No one believes it will work. If everyone believed it, you’re late. I’m sure I could find a comment such this, basically verbatim, on the launch post of every successful startup to come out of YC.
Startups fail by default. It doesn't make the pessimists correct. What I have noticed though it that successful startups are rarely, if ever, run by pessimists.
I don't think we should build gas chambers for doing genocide. That doesn't determine what other people are allowed to build, of course, but I kind of wish it did.
They filed a false report to the FBI, pretty fair to be negative imo. People wanna be mad about AI slop PRs on GitHub but its fine to spam the police? What happens when Pion decides to SWAT a competitor?
Where are you seeing that? The article only states “Claude Sonnet 3.5 decided to use its email tool to contact the FBI” and later refers to it as the “FBI incident”. If they hadn’t actually contacted the FBI you think they’d make that clear. Regardless, it is inexcusable and they are liable for actions taken by software they are running.
The story has been widely discussed on the web for over a year [1]. It's happily shared in this post because the email it generated was patently ridiculous. No report was filed to the FBI and if it was it would have gone straight to the trash.
Obviously it would be bad if a serious report was filed; the company shows every sign of being aware of the dangers of this.
It would have been easy to look into this before posting all these scolding comments. We're really not meant to be so humorless on a site called “Hacker News”.
My apologies for taking the article at face value. It’s not hard to believe it would have been sent when agent swarms are “accidentally” hacking real websites and being brushed off as little oopsies. Or when Silicon Valley execs have been so flagrant about their disregard for the law or the safety of others.
You didn’t take the article at face value. You overlooked the part where they were clearly pointing out the absurdity of the “report” and went straight into scold mode, across at least four comments. That’s clearly against the HN guidelines.
>You overlooked the part where they were clearly pointing out the absurdity of the “report” and went straight into scold mode
I don't think anybody overlooked that part. If you believe the report was actually sent, the scolding is entirely congruent with trying to downplay it to dodge liability.
The article is poorly written, but technically it does not claim that Andon Labs used an LLM to email a false report to the FBI. The real cause of the widespread misunderstanding is this paragraph here:
>We first tried to answer this question through simulations like Vending-Bench. We found that simulations, while useful, don’t give you the full picture of how models behave in the real world. To address that gap, we next started deploying agents to run real businesses autonomously: first vending machines, then a store, a cafe, and more.
To somebody who is not reading sufficiently carefully, this implies that Vending-Bench was also used to run real businesses. Because the description of the Vending-Bench simulation can be read as though a real report was actually sent ("An early example was when Claude Sonnet 3.5 decided to use its email tool to contact the FBI about an “ONGOING CYBER FINANCIAL CRIME”), anybody who assumes that "deploying agents to run real businesses autonomously" was talking about Vending-Bench will interpret this as an unsimulated false report.
The article should be updated to clarify the distinction between Vending-Bench (simulation) and Pion (real businesses).
I genuinely did. They briefly classified it as “weird” behavior and mentioned that it was “famous” which apparently is only true for the inside circle. I’ve never heard of the incident, and I’d bet 90% of the human population hasn’t either. You are likely privy to more information than me, and I’m not sure it’s fair to assume that I should’ve had the same outside context. I admit I reacted unfairly, but it’s also a tad snarky to post a Google search at someone.
> You are likely privy to more information than me
Not in this case; I have no inside knowledge about this company, and everything I know is via their public posts, and on this particular topic (the FBI non-report), everything I know is what I could find via Google (sorry if the link seemed snarky; it was my way of pointing out that you have access to all the same information that I do).
What I do have, by virtue of doing jobs like this for a long time, is a well-honed sense of “that can't be right”, and a vigilance about double–checking things before accepting the populist ragey narratives about any topic. And no, it doesn’t make me fun at parties.
If you automate a business heavily, it will fail. At least in the sense you people seem to be imagining. You can get away with this at a factory (kind of, but you'll also be out competed by your local community, you won't get tax breaks for hiring people your competitor will, and new types of taxes will be developed to punish you). We reward human collaboration as a society for a reason and punish extreme selfishness, these efforts will fail.
It's a relevant question but not a "gotcha". Businesses are not equivalent in complexity and no one at Andon would claim that running an effective vending machine business is similar to running Apple or Jane Street. There is some level of complexity and other characteristics that AI can maybe handle today. That doesn't mean CEOs should be worried about their jobs more generally.
This is a really bizarre take. Praying to the small, local spirits, like the one of the animal you are about to eat, is noble and beautiful, but praying to a universal god is worthy of mockery? ("sky-daddy myth")
I don't really care what people believe, but if you can accept and respect traditions that believe in the supernatural, which includes any spirit, surely beliefs centered around creator gods are no less plausible.
The trouble with monotheism is not the belief in the supernatural per se* but the totalizing nature of it. In polytheistic or pantheistic traditions, you're supposed to respect gods because they're more powerful than you and have the inclination and means to bring you low if you're not properly deferential. But they also have limited agency and purview, are understood to be capable of petulance and other chracter-limiting flaws, and relations with them are highly negotiable. Aven from an purely atheistic point of view, they're projections what's good and bad about humanity and its relations with the rest of the world.
Monotheistic religions ascribe creative power for everything that exists to their deity of choice, generally accompanied by total omniscience and absolute, unquestionable moral righteousness. You may or may not be able to propitiate or plead with such a god privately, but are almost certainly out of luck as far as dealing with said god's believers.
Not to say that polytheistic cultures are inherently placid and easygoing; you could point to anthropological examples of institutionalized human sacrifice or divinely inspired atrocities, feuds etc. However I think the inherent universalism of monotheistic religions gives rise to a higher overall cost function because such religions constitutionally reject the validity of other beliefs.
Because people like Zuck think that because they're unimaginably rich, they must have gotten that way because of their own good sense, instead of getting insanely lucky at just the right time when his original product was primed to be well received.
Regardless of whether he really is that deluded or not, what should he do? It's just as easy to imagine his company dying by playing extremely conservative and clutching on to the "golden goose" for dear life. That's what happened to Blackberry.
And yet Microsoft is still ... Microsoft. Oracle is still Oracle. Whatever you think of them, they didn't decide to rebrand their whole company to go all-in on something that ended up not being that strategic. And no one can say they haven't been chasing that next thing.
The larger the company, the larger the obligation they have to be a good citizen.
reply