> Lot of Australians can simply stop paying for power now due to free power on offer and batteries
This is overstating things.
Even if you only draw power during these three hours of the day, you still need to pay a daily supply charge, which makes up about 30%(and growing) of the average household electricity bill.
You would need about a 15 kWh battery to cover your household usage outside of these three hours.
A 13.5kWh Tesla battery system will cost about $15k installed, the taxpayer will cover about 30% of the battery cost(exc installation), which brings it down closer to $11k.
If you live an an owner occupied detached house(about 50% of Australian households), and you can afford a ~$11,000 for a battery, then you can probably pay off the battery within about 10 years.
What I've read, and it seems reasonable to me, is that glacier is mostly just stored on the same HDDs that everything else is stored on.
What you need to understand is that a modern hard drives are severely limited in the amount of IOPS they can perform. Disk size has grown, but read and write speeds have not kept up with it.
In 1990 you could read a whole hard drive in 2 minutes, in 2026 as sizes have grown it takes the entire day.
As a system designer you want the maximum utilisation of your hardware, so you want to be close to saturating the IO that your drives are capable of.
What that means in practice is that only a tiny portion of the drive can be allocated to files that are read often.
That leaves the rest of the drive for files which are not used very often.
It's hard to imagine how these API differences can be explained by the different underlying block device. I don't see any good reason you couldn't support these operations on a HDD.
I suspect it's more to do with the fact that with One Zone is a clean rewrite of large parts of the application stack that makes up S3.
S3 is made up of hundreds of microservices[0], there probably isn't anyone at Amazon that actually understands the whole system. Refactoring it to support these features probably requires coordination between a lot of different teams.
They might have petabytes of metadata, making a change to how metadata is persisted probably requires a massive risky data migration.
Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code..
"Stronger" is absolute bullshit. No data race prevention. No intra-object protection. Mandatory GC, and 5x the compute cost. Nothing like a statically safe language.
I think I saw the Rust based implementations sometimes used a separate thread for background tasks like statistics reporting. Not much additional in the way of "directly" using threads, but I wonder how many could actually be any faster with direct threading.
Are there any unionized game studios that continue to produce highly acclaimed games?
Bethesda used to make great games, but the last great game they made was Skyrim in 2011, they unionized in 2022, and just recently they had some big layoffs.
CD Projekt made the highly acclaimed Witcher 3 in 2015, Cyberpunk disappointed on it's release in 2020, although it's reviews are mixed. CD Projekt unionized in 2023.
Blizzard have been in decline for a long time, they mostly focus on maintaining the cash cows games WoW and hearthstone. Although Diablo has is mostly well regarded(ignoring immortal). They haven't made any new ambitious game for a while. Their last attempt at making something ambitious was Titan, a cancelled MMO that they worked on for 6 years and supposedly spent $80 million on, cancelled in 2013.
The decline seems to begin well before the unionization, so I wouldn't say it's causal, it's more of a symptom of the company no longer being a place that can foster high functioning teams, where people feel like they are valued and working on something important.
> Are there any unionized game studios that continue to produce highly acclaimed games?
In order for that to happen, a game studio that is currently producing highly acclaimed games would have to unionize. All of your examples seem to be of studios that are past their peak... Does unionizing turn that around? Seems like no, but what does?
Anyway, Acclaim Games shut down in 2004, and again in 2010. There's a new Acclaim as of 2025, so maybe there's a chance highly Acclaimed games will come out, but I don't think they're unionized, and it might just all be vapor and puffery.
Aguably those things would have happened with or without a union. E.g. it's extremely rare that any studio could repeat a masterpiece like Witcher 3, and CDPR's earlier Witcher titles also are far away from that quality. This game really was a unique 'perfect storm'.
From what I've seen, success and following decline are directly related. Once a studio becomes successful, they start to attract the sort of people (especially in leading positions) who are great at selling themselves but not much else, and the studio founders haven't learned yet to separate the chaff from the wheat. And then after a while suddenly the company is full of 'mercenaries' which only care about their own carreer advancement but not about the games they create.
I live in Sweden, but my company is not unionized (somewhat unusual). Non-unionized companies at least in tech tend to be _overtly_ better places to work than unionized ones simply because people have the _option_ to go to a unionized company. So the non-unionized companies have to make up for it with better work conditions, benefits and pay.
Even if you are not unionized you benefit from other people being unionized in your profession/area.
My uneducated take here is based my my friend's experience, who is an electrician. He's happy to be more flexible than the law allows him to. Work more hours, longer shifts, worse times of the day. Whatever gets the job done as good as possible. But there's an expectation of mutual respect here. If the boss starts not compensating him sufficiently for the work he is asked to do, not giving him time off and periods of calm, and listening to him when he thinks he's nearing his limits, the system doesn't work.
Just like laws in reality are the to protect the average Joe from an abusive employer, unions are similarly a strength in numbers approach to being treated better.
It seems unionisation is one way people slam the breaks on companies that don't treat them fairly for the effort they are expected to put in. Your evidence seems to indicate the companies had plenty of chances to ask "why are people unhappy" before their employees unionised
I'm not sure I follow the correlation or causation logic here. By the evidence presented the conclusion I would draw is it's very difficult to have repeated success. All your stated failures predated any unionisation.
If anything to unionization seems correlated simply to how long a company has been around.
There aren't many studios that have managed long term repeated success.
The best contenders would be:
Nintendo EPD, Nintendo's internal studio.
~40 years of sustained high quality games.
FromSoftware is also about 40 years old, although didn't really see breakout success until Demon's Souls in 2009.
Naughty Dog, founded in 1989, released Crash Bandicoot in 1996, and have continuously maintained a high bar.
Rockstar is 27 years old and makes great games, though it's been about 6 years since they released a game. Also I believe they have recently begun to unionize.
Valve is also worth a mention, they never really dropped the bar in terms of quality, they just lost interest in making games because they make so much money from Steam.
I guess we will find out when GTA 6 comes out as Rockstar has become unionized.
Although actually…Rockstar didn’t become unionized until most of GTA 6 had already been completed. So I guess we’ll find out when their next game comes out.
Fair point on WoW and I totally forgot Starcraft 2.
Diablo 3 I played extensively, yet I felt somewhat disgusted by the end of it.
But it's a product of that time. If I think about the games I played recently, nothing holds except Warcraft 3 with the custom maps.
I have little time so I play only what I consider "top" for my taste and drop everything else, even in the "good" category.
Due to that my last few years have been games that last me hundreds and hundreds of hours with high satisfaction, or shorter games with high satisfaction.
Either way, I would never play diablo 3 the same amount of time I did back in the day, the only reason I played was because of the friends I had
I don't see how this is a meaningful statement, as it implies there are games that cross this threshold. GTA V and Cyberpunk are some of the most critically aclaimed and beloved games ever made?
I don't think "raw, unfettered capitalism" and unions are orthogonal.
Actually, quite the opposite - in a free market, labor is free to organize in any way they want. If they have enough leverage over the employer, they'll succeed.
The anti-free market part is the regulatory quagmire that the US has in place for organized labor.
I think that's the thing that most people take umbrage with.
I don't know for sure, but I've heard from knowledgeable folks that it is more effective in Europe.
They are a little bit, because collective action is very hard. If everyone chooses to participate and pay the cost of organizing it is worth the cost and a union will happen. But if a number of people choose not to then everything falls apart, as it is no longer worth it for anyone to pay the cost and the union can't function. Often the benefits of a union are also a public good, meaning everyone gets the benefits of a union fighting for better working conditions whether they pay the cost or not. If so, then there's little incentive to pay and the union will have trouble keeping itself alive.
Unions need some external extra incentive, like the state forcing them to exist or subsidizing the cost of organizing, to exist long term.
> I don't think "raw, unfettered capitalism" and unions are orthogonal.
In a vacuum, no. If the most profitable approach means involves maintaining an "all star" cast to keep the best team happy, then everything works out. That's the athlete/celebrity model.
But current dynamics has games divorced from quality to generate the most profit, and companies work to minimize expenses instead, via the assembly line approach. Devaluing labor to maximize money makes unions inevitable.
One theory is that building/maintaining games is knowledge work, and each worker you retain helps with that. But as always, human social groups can deviate against the common good, but they can also boost it, and in this case even protect against abuses of the masses workers by management.
the expectation combined with more studios doing stuff, the fact that video-games don't have 100 years (so it's a maturing art form, somehow) and also investment money... i believe there's much more chances of quality declining on companies by the hook of investors or at least less innovation (which seems to drive a bunch of 'unicorns' on this field)? graphics kinda topped by now, there's no more magic on realism/fancy graphics! maybe at some point role-play/storytelling will get more complex/infinite with AI but it's not clear how or if it'll, as we have player driven multi-player video-games for quite a while, like Albion or some much older: https://www.havenandhearth.com/portal/ ... maybe man vs. the machine in a sensible way and not those engines stomping pro-players on Dota
I think Valve sets a good example for an alternative, while not union they operate with a flat structure and is not publicly traded which sets them apart. They're kinda like an elite guild of game developers.
I'm not really sure how you could know this? For all we know all the employees are unionized and haven't felt like they need to push management for official recognition.
Let's not get too excited until the game is actually released. Cyberpunk was also irrationally hyped and then was released as a turd which then took 5 more years to become a merely 'good' but not great game.
Unionization seems to be a secondary effect of strategic failure. If there is a causal relationship, I think it happens in reverse.
Walking the game theory backward, if the team was executing successfully and productively and everyone is getting paid fat bonuses then I don't think there is much motivation to get political in the workplace.
Only after the soul has been completely extracted from a company/team does this process seem to occur.
I wonder how many examples there actually are of the people in the trenches doing the actual work getting a 'fat bonus'.
E.g. the idea that unionization might not be a bad idea usually starts with teams not getting any bonuses after they created a highly successful game, and instead the company preventing such 'problems' by firing most of the team right before a game ships.
Linear Technology gave the same bonus multiplier based on overall company profit, paid out every 6 months. Most years this came out as an extra 30% on top of base comp for literally everyone at the company. Then the founders retired, Linear got Acquired by Analog Devices, and the program was scrapped the next year.
There's also RenTech, which allows employees to invest in their private fund that pays out 40% annually.
So to answer your question: not many, especially not in games.
So the village is the only information given about a candidate?
How else is the model supposed to interpret the intent of the prompter, other than wanting them to attempt to find and discriminate on patterns related to the village, regardless of how successful it is at that task?
One way to interpret these results is that the LLMs tested are badly calibrated for this kind of multi-armed bandit problem. Even if the intent is for the model to find and exploit patterns, it's bad at doing it (or rather, at recognizing that there is not in fact any pattern).
If it were vulnerable to XSS, why would you even want it properly signed by a CA?
People almost never inspect the certificates of working websites, the only time they might look at it is when it fails validation.
I actually do like to view certificates of working sites, because it can be interesting to see what's listed in the Subject Alternative Names field. It can lead to some interesting observations about what sites are linked.
I don't use any skills, what kinds of skills are people finding most useful?
For general tasks, the model seems perfectly capable of figuring out things itself, for project or environment specific tasks, I just put that information in the readme or agents.md file.
I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.
It's possible I invented skills before they were common. I've always had some instructions in agents.md that are something like "when working with typescript, read prompts/conventions.ts.md, when working with our fooBar module, read prompts/foobar.md"
I'm not sure if this differs greatly from skills. Maybe my wording makes these "skills" less likely to be read at the correct times, but I haven't seen an issue.
I try to keep agents/Claude.md as tiny as possible. With high level "truths" that don't change. Stack used, invariants, file structure, and some scripts.
Skills are more for things you do often. I run mutation tests, type check,linting,etc. I _could_ just prompt and copy/paste the same prompt each time I need to, or I can just run /tests.
I also have skills for specialized tasks I need every once in a while, like a ux skill, a text skill optimized for xyz, etc.
Most guidance I’ve read, and experienced success with, is keeping a lean agents.md file and building out a tree of docs or skills that an agent can navigate via progressive disclosure.
Depends on how much information and details you have. The agents.md always goes into context. Detailed testing or process information might be excessive, when agent is working on UI. Skills are pulled when needed.
I handle the context problem by splitting the details to dozens of small md files. Agents.md acts as a router that directs the llm to correct documentation file/folder according to the task at hand.
This documentation is its own git repo, and the agents.md file has an explicit instruction to update the docs when it has learned something general that can be useful in future sessions. I then occasionally review and prune those docs.
The description in the front-matter (at the top of the skill markdown file) is the only thing in the context and used by the agent to determine when to read in the rest of the skill file.
skills are just an agents.md broken up into chunks so you can manage and share them separately. unfortunately there's no real good workflow for managing or sharing them separately, so most people end up treating them exactly the same way they do agents.md.
So the term used internally is to make things "Determinishtic". I use skills extensively, combined with SOPs, scripts and MCP servers.
An example skill I have is SessionMiner, which is installed via post session hooks in Claude and Kiro, and analyzes the session, what was accomplished, and whether or not it should be turned into a skill, then when it summarizes it, the decisions it came to and either fires off a message to me for followup if it decides a new skill or tool should be built, or it catalogues the approach so that future analysis can identify trends in how I use the tools.
Over time it has built me a fairly decent stable of repeatable skills and tools, and highlighted process deficiencies and nominated process changes that I have pursued.
Another skill is a communications analysis skill; I started using it summer last year I think, and it scans my communications across a broad cross-section of my activity online. It tracks the commitments I make, ensures that I follow up with people that I might miss, ranks and scores my communication against my own personal targets that I set to make sure that I am communicating effectively. As a person who has had a decently successful career despite autism spectrum and unmedicated ADHD (I was medicated, but unfortunately each medication I tried had adverse side effects), it has made me much more effective in tracking work and following through, especially on the "boring" stuff that is actually critical to being a dependable team member, and effective partner for the teams I support.
You're putting a lot of trust into the judgement abilities of what is just a next token predictor there.
I can see what the goals are there, and they do make sense I suppose, but I'm not confident that what you're handing off there can be handed off to that degree.
But maybe that is not the point and the point instead is to see what the LLM thinks would be correct, and then think about that and collect learnings about the world from it.
It might not be right, but it still tells you how normal people think. So that's useful.
Just a very roundabout way to achieve that, but that's fine, I guess.
"Another skill is a communications analysis skill"
It is interesting how people delineate what is a "skill". A 50 word prompt can be called a skill. This process you are describing sounds like it is highly authed and polling or hooked into multiple apps (slack?, text messages?, email?, forums, etc.) and then piping output to an LLM and to generate reports that it pushes to you based on output. You might need some data store to hold all the different communications locally as well.
That is almost a full on app/service that uses an LLM for one layer, but it is still just called a "skill".
Your agents.md is a good place for high level facts, but if you have something that requires a lot of info to explain (ie: if there is a complex build process, testing patterns, things like that), loading up your agents.md for every request may be a bad idea. Offloading that information to a skill ensures it's only included in the context if you're actually using it.
How about linking to a separate docs file from the Readme, same as how you'd split separate topics into different files for humans? The context cost is low and as far as I can tell it's pretty much how Claude's "memory" feature works.
That splitting is basically what a skill is, with some instructions as to when to load it. Depending on the harness used it might be quite equivalent, but not sure how easy it follows links in the readme compared to skills (which is just a glorified name of a readme anyways)
Right, it's all just text file management. My point is that if I can add a few lines of description with links in my readme/agents/etc instead of manually including skills in the prompt, without any downside, I'd rather do that.
Something else I want to add on to be more specific is that I use skills to document tasks that my model doesn't know how to do out of the box. For example, there is a jira cli[0] that I use for interfacing with jira. If I just say something like "add an issue for X on jira", the model will have no idea how to interface with jira. I could add that the jira cli is installed on my system, but it's not popular enough for the model I use to just know how to use the CLI, and it will end up spending a lot of tokens guessing how to use it, failing, reading the help output, trying again, etc. Adding a skill for jira lets me capture how to use the cli, and makes prompts like the original usually work first try. If something still requires the model to iterate with the cli, I will ask the model why it failed originally, and ask it to update the skill file accordingly, to avoid the same failures in the future.
I use skills for offloading work onto subagents. By configuring the skill to use a specific model it gets enforced at the harness instead of depending on the good will of the orchestrating model to actually delegate. This also saves context.
Today Fable had to fetch a zip file from a web page with a eula prompt, then get at a file in a disk image in the zip.
This is something that will need to happen a lot as part of this project.
I asked Fable for a skill/script combo suitable for Haiku to accomplish the task, and now that task happens at minimal cost during an analysis run.
I have a couple of skills with project-specific conventions for how to write a plan and how to write HTML-generating code. But they could probably just as well be .md files in a docs directory, linked to from the AGENTS.md file.
Well, for non-general tasks, of course. For example particular tooling that's required for the environment.
I will often make a skill out of the docs for any of the frameworks or libraries that we're using but with which I'm unfamiliar. When I'm creating that skill, I focus on idiomatic implementation and usage. It's not enough for the code to work—I want it to work "with the grain" and "through the front door", as it were.
By default, these models are just all too willing to reinvent the wheel and monkeypatch as they go.
Claude will do this for you after a few times. But yes, I have a skill called plan-to-epic which creates a Jira epic and ticket per milestone. It helps my agents persist context and, because I’m terrible at competing with my coworkers for “visibility,” means I can point to all my work if asked.
> I don't use any skills, what kinds of skills are people finding most useful?
I create/edit/delete at least one skill per day. I can't imagine working effectively without those files.
The most common case: if I see something took AI too much time and tokens and it is done, I ask my Cursor immedietly after to save it as skill. So next time I do the same I just refer to skill. I don't need to remember the name of the skill, I just mention something like "do {explaining briefly the task}, you have done something similar in the past and it is saved as skill"
One way I use skills, which I don’t see mentioned very often, is as “shortcuts”. Imagine some frequently issued prompt like “fetch origin and rebase this branch onto origin/master and resolve conflicts”. I make that into a little skills file called “rebase” with a one sentence description, and next time just type something like “/reb-tab-enter”.
I made an agent skill for `tsort` and that unlocked a lot of interesting things.
Giving the agent an external tool to consider the sequencing of anything with dependencies led to some creative construction and offloading sequencing not unlike offloading calculation. (I also made a `bc` skill).
https://github.com/sj4nes/clanker-tools is where I've been riffing on this. My plan is to collect not "just skills" so much but "capsules" of reliable knowledge that agents can pull without confabulation. I'm already hitting the organizational stumbles, so this HN thread is right-on-time.
So the main feature of this project is that it's easy to fork a database, however it's 1.2x to 4x slower than sqlite, and it's level of testing and validation will be nothing like sqlite.
The simple way to fork a sqlite db is just to copy it, but if that is too slow you could use it with a copy on write filesystem, either something native, a FUSE filesystem, or build a sqlite VFS.
That would probably be faster to build, faster to run, and easier to validate.
> The simple way to fork a sqlite db is just to copy it
SQLite recommends against doing that [1] while a transaction is active, because the copy might have some pre/post data in it which could potentially cause corruption. Presumably this isn't an issue with copy-on-write filesystems assuming they copy atomically, but I probably still wouldn't do it, instead use the backup API or VACUUM INTO (if nothing else, because VACUUM INTO will also obviously VACUUM the copy).
If you're not attached/writing to it, then of course it's fine.
That's what I'm saying, if you have a CoW filesystem, backing up with atomic snapshots is almost certainly fine, SQLite's advice against copying probably doesn't apply to that. But just typing `cp` in a terminal is probably not a good idea if a transaction is active (even if you're on a CoW filesystem, `cp` in experience usually isn't atomic without some flags).
No? Where are you getting those figures? It feels like you may have pulled that from the 125 and 400 us numbers?
> The simple way to fork a sqlite db is just to copy it, but if that is too slow you could use it with a copy on write filesystem, either something native, a FUSE filesystem, or build a sqlite VFS.
That wouldn’t really solve what dolt does though.
> and it's level of testing and validation will be nothing like sqlite.
They’re using the other dolt tests as well as the SQLite tests. Nothing will hit the level of real world testing SQLite does.
Dunno if I'd have directly attributed the writing to LLMs had I not read this, but I wouldn't have opened the link otherwise. Holy crap, that reads just like the documentation / explainers that I have Claude write for future agents or to remind me what I had it do in the future.
Ah yes so the 4x slower isn’t really a real world case and you’d have to explicitly measure yours - it’s not a fixed slowdown but depends on table size - and it’s for doing many many single inserts in a row, which you’d be batching either way.
reply