Yes, bad data centers. BAD BAD datacenters. whacks datacenters on nose with a rolled up newspaper

Just wait until you see how much they waste on unused life insurance!

Oh, did D have a single standard library for a while?

Remember KillerFS? Oakland PD remembers!

Economies of scale… And you said instance, which is AWS terminology… If you have the scale and the expertise to run a DC efficiently, expect significant savings. We pay a premium for opex over capex.

If you assume they are unprofitable, the Q only becomes whether they are more or less unprofitable by serving the older models for longer.

My caveats were clearly stated… After capital expenditure, it’s just operational costs, where electricity & cooling are the big ones.

At that point, it is insanely profitable to serve. The cheap API prices on open weights models hints at the profit margins involved in the US (the frontier labs and hyperscalers don’t open their books for us), unsurprisingly)

Therefore, the longer they can serve existing and lower cost models at the current rates, the better for their bottom line. It’s just common sense in business.

It doesn’t mean the company as a whole is profitable. I expect we’ll see turmoil in the coming months and years, and the prize will be compute capacity, with electricity & cooling options.

There is also a commercial aspect…

Bigger models are more expensive to train and serve…

Inference is currently insanely profitable if you have the hardware and the automation in place to support and serve it. At that point, it’s a money printing machine, and you want to squeeze as much out of it as you can.

While training new models is extremely expensive, and serving them probably makes less profit (at least initially).

Having an external brake applied to the frontier labs is likely good for their bottom line, while increasing hype and directing customers’ annoyance away from them.

It’s likely only a temporary benefit, though. The dragon will catch up and apply more pressure, both on inference price and capabilities.

I would also do #1, and I’d probably make it work (loooong time Linux user and persistent debugger).

#2 is probably simpler, both conceptually and technically. NAT and FW config is self-contained, and there are plenty of docs and how-tos.

Note: I’m not a proxmox user, so there could be some proxmox specific spanners… But I doubt it.

Indeed.

350 jobs is a drop in the bucket of the terrible hiring and firing decisions that companies make all the time.

This one just had an AI spin to it, so it gets repeated and reposted ad infinitum.

It’s not just about current LLMs, though. LLMs are being made to work 24/7 on the next generation of models (and not just LLMs), which may be quite novel or just more effective. The next generation might be the one to worry about… Or the generation after that.

LLMs can be used like an army of monkeys with typewriters, with evals guaranteeing progress. It’s inefficient, but effective.

Assuming it is possible to make progress (and I think it is), the logical conclusion is that progress will be made, and AGI and ASI will come

it gets integrated into automated killchains including a nuclear arsenal, and i hope noone is stupid enough to

Have you ever met a human? 🤣

The main issue was the motherboard. It’s too “new” and I ended up having to build a bunch of drivers to just get my computer to work exactly what Windows provided out the box.

Ok… To be fair, the drivers for Windows are probably all third party drivers. HW companies tend not to provide standalone drivers for Linux - either they contribute specs and/or patches that get incorporated to mainline, or do squat and eventually someone will reverse engineer it and create a driver.

There is so much hate for Windows, but you can’t beat their commitment to stability and backwards compatibility.

This isn’t the problem you just described, ftr. Linux often has a delay in supporting the newest hardware, but then supports it well and for a long time. OSS in general is good at that.

For example: my Wacom tablet is no longer officially supported on Windows (by Wacom), while it works out of the box on Linux.

Another example: Windows 11 refuses older hardware - not backwards compatible.

If you are talking about software APIs, that’s a different story. eg. There’s not much point in targeting Linux native APIs for games, because wine usually works better.

Mumble?

I recorded and copyrighted a WAV of myself farting once, and now I hear it everywhere. Fuck AI firms.

I bet the official CLI will get text ads… animated… with blinking text… They’ll follow it up with a release of Chrome Terminal, to view them better…

As much as I liked the initiative, it was always on shaky ground because games aren’t needed… now, if we could have tied it to the environment somehow (eg. hardware waste), or to the right of education (eg. safeguarding access to learning material), it would have stood a better chance.

Mijn hemel! Eindelijk kunnen we het Amerikaans-Engels uit de wereld bannen.

To be fair, protecting credentials and important data is the company and individual’s responsibility. The building blocks to restrict access are there, but are often not leveraged (even by large companies with the ability to invest)

Sandboxing is one of them: Both Codex & Claude’s sandboxing is reasonable (sandbox-exec, Linux cgroups & seccomp). Many others are lacking, sometimes deliberately.

I do most coding with Pi these days, and I have it heavily sandboxed. I expose sensitive services via a localhost network service with auth (typically for running scripts outside the sandbox). Reads are limited to the system binaries/libs, nad writes to the project dir & Pi’s own dirs. If I choose to give a particular session creds, then I have to be very deliberate. I also force egress traffic through a proxy (just logging for now, but I have plans)

I have no doubt some people can do that with a large project, a /goal loop, and (probably) poorly defined requirements.

My experience (using Claude models, but not Claude Code) is about $20-40/day worth of API costs in a collaborative mode, picking the right model for the task. Plan, implement, review & test features or bugs.

I get where I’m going faster, but not 10x faster nor 100x the cost. :-P

$14000 in API pricing is not $14000 in costs, though. Costs are hard to calculate because of the huge capital outlays and unknowns about hardware lifecycles, various business deals, and limited public knowledge.

It’s likely that inference costs for good-enough models will go down over time. China’s API pricing tells us the direction already. Energy costs will be a driving factor in the west, I guess.

So… they are almost certainly subsidizing plans right now, but on average, it won’t be by sooo much. Your average ChatGPT user will hardly use Codex, for example. Your average developer is not token-maxxing either.

Why are they subsidizing plans? To build a sticky customer base … which means they want you to stick to their tools - their coding agents/harnesses, their integrations, etc. Models are/will be increasingly interchangeable, so they are building sticky ecosystems instead.