zemo

> OpenAI, Anthropic and xAI (the new Musk one) all have a funky governance structure because they want to be a public good

do they actually want to be a public good or do they want you to think they want to be a public good?

honestly I bet a big portion of why that works is that they're statically linked binaries, but "ships as one statically linked binary" doesn't have quite the same marketing power. One of the first things I do when I check out an open source project is check if it's written in or requires node.js, and if it does, I ignore the project. I've worked with enough node.js stuff over the years to know that I simply do not want to deal with its ecosystem. I feel the same way about Ruby but I can't remember the last time I saw a new Ruby project. If I have to deal with managing an interpreter, I don't want to use your project. Python only gets a pass because I still use it professionally so I am personally up to date on its quirks, but I can understand why someone would say the same thing about Python projects.

while they do have pretty deep ties to tencent and are 40% owned by them, they’re not really chinese-owned since Epic is majority-owned by Tim Sweeney, a billionaire programmer on the Forbes 500 who mostly escapes criticism from programmers and game devs by branding himself as a savior for indie devs, which people accept uncritically because he likes to go on twitter and affirm their priors. He’s a highly effective nerd populist.

did an suv write this

the vast majority of organizations buying this product will use it to build SaaS. Now comes the part where you pretend otherwise ("but hospitals/universities need this too!"), press me for more evidence ("how do you know that's what people buy it for?"), or feign ignorance on the topic ("what's inherently rentier capitalist about SaaS?").

their whole "AWS is bad because THEY are engaging in rentier capitalism, we are good because we sell you the tools to let YOU engage in rentier capitalism" shtick rings empty to me

> Ironically this looks like the realization of Richard Stallman's dream where users can help each other if something doesn't work.

that's only true if you think that "users" means "people who operate cloud computers", which is about as far from understanding what Stallman is talking about as is possible. Someone who makes SaaS and runs it on an Oxide computer is no less of a rentier capitalist than someone who makes SaaS and runs it on AWS.

yeah he quotes the Futurist Manifesto further down the page, also with no historical context, which ... I dunno, that's gotta be a dog whistle, right?

> The myth of Prometheus – in various updated forms like Frankenstein

"if you democratize power, the powerful will hate you for it" and "if you play with powers beyond your ability to control, they may backfire" seem like really different myths to me

> We are told to denounce our birthright – our intelligence, our control over nature, our ability to build a better world.

huh, I don't know that I've ever been told this

> We believe the market economy is a discovery machine, a form of intelligence – an exploratory, evolutionary, adaptive system.

I love how intellectually shallow the power of this reasoning is. Oh, a person who is drowning will pay more for a gulp of air? Wow, what an amazing conclusion, how could we have ever figured that out without the beautiful Divine Glory of The Market?

> Decentralization harnesses complexity for the benefit of everyone; centralization will starve you to death. ... Our enemy is statism, authoritarianism, collectivism, central planning, socialism.

centralization is bad, collectivism is bad, only markets and individuals are good... yeah, this is anarcho-capitalism. Like at no point do they recognize that under this line of thinking, people with a lot of money may be incentivized to cause harm to people without a lot of money, gee I wonder why they might not be so keen to acknowledge that?

> Markets prevent monopolies and cartels.

ah yes that's why the market produced the Sherman act. oh, wait, shoot, that was statist action motivated by collectivist goals.

> We believe there is no conflict between capitalist profits and a social welfare system that protects the vulnerable.

I dunno man, thought experiment here, do you make more money by curing someone of a sickness or by keeping them sick and charging them for treatment forever?

> We believe the ultimate moral defense of markets is that they divert people who otherwise would raise armies and start religions into peacefully productive pursuits.

yeah the idea that everyone wants to be either a murderer, cult leader, or billionaire is ... a totally normal idea that totally normal people have. Beyond being a deeply problematic worldview, the existence of the military-industrial complex challenges the notion that "if if weren't for markets people would do war". Marvelous logic on display here.

> To paraphrase a manifesto of a different time and place: “Beauty exists only in struggle. There is no masterpiece that has not an aggressive character. Technology must be a violent assault on the forces of the unknown, to force them to bow before man.”

he's quoting the Futurist Manifesto here, which ... pretty weird move, my dude. The Futurist Manifesto paved the way for the Fascist Manifesto, and if you're going "that's a reach", the guy that wrote the Futurist Manifesto cowrote the Fascist Manifesto with Mussolini. Yes, THAT Mussolini.

> Techno-Optimism is a material philosophy, not a political philosophy.

brave to make a bunch of sweeping politically-motivated generalizations and then to say it's not a political philosophy. Ok, if you say so!

dunno if you haven't noticed but people haven't been writing self-daemonizing processes that disappear into the background silently for ::checks watch:: at least a decade now. The practice of writing self-daemonizing processes was always a wart, a reflection of how low our expectations are of the job-control expressivity of cli shells. Grab ten programmers who use bash/zsh every day and say "you have a program that runs in the foreground forever, launch it in the background and close your terminal" and see what they do. You'll find some mixture of nohup, launching it and putting it in the background and disowning it, putting it in a tmux session and then detaching from the session, or deciding they have to put it in a container just to get that behavior, or some other workaround to deal with the fact that launching a process into the background is an ergonomic challenge for a lot of people. The circa-2000 status quo actually had a drawback or two.

