Live data from Hacker News

MinIO Is Dead, Long Live MinIO

blog.vonng.com

31–40 of 95 posts

Re: MinIO Is Dead, Long Live MinIO

#31
post #6

Earlier quoted context omitted.

The copyright for Minio consists of: - Code written by the Minio team, which they have full ownership of and can relicense as they wish - Code written by third party contributors, where Minio required the contributors to provide Minio a BSD license to use the contributions but only published it to other people under AGPL. So the AGPL doesn't bind Minio themselves because of their licensing policy. (Which is why while…

Was going to mention the CLA. Each time you sign a CLA you're doing free work. Never do that. Keep and maintain your patches locally instead.

Sometimes that’s far more work than it’ll ever be worth.

If I get my patches upstream, then I don’t have to waste time reintegrating patches and rebuilding packages when I could instead be doing productive things.

Re: MinIO Is Dead, Long Live MinIO

#32
post #6

Earlier quoted context omitted.

The copyright for Minio consists of: - Code written by the Minio team, which they have full ownership of and can relicense as they wish - Code written by third party contributors, where Minio required the contributors to provide Minio a BSD license to use the contributions but only published it to other people under AGPL. So the AGPL doesn't bind Minio themselves because of their licensing policy. (Which is why while…

the FSF position is that GPL is unenforceable without a single copyright owner, which is why almost all gnu projects, linux, canonical/redhat/etc projects have a CLA or something functionally similar

That would seem a bizarre position from the FSF, since it would make the license on combined GPL works unenforceable. Do you have a source for that?

Re: MinIO Is Dead, Long Live MinIO

#33
post #5

It's nice that people are taking this up, and one of the main benefits of open source in the first place. I have my doubts that this will succeed if it's just one guy, but maybe it takes on new life this way and I would never discourage people from trying to add value to this world. That said I increasingly have a very strong distaste of these AI generated articles. They are long and tedious to read and it really mak…

I agree completely. I know everyone is tired of AI accusations but this article has all of the telltale signs of LLM writing over and over again. It’s not encouraging for the future of a project when the maintainer can’t even announce it without having AI do the work. It would be great if this turns into a high effort, carefully maintained fork. At the moment I’m highly skeptical of new forks from maintainers who are…

An app that basically reimplements a well documented and tested api is the best possible use case for ai development.

Re: MinIO Is Dead, Long Live MinIO

#35
post #25

> MinIO as an S3-compatible object store is already feature-complete. It’s finished software. I don't see how these two lines can be written together. The goal is either to remain S3-compatible or to freeze the current interface of the service forever. As it stands this fork's compatibility with S3, and with the official MinIO itself, will break as soon as one of them pushes an API update. Which works fine for existi…

The S3 API is quite stable and most new features are opt-in (e.g. ApplyIfModified) or auxiliary (e.g. S3Tables). It’s highly unlikely that S3 proper will break backwards compatibility for clients with any future API change. So if all you need is basic object storage that works with existing S3 clients, then MinIO is enough. The fork just needs to keep CVEs patched and maintain community hygiene (accept new PRs for small bug fixes, etc.). And as the author points out, this is much easier in the age of AI than it might have been previously.

Re: MinIO Is Dead, Long Live MinIO

#36
I never understood why one would use MinIO over Ceph for serious (multi-node) use. Sure, it might be easier to setup initially, but Ceph would be more likely to work.

For the single node use-case, I'm working on https://github.com/uroni/hs5 . The S3 API surface is large, but at this point it covers the basics. By limiting the goals I hope it will be maintainable.

Re: MinIO Is Dead, Long Live MinIO

#37
post #20

Earlier quoted context omitted.

To be fair, most open source is like that. The most famous one I can think of right now is xz.

A vastly less complex project whose maintainer burned out. You're not wrong, but this only underlines how unsustainable this is.

Yeah, I agree.

But we have to rally around something.

Re: MinIO Is Dead, Long Live MinIO

#39
This had a ton of LLM-ese in it, so, here's an LLM explaining it. I read it, agreed, then read it again for LLM-ese, then shared it. I recommend this pattern when using LLMs. Especially when claiming you'll replicate the role of a 9 figure company with an LLM.

LLM generated TL;DR: The factual sections read like a real person who knows what they're doing. The rhetorical flourishes read like someone pasted their draft into Claude and said "make it more compelling." The work deserves better than the prose it got.

LLM output given "X Identify parts written by an LLM"

Here are the passages that read as LLM-generated rather than naturally written:

*Overwrought dramatic pivots (LLMs love the "Not X — Y" antithesis):* - "Not an obituary — a resurrection." - "Not 'unmaintained' — officially, irreversibly, done." - "That demand doesn't disappear — it just finds its way out."

*Explicitly labeling rhetoric that should speak for itself:* - "The ironic part:" — just show the irony, don't announce it. - "The consensus in the international community is clear:" — "international community" is overbearing. "is clear" is LLM throat-clearing. - "That's the beauty of open-source licensing by design" — "That's the beauty of" is a hallmark LLM filler phrase.

*Grandiose one-liners that try too hard:* - "git clone is the most powerful spell in open source." - "a digital tombstone" - "If December was the clinical death, this February commit was the death certificate." — the metaphor was already established in the heading; extending it here is overworked.

*LLM vagueness / filler:* - "Things are different now." — says nothing. - "Consider:" as a standalone transition into the Elon/Twitter example. - "I believe the maintenance workload is manageable." — the hedging "I believe" adds nothing; just say it's manageable.

*Cliché deployment:* - "the dragon-slayer has become the dragon" (in the related-article blurb) - "Eating your own dog food is the best QA." — explaining the idiom ("dogfooding") one sentence before, then restating it as a maxim, is the LLM pattern of using a phrase and then making sure you understood it.

*The AI-hype paragraph is the worst offender:* > "With tools like Claude Code, the cost of locating and fixing bugs in a complex Go project has dropped by *more than an order of magnitude*. What used to require a dedicated team to maintain a complex infrastructure project can now be handled by *one experienced engineer with an AI copilot*."

This reads like an LLM writing about itself — vague quantification ("order of magnitude"), the buzzword "copilot," and the utopian framing are all telltale. The Elon/Twitter analogy that follows ("Consider:") makes it worse, not better.

*Overall pattern:* The technical/factual sections (the timeline table, the build instructions, the console revert explanation) read like a real person. The editorializing and rhetorical flourishes — especially the intro, the "But Open Source Endures" section, and the "AI Changed the Game" section — are where the LLM voice creeps in most heavily.

Re: MinIO Is Dead, Long Live MinIO

#40

Earlier quoted context omitted.

I agree completely. I know everyone is tired of AI accusations but this article has all of the telltale signs of LLM writing over and over again. It’s not encouraging for the future of a project when the maintainer can’t even announce it without having AI do the work. It would be great if this turns into a high effort, carefully maintained fork. At the moment I’m highly skeptical of new forks from maintainers who are…

An app that basically reimplements a well documented and tested api is the best possible use case for ai development.

I have nothing against a skilled maintainer with attention to detail using AI tools for assistance.

The important part is the human who will do more than just try to get the LLM to do the hard work for them, though. Once software matures the bugs and edge cases become more obscure and require more thoughtful input. AI is great at getting things to some high percentage of completeness, but it takes a skilled human to keep it all moving in the right direction.

I would cite this blog post as an example of lazy LLM use: It's over-dramatic, long, retains all of the poor LLM output styling that most human editors remove, and suggests that the maintainer isn't afraid to outsource everything to the LLM.

Post reply on HN