Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MinIO Is Dead, Long Live MinIO

blog.vonng.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: MinIO Is Dead, Long Live MinIO

#51

Post by PunchyHamster »

dijit wrote: post #19
PunchyHamster wrote: post #9

Earlier quoted context omitted.

Seeing what coming ? They pivoted into storage for AI, lone maintainer is not threat to their business model

Still, I would probably abandon the name for trademark enforcement reasons. It's low hanging fruit for them if they want to kill you. (this is also why the Pentium was called the Pentium instead of the numbers that processors used to be called.. and why the gameboy copyright text was embedded into the ROMs)

Oh yes, I'm sure that if this fork gets any momentum they will send lawyers

Re: MinIO Is Dead, Long Live MinIO

#52

Post by teeray »

chatmasta wrote: post #35
paxys wrote: 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 sm…

> The S3 API is quite stable

With so many things offering S3 compatibility, I’d say it’s de-facto standardized.

Re: MinIO Is Dead, Long Live MinIO

#53

Post by bugufu8f83 »

Aurornis wrote: post #23
awesan wrote: 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…

>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.

I mean, I'm more worried about the AI writing itself than people calling it out.

The AI articles on HN are an absolute disease. Just write your own damn articles if you're asking the rest of us to read them.

Re: MinIO Is Dead, Long Live MinIO

#54

Post by jonathrg »

awesan wrote: 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 have no reason to trust that the fork itself is competently maintained when the author did not even bother to write the announcement.

Re: MinIO Is Dead, Long Live MinIO

#55

Post by mtndew4brkfst »

teeray wrote: post #52
chatmasta wrote: post #35

Earlier quoted context omitted.

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 sm…

> The S3 API is quite stable With so many things offering S3 compatibility, I’d say it’s de-facto standardized.

I can't see how Amazon is incentivized to avoid making any changes that break compatibility for their imitators, so long as their first party SDKs continue working. Standardized feels like it should be suffixed with "as long as Amazon doesn't ever feel like evolving the product further".

Re: MinIO Is Dead, Long Live MinIO

#56

Post by uroni »

mtndew4brkfst wrote: post #55
teeray wrote: post #52

Earlier quoted context omitted.

> The S3 API is quite stable With so many things offering S3 compatibility, I’d say it’s de-facto standardized.

I can't see how Amazon is incentivized to avoid making any changes that break compatibility for their imitators, so long as their first party SDKs continue working. Standardized feels like it should be suffixed with "as long as Amazon doesn't ever feel like evolving the product further".

There is a lot of software that directly implements the HTTP S3 API. That API is also documented by Amazon.

E.g. the last implementation I saw was by DuckDB https://github.com/duckdb/duckdb-httpfs/blob/main/src/s3fs.c...

Re: MinIO Is Dead, Long Live MinIO

#57

Post by Havoc »

I used S3 as a vibe code case study for whether I can just make my own. Learnings:

* Yes you can absolutely spin up a DIY S3 server

* When you run your server against a credible bench suite it throws a bunch of issues (ceph s3 - is disheartening 5 pass out of 800)

* Vibe coding can address the core issues & make significant progress on the 800 issues. Most of those 800 don't actually matter

* Low trust in resulting outcome, but I do plan on running some personal infra off DIY s3 - shopping list etc.

* Planning to roll some personal infra onto said S3, but with low confidence on

Re: MinIO Is Dead, Long Live MinIO

#58

Post by thenewwave »

uroni wrote: post #50
thenewwave wrote: post #38

AGPL is a plague. So many possible partners or future stewards won’t touch anything minIO with a ten foot pole unfortunately. And I say this because minIO started to actively engage on the ugly parts of the license

AGPL is "a plague" by design (viral). It has the explicit goal that any improvements flow back to the community project and the virality is a necessary building block for this. It is an elegant solution to a tragedy of the commons problem. Companies like MinIO extending the virality beyond the single software/work, even though not intended by license, gives it a bad reputation. They have fixed https://min.io/complian…

Intentions of the license aside, the abusive stance of how far the license extends is an unsettled matter in the US court system. And that means when a project wants to assert that any software which talks to a minIO instance over s3 is included in this license expectation, it’s on you to decide if you want to go the distance defending yourself. And even then, they can just drop the suit whenever in that long process and continue the status quo world of ambiguity.

Re: MinIO Is Dead, Long Live MinIO

#59

Post by Arcuru »

Macha wrote: post #28
patmorgan23 wrote: post #24

Earlier quoted context omitted.

Doesn't that depend on the CLA? Could you not have a CLA that only allows the project to use a specific license?

You could, but the reason that companies ask for CLAs is to free themselves by that restriction. If Minio just wanted to use the changes under AGPL, the contributor could just license them under AGPL, no CLA needed.

There are several companies I've seen that use a CLA primarily to sell AGPL exceptions so they can actually fund development, Element for example [1]. Some even word the CLA to require them to keep contributions available under an OSI-approved license.

I'm a fan of that model. IIt allows for a path to funding, a legal framework to keep contributed code open, and also allows them license agility to more permissive license ass needed. I've started using that for my own larger projects too.

https://element.io/blog/synapse-now-lives-at-github-com-elem...

Re: MinIO Is Dead, Long Live MinIO

#60

Post by cluckindan »

deeebug wrote: post #42
holysoles wrote: post #22

I'll plug that Chainguard has been maintaining a fork for awhile and seems to have a history with supporting forks like this: https://github.com/chainguard-forks/minio For a web GUI, I had been using this project: https://github.com/huncrys/minio-console I switched to rustfs this week though and am not looking back. I'd recommend it to others as well for small scale usage. Its maturing rapidly and seems promising.

Do note rustfs has had a...questionable...security posture. See https://github.com/rustfs/rustfs/security/advisories/GHSA-h9... as a good example (hardcoded static token).

If you run (vibe-coded?) alpha software in production, assume security is compromised.

In fact, if you run software in production, assume security is compromised.

Post reply on HN