materielle

Tech people seem to have a really difficult time grasping that the average person is not a utilitarian.

People are really bothered by perceived inauthenticity and injustice. And care about more things than the utility of the end product.

On top of that, we have a very out of touch political system that has continually ignored the will of the electorate. So then the tech people will say “see, the masses voted with their feet, they love the utility of AI generated art!”. Completely ignoring the perverse incentivizes and regulatory capture that led to that outcome.

If you were to poll 100 people on the street, they would be very against replacing human artists with AI.

I agree, Disneys’ dubs are generally of high quality.

Netflix seems to just grab radio announcers or something. The dubs are stripped of all emotions and acting. It’s like the voices are reading out an advertisement.

Obviously there’s exceptions, but Disney seems to employ actual actors. The dubs feel natural and native for the most part.

I don’t know, but typically when orgs don’t make logical decisions, it’s because internal politics are incentivizing something else.

I suspect that rate-limits would fly in the face of a lot of narratives like “Azure is ready for hyperscale”. And getting eyes on Github is probably a part of their Copilot product strategy.

The person you were applying to said “rate-limiting” but I think they meant “load-shedding”.

There’s a weird yet common attitude that nobody has to implement operating systems, databases, compilers, cryptography, consensus algorithms, etc because you should use off the shelf solutions.

This is obviously true, and there are surely more web devs than, say, compiler engineers.

But then the logic seems to go as far as to imply nobody does or should be doing these things. Where do they think the “off the shelf” solutions came from?

I worked at <big internet tech company>, and many critical systems written in the 90’s and early 2000s used bespoke compilers, caches, and consensus protocols that were hand rolled by the original developers.

Back then, most of these ideas were already present in academia. But the industry tech wasn’t quite there yet to run these huge services at scale without running into problems (paying a vendor, licensing, the open source solution not quite there or tunable enough to easily integrate it at the needed scale, no company wide consensus on a shared approach yet).

A lot of these handwritten implementations eventually informed the “off the shelf industry solutions” we have today.

I think that’s what gets me down about tech these days. There’s a weird almost anti innovation attitude, which is the opposite of what made me fall in love with this profession. I’m not saying to hand roll a consensus algorithm at your next start up. But there’s definitely a vibe these days that any sort of theoretical, creative, or innovative thinking is suspect. Get back to selling ads!

I don’t know anything about Germany’s postal service.

In the US, what the parent comment was getting it, is why are we even talking about this in the first place? What problem is privatization trying to solve?

As an American, I have zero complaints about our postal service or how much we pay for it. Apart from the fact that I wish there were more branch offices and a few more workers at most locations. I don’t think privatization will solve either of those.

Why do we need to reform something that already works?

Their argument didn’t make sense to me from the beginning.

One of its premises is that The Rich are some cohesive group that can trade amongst themselves in a hermetically sealed economy. That seems obviously untrue, there are a lot of different rich people with competing goals and motives.

Another false premise is it argues that finance and tech are completely detached from the so-called “real” economy. It uses the example of money moving between international account, detached from inherent physical value.

That also seems obviously false. The purported benefit of finance and tech is that they act as a force multiplier for the rest of the economy. In exchange they get to skim value off of the top.

If middle class consumption stopped or decreased in a serious way, finance and tech would be impacted. It seems weird to argue otherwise when we have such recent examples, like the great financial crisis.

Also, going back to my first point, if valuations of certain “main street” companies start to fall, it would set in a chain reaction. Because again, the rich aren’t a single cohesive group.

I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost.

Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software.

It’s not obvious to me that it would be theoretically impossible to build a cheaper package manager.

That’s not so special, though? There’s a difference between Google infra running Google services.

Versus any F500 company running their services on GCP.

It’s a bit whacky to think about because Apple will operate Google owned software on GCP. But it should be sandboxed just the same.

I’m not making a normative privacy argument here. Just pointing out that this is cloud business as usual. Perhaps it’s interesting Apple is doing it, but basically everything else is already using either AWS or GCP at this point.

What if I don’t care about affording more things? And instead want to live in an ethical society that prioritizes stability and universal access to housing, healthcare, and education?

I’m not sure this is generally true, and you’re ignoring a lot of context around the specific situation of GCC.

Just to make a point: I could throw out SQLite as a project that bans open contributions and is wildly successful.

Also, as others pointed out, Linux is technically open contribution bazaar style by 2000s standards. But if you look at how to actually get involved, there’s way more friction compared to the average GitHub project.