it's really hard for me to express just how much content hits the front page of HN that, if you follow it, will make you worse at programming.

yeah I never suggested that heroku invented environment variables, and the idea that environment variables weren't common knowledge before heroku came along is ... let's say at best revisionist.

I... don't think the "flag" functionality is intended to communicate "this is bad advice".

the twelve-factor app is a set of recommendations from 2011 that are based less on engineering principles and more on the capabilities of Heroku and containerized infrastructure in 2011. For example:

> Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.

> The twelve-factor app stores config in environment variables (often shortened to env vars or env).

yeah the reason they argue for this is that the people that wrote this worked on Heroku, and the way that Heroku worked is you populated the environment variables from some fields in a web app. If you want your config history tracked in version control, or you do gitops, or you have k8s configmaps, or you want to have your configuration files on a mounted volume ... those things are all broadly fine; they keep the configuration state separate from the app deploy state. This document really confuses the forest with the trees and recommends things based less on actual engineering principles and more on the product capabilities of the corporation that produced it. It is an actively harmful set of guidelines.

nice try, Elon

> Another consistent part is earmarked to help Arduino grow even more in the US, where we recently opened an office in Austin, TX and bolstered our presence in Chicago, IL.

Oh! I want to hear more about what they’re doing in Chicago since I’m in Chicago.

yeah I don't like environment variables because it's all stringly typed and the lack of a thing you deserialize the config file into means that practically speaking, you can read the values from anywhere in a program; figuring out what's permittable in environment variables is very often a disorganized mess. .env files take all of the messiness of environment variables and then ... put them into a file, which is typically the thing that people who are using environment variables are trying to avoid, so ... I dunno, just use a configuration file imho, .env files are the worst of both worlds.

structured logging has been a thing for a long time, so I don’t really buy this argument.

the problem with monitoring and alerting derived from logs is that log ingestion pipelines usually have the property that when they get saturated, they get behind in time and catch up later. That’s more or less the opposite of what you want for an alerting pipeline.

Not having a backlog is actually the thing I like about it. Discord (and Slack) have this thing where because there’s a backlog, people expect other people to have read everything. I prefer the experience where the assumption is that the people not in the room are assumed to have not seen a message. It makes it more unambiguously a synchronous experience, whereas Discord and Slack chat is pretty ambiguous as to whether it is synchronous or asynchronous.

it’s a story about how all of society takes place inside of a video game and at no point in the story does it ever contemplate whether or not that is a good thing. The story is just “save the princess from the dragon” but the princess is the oasis.

it’s a different situation though: very few people have shipped guis in Rust, so the Rust projects are largely greenfield, while a lot of JavaScript front ends are legacy apps.

... the entire product is based on voting

> I am so sick of these shoesalesman trying to get you to adopt their platform which runs on another platform which runs itself on wishful thinking and startdust.

I think you misunderstood basically everything about this post. The author is not saying to adopt the author's platform, the author is saying that beyond a certain scale, every org is actually building their own internal platform whether they elect to view it that way or not: the author is arguing the opposite of what you describe in this sentence.

> You dont get people who do "DevOps" fresh out of college or people that have been barely using a computer for some time. You get the dudes with experience, but every time someone with experience makes up one of these buzzwords like "platform engineer" "lord of the box" or whatever, tons of people just assume the role without having the experience.

did you even read the post? From the post:

> We have an industry-wide shortage of expertise in the cloud space, a great IDP should have safe, dependable building blocks for designing cloud services quickly.

The ... entire argument is that you need strong foundations and reusable building blocks, and those things take expertise to build specifically because most product engineers do not have or want that expertise.

Your whole argument is describing something the post isn't saying.

> it was developed using GB Studio

yeah a lot of people in this thread seem to be completely unaware of GB Studio's existence, which is funny because a lot of people learn to make games in GB Studio nowadays. The GB Studio scene is pretty active.

right but if you have two crates you have to list the common dependencies twice, and you have to either keep them in sync manually or put the crates into a workspace and then use workspace dependencies, so now you have to declare the dependent crate three times.

“person with vested business interest says their sector/product/company is going to revolutionize the world” wow no way you don’t say

I read the article, you're refusing to see the forest through the trees.

connotation exists, you know

When you hire new people and they encounter this over and over again, onboarding drags on so, so much longer than it should, because people taking your position never think "we should reduce how complex this is", they think "they should stop being babies", and things just get progressively more obtuse and annoying and require more and more tribal knowledge instead of making sense.

It's not the word "simply", it's that if you think every thing that's easy for you is therefore easy, you're communicating that you don't think that understanding other people's experience matters.

the idea that learning to code is virtuous and having fun is bad needs to go away. Lots of people learned to code AND did beer bongs.