I actually think GCC falls into the same category. Even though it’s technically open contribution these days, it’s not exactly a free for all where any AI agent can open a GitHub pull request and get it reviewed.

You have to mail patches to a mailing list and follow a bunch of super specific and arcane rules set by the grey beards.

You’re being sarcastic, but I think you’d be surprised at how often you can say no to managers or even VPs and the c-suite and … have nothing happen to you.

I didn’t realize this until I was 32.

Obviously some companies will actually punish you. You might get fired from your Amazon or Microsoft job, for instance.

But typically what happens is the work just gets offloaded to another yes-man.

And the funny thing with promotions is most orgs don’t reward work volume. Nobody will remember that you took 11pm meetings or did that one unpleasant migration nobody wanted to do anyways.

One thing I don’t quite understand:

Wouldn’t it be in Amazon’s interest to run open models and sell time slots at around the cost of running them?

My only guess for why they don’t is that AI labs are currently selling their models at a huge loss, so this isn’t worth Amazon spending low-margin compute on compared to other higher margin products.

What I’m getting at, is maybe we won’t even need to run the models locally for the current status quo to implode. After today’s AI labs run out of free-money runway and actually have to sell their models at a price above running them, there will be the incentive for anyone with compute to just undercut by selling open-models-as-a-service at commodity prices.

There’s going to be lots of documentation. It will be AI generated and no human will ever read it. But there will be a lot of it.

I'm about to leave a shallow comment, but I am a bit skeptical of the supposed drop in inference costs. If AI labs saw a lot of potential there, they'd surely be bragging about it non-stop? So the fact that publicly available information is conflicted is probably a sign that at the very least, the numbers aren't amazing.

Yes I know there's no evidence and this is lazy reasoning. But there's probably a bit of truth to this line of thought.

I get what you’re saying, but the housing market is actually a really subtle issue in my opinion.

Just one example, owning a home protects you against price shocks. As others have pointed out, this can sometimes be a bad thing, because when prices decrease you are also leveraged.

But it’s pretty important to a lot of middle class people that they are protected against forced relocation due to 5x housing price increases.

Of course, there’s other reasons to not own a home.

My point is that localized housing markets have all sorts of factors that are perfectly explainable by economic theory but aren’t just “Econ 101, run the supply and demand” curve.

This brings to mind two thoughts:

First, that this is challenging to scale across large orgs. Even if your plans produce high quality code, that isn’t true for everyone. I’m definitely struggling with slop code being collectively mailed to me for review my our 1,000 engineers that were told to use their AI subscription all at once.

I feel like we should be taking “prompt engineering” more seriously. And when people mail me code to review, it should also include the agentic workflow and plan. So that when code isn’t up to quality, and can have a discussion about the prompts used to generate it.

My second thought is related to your senior engineer comment. This isn’t surprising, because in most engineering orgs, seniority is completely unrelated to code quality. In fact, many orgs incentive the opposite: “senior” devs that push out buggy code quickly and push accountability downhill to the junior devs.

He didn’t hedge at the end. Nate always writes the models before election season then doesn’t touch them apart from actual bug fixes. The model actually organically predicted 30%.

I still think that’s about accurate. Maybe it should’ve been 40%.

Everyone forgets that it was a pretty close election. Clinton could’ve won without the Comey announcement.

Also, they don’t any plans for the IP, and Nate would’ve paid above-market rate just to take over and preserve the content for posterity. He estimates that they deleted 200,000 hours of human labor.

This is just some Disney suits being extraordinarily petty.

Which brings us to the next layer of modern dependency management insanity:

The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.

At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.

As recently as 2015 when I attended a middling CS program, we had in-person timed exams where we had to write down DSA implementations on a blank sheet of paper in Java.

We were deducted points for trivial syntax mistakes.

If these stories I keep hearing are true, then university programs have really taken a nose dive recently. This isn’t a “back in my day” thing, but within the past 5 years.

The pace of the purported decline makes me question if some of these stories are sensationalist. But I don’t know, I keep hearing about them.

One important piece of context that might make all these stories less confusing for non-googlers:

Code references are less important inside Google editors, because we have a code viewer tool inside the web browser.

Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually trace referenced, and overall has a million little features optimized for reading code.

We also have a code reviewer tool, and a separate tool to run and view CI runs.

So what’s left for the editor? Syntax highlighting?

I would tend to view code, run tests and CI, and review in separate tools specialized for their specific use case. The code editor was just a place where I would type in my changes.

I’d imagine this workflow feels weird to people who learned in one-stop-shop IntelliJ and GitHub world. But I can’t emphasize how much better these other tools were compared to GitHib. So a code editor that also lets me read, review, and test code didn’t really matter for me when I had a collection of smaller tools specialized for each individual task.

If you want a laugh, Google a tutorial for how to read a file. You should also know that all the tutorials are wrong, because they fail to handle at least one footgun or another.

There is no “modern” alternative. If you read Reddit threads, C++ programmers actually believe that it’s a reasonable file reading API.

Most companies that I’ve worked at have just implemented our own on top of the OS syscalls. Which is annoying because it requires at least a Windows and UNIX variant.

Look, I like C++. I’ve been programming in it for years. But some of the stereotypes around C++ programmers are true. I still occasionally run into design decisions so untethered from reality that it still shocks me after all these years.

Because you can naively iterate through a million items faster than an additional network round trip would take.

So a lot of code quality debates don’t matter for the typical enterprise app. While a dev spends their afternoon shaving off 100 nanoseconds in the hot path, a second developer on a deadline added a poorly thought out round trip that adds 800milliseconds.

This architectural problems are also more difficult to unwind later since they tend to have cascading effects.

It’s because in most enterprise contexts:

1) Most bugs are integration bugs. Whereby multiple systems are glued together but there’s something about the API contract that the various developers in each system don’t understand.

2) Most performance issues are architectural. Unnecessary round trips, doing work synchronously, fetching too much data.

Debuggers and profilers don’t really help with those problems.

I personally know how to use those tools and I do for personal projects. It just doesn’t come up in my enterprise job.

I agree and that’s the point I was trying to make.

Linus’s contribution is a great one. He learned from prior tools and contributions, made a lot of smart technical decisions, got stuff moving with a prototype, then displayed good technical leadership by handing it off to a dedicated development team.

That’s such a good lesson for all of us devs.

So why the urge to lie and pretend he coded it in a week with no help? I know you’re not saying this, but this is the common myth.

Im specifically pointing out the false history that Linus god-coded git and handed it to us on the 7th day.

In reality, it was a collaborative effort between multiple smart people who poured months and years of sweat into the thing.

I seem to agree with you. The real story is a good thing and Linus made important contributions!

But he didn’t create git by himself in a week like the parent comments argue.

It’s not being pedantic.

The parent comments are arguing that 17million for git 2.0 is insane because Linux wrote the original in a week.

Except that’s not true. He sketched out a proof of concept in a week. Then handed it off to a team of maintainers who worked on it for the next two decades.

It’s also not pedantic because Linus himself makes this distinction. He doesn’t say he coded Git and specifically corrects people in interviews when they this.

I think AI bans are more common in projects where the maintainers are nice people that thoughtfully want to consider each PR and provide a reasoned response if rejected.

That’s only feasible when the people who open PRs are acting in good faith, and control both the quality and volume of PRs to something that the maintainers can realistically (and ought to) review in their 2-3 hours of weekly free time.

Linux is a bit different. Your code can be rejected, or not even looked at in the first place, if it’s not a high quality and desired contribution.

Also, it’s not just about PR quality, but also volume. It’s possible for contributions to be a net benefit in isolation. But most open source maintainers only have an hour or so a week to review PRs and need to prioritize aggressively. People who code with AI agents would benefit themselves to ask “does this PR align with the priorities and time availability of the maintainer?”

For instance, I’m sure we could point AI at many open source projects and tell it to optimize performance. And the agent would produce a bunch of high quality PRs that are a good idea in isolation. But what if performance optimization isn’t a good use of time for a given maintainer’s weekly code review quota?

Sure, maintainers can simply close the PR without a reason if they don’t have time.

But I fear we are taking advantage of nice people, who want to give a reasoned response to every contribution, but simply can’t keep up with the volume that agents can produce.

No he didn’t. He built a proof of concept demo in 7 days then handed it off to other maintainers to code for real. I’m not sure why this myth keeps getting repeated. Linus himself clarifies this in every interview about git.

His main contributions were his ideas.

1) The distributed model, that doesn’t need to dial the internet.

2) The core data structures. For instance, how git stores snapshots for files changes in a commit. Other tools used diff approaches which made rewinding, branch switching, and diffing super slow.

Those two ideas are important and influenced git deeply, but he didn’t code the thing, and definitely not in 7 days!