[HN Gopher] MinIO is now in maintenance-mode
___________________________________________________________________
MinIO is now in maintenance-mode
Author : hajtom
Score : 371 points
Date : 2025-12-03 16:00 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| baq wrote:
| please copy and paste outrage from previous discussions to not
| waste more time
|
| https://news.ycombinator.com/item?id=45665452
| dardeaup wrote:
| Hopefully no one is shocked or surprised.
| giancarlostoro wrote:
| I'm both shocked and not surprised. Lots of questions: Are they
| doing that bad from the outcry? Or are they just keeping a
| private version and going completely commercial only? If so,
| how do they bypass the AGPL in doing so, I assume they had
| contributions under the AGPL.
| 0x073 wrote:
| "For enterprise support and actively maintained versions,
| please see MinIO AIStor."
|
| Commercial only, they will replace the agpl contributions
| from external people. (Or at least they will say that)
| Kerrick wrote:
| I don't understand. They've seen the contributions. How can
| they possibly do a clean-room implementation to avoid
| copyright infringement? (Let alone how tangled up in the
| history of the codebase they must be...)
| giancarlostoro wrote:
| I hope some contributors get together and sue. ;)
| tempest_ wrote:
| It doesnt matter unless someone takes them to court over
| it.
| ecshafer wrote:
| Is this just the open source portion? Minio is now a fully paid
| product then?
| 0x073 wrote:
| "For enterprise support and actively maintained versions,
| please see MinIO AIStor."
|
| Probably yes.
| margorczynski wrote:
| Basically officially killing off the open source version.
| johnmaguire wrote:
| Any good alternatives?
| pezgrande wrote:
| This one is usually the most recommended:
| https://garagehq.deuxfleurs.fr/
| mlnj wrote:
| Have heard good things about Garage
| (https://garagehq.deuxfleurs.fr/).
|
| Am forced to use MinIO for certain products now but will
| eventually move to better eventually. Garage is high on my list
| of alternatives.
| itodd wrote:
| seaweedfs
| xrd wrote:
| I saw this referenced a few days ago. Haven't investigated it
| at all.
|
| https://garagehq.deuxfleurs.fr/
|
| Edit: jeez, three of us all at once...
| ecshafer wrote:
| A lot of them actually. Ceph personally I've used. But there's
| a ton, some open source, some paid. Backblaze has a product
| Buckets or something. Dell powerscale. Cloudian has one.
| Nutanix has one.
| coredog64 wrote:
| I've been looking at microceph, but the requirement to run 3
| OSDs on loopback files plus this comment from the docs gives
| me pause:
|
| `Be wary that an OSD, whether based on a physical device or a
| file, is resource intensive.`
|
| Can anyone quantify "resource intensive" here? Is it "takes
| an entire Raspberry Pi to run the minimum set" or is it
| "takes 4 cores per OSD"?
|
| Edit: This is the specific doc page https://canonical-
| microceph.readthedocs-hosted.com/stable/ho...
| dardeaup wrote:
| Ceph has multiple daemons that would need to be running:
| monitor, manager, OSD (1 per storage device), and RADOS
| Gateway (RGW). If you only had a single storage device it
| would still be 4 daemons.
| dardeaup wrote:
| Ceph is awesome for software defined storage where you have
| multiple storage nodes and multiple storage devices on each.
| It's way too heavy and resource intensive for a single
| machine with loopback devices.
| dathinab wrote:
| ceph depends a lot on your use case
|
| minio was also suited for some smaller use cases (e.g.
| running a partial S3 compatible storage for integration
| tests). Ceph isn't really good for it.
|
| But if you ran large minio clusters in production ceph might
| be a very good alternative.
| import wrote:
| Seaweed and garage (tried both, still using seaweed)
| phpdave11 wrote:
| If you just need a simple local s3 server (e.g. for developing
| and testing), I recommend rclone.
|
| rclone serve s3 path/to/buckets --addr :9000 --auth-key <key-
| id>,<secret>
| SteveNuts wrote:
| RustFS is good, but still pretty immature IMO
| lousken wrote:
| wasn't there a fork with the UI?
| nullify88 wrote:
| https://www.versity.com/products/versitygw/
|
| I haven't tried it though. Seems simple enough to run.
| tiernano wrote:
| Is this not the best thing that could happen? Like now its in
| maintenance, it can be forked without any potential license
| change in the future, or any new features that are in that
| license change... This allows anyone to continue working on this,
| right? Or did i miss something?
| Weryj wrote:
| Pretty sure you can't retroactively apply a restrictive
| license, so that was never a concern.
| IgorPartola wrote:
| You can, sort of, sometimes. Copyleft is still based on
| copyright. So in theory you can do a new license as long as
| all the copyright holders agree to the change. Take open
| source/free/copyleft out of it:
|
| You create a proprietary piece of software. You license it to
| Google and negotiate terms. You then negotiate different
| terms with Microsoft. Nothing so far prevents you from doing
| this. You can't yank the license from Google unless your
| contract allows that, but maybe it does. You can in theory
| then go and release it under a different license to the
| public. If that license is perpetual and non-revokable then
| presumably I can use it after you decide to stop offering
| that license. But if the license is non-transferrable then I
| can't pass on your software to someone else either by giving
| them a flash drive with it, or by releasing it under a
| different license.
|
| Several open source projects have been re-licensed. The main
| thing that really is the obstacle is that in a popular open
| source or copyleft project you have many contributors each of
| which holds the copyright to their patches. So now you have a
| mess of trying to relicense only some parts of your codebase
| and replace others for the people resisting the change or
| those you can't reach. It's a messy process. For example,
| check out how the Open Street Maps data got relicensed and
| what that took.
| bilkow wrote:
| I think you are correct, but you probably misunderstood the
| parent.
|
| My understanding of what they meant by "retroactively apply
| a restrictive license" is to apply a restrictive license to
| previous commits that were already distributed using a FOSS
| license (the FOSS part being implied by the new license
| being "restrictive" and because these discussions are
| usually around license changes for previously FOSS projects
| such as Terraform).
|
| As allowing redistribution under at least the same license
| is usually a requirement for a license to be considered
| FOSS, you can't really change the license of an existing
| version as anyone who has acquired the version under the
| previous license can still redistribute it under the same
| terms.
|
| Edit: s/commit/version/, added "under the same terms" at
| the end, add that the new license being "restrictive"
| contributes to the implication that the previous license
| was FOSS
| IgorPartola wrote:
| Right but depending on the exact license, can the
| copyright holder revoke your right to redistribute?
| jagged-chisel wrote:
| > ... it can be forked without any potential license change in
| the future ...
|
| It is useful to remember that one may fork at the commit before
| a license change.
| phoronixrly wrote:
| It is also useful to remember that MinIO has historically
| held to an absurd interpretation of the AGPL -- that it
| spreads (again, according to them) to software that
| communicates with MinIO via the REST API/CLI.
|
| I assume forks, and software that uses them will be held to
| the same requirements.
| ahepp wrote:
| As long as I'm not the one who gets sued over this, I think
| it would be wonderful to have some case law on what
| constitutes an AGPL derivative work. It could be a great
| thing for free software, since people seem to be too scared
| to touch the AGPL at all right now.
| Havoc wrote:
| I thought they were pivoting towards close it and trying to
| monetize this?
|
| That got backlash so now it's just getting dropped entirely?
|
| People get to do whatever they want but bit jarring to go from
| this is worth something people will pay for to maintenance mode
| in quick succession
| ocdtrekkie wrote:
| They cite a proprietary alternative they offer for enterprises.
| So yes they pivoted to a monetized offering and are just
| dropping the open source one.
| itopaloglu83 wrote:
| So they're pulling an OpenAI.
|
| Start open source to use free advertising and community
| programmer, and then dumps it all for commercial licensing.
|
| I think n8n is next because they finished the release
| candidate for version 2.0, but there are no changelogs.
| embedding-shape wrote:
| > I thought they were pivoting towards close it and trying to
| monetize this?
|
| That's literally what the commit shows that they're doing?
|
| > *This project is currently under maintenance and is not
| accepting new changes.*
|
| > For enterprise support and actively maintained versions,
| please see MinIO SloppyAISlop (not actual name)
| this_user wrote:
| Their marketing had shifting to trying to push an AI angle for
| some time now. For an established project or company, that's
| usually a sign that things aren't going well.
| theideaofcoffee wrote:
| Oh, no! Anyway... Maybe it's for the best seeing as it's AGPL. I
| won't go within 39.5 feet of infected software like that, so no
| loss for me.
| nkmnz wrote:
| Downvoted because nobody knows how far a distance 39.5 feet is.
| stronglikedan wrote:
| they do if they know the shoe size of the person who measured
| it
| deathanatos wrote:
| It's a reference to a fairly widely known, and presently
| topical, song: Your brain is full of
| spiders You've got garlic in your soul, Mr. Grinch
| I wouldn't touch you with a 39 and a half foot pole!
| bananapub wrote:
| for those looking for a simple and reliable self hosted S3 thing,
| check out Garage . it's much simpler - no web ui, no fancy RS
| coding, no VC-backed AI company, just some french nerds making a
| very solid tool.
|
| fwiw while they do produce Docker containers for it, it's also
| extremely simple to run without that - it's a single binary and
| running it with systemd is unsurprisingly simple[1].
|
| 0: https://garagehq.deuxfleurs.fr/
|
| 1:
| https://garagehq.deuxfleurs.fr/documentation/cookbook/system...
| colesantiago wrote:
| How do you sustain yourselves while developing this project?
|
| What if the sponsorships run out?
| prmoustache wrote:
| What if a company change license, drop the project or goes
| bankrupt?
|
| You shouldn't expect guarantee of any kind.
| snickell wrote:
| Any efforts to consolidate around a community fork yet?
| Dachande663 wrote:
| Does anyone have any recommendations for a simple S3-wrapper to a
| standard dir? I've got a few apps/services that can send data to
| S3 (or S3 compatible services) that I want to point to a local
| server I have, but they don't support SFTP or any of the more
| "primitive" solutions. I did use a python local-s3 thing, but it
| was... not good.
| mr-karan wrote:
| You could perhaps checkout https://garagehq.deuxfleurs.fr/
| dardeaup wrote:
| I've done some preliminary testing with garage and I was
| pleasantly surprised. It worked as expected and didn't run
| into any gotchas.
| digikata wrote:
| Garage is really good for core S3, the only thing I ran
| into was it didn't support object tagging. It could be
| considered maybe a more esoteric corner of the S3 api, but
| minio does support it. Especially if you're just mapping
| for a test api, object tagging is most likely an unneeded
| feature anyway.
|
| It's a "Misc" endpoint in the Garage docs here:
| https://garagehq.deuxfleurs.fr/documentation/reference-
| manua...
| topspin wrote:
| "didn't support object tagging"
|
| Thanks for pointing that out.
| import wrote:
| rclone serve s3, could be.
| spicypixel wrote:
| This is the winner
| frellus wrote:
| Check out from nvidia, aistore:
| https://github.com/NVIDIA/aistore
|
| It's not a fully featured s3 compatible service, like MinIO,
| but we used it to great success as a local on-prem s3
| read/write cache with AWS as the backing S3 store. This avoided
| expensive network egress charges as we wanted to process data
| in both AWS as well as in a non-AWS GPU cluster (i.e. a
| neocloud)
| mcpherrinm wrote:
| Versity Gateway looks like a reasonable option here. I haven't
| personally used it, but I know some folks who say it performs
| pretty great as a "ZFS-backed S3" alternative.
|
| https://github.com/versity/versitygw
|
| Unlike other options like Garage or Minio, it doesn't have any
| clustering, replication, erasure coding, ...
|
| Your S3 objects are just files on disk, and Versity exposes it.
| I gather it exists to provide an S3 interface on top of their
| other project (ScoutFS), but it seems like it should work on
| any old filesystem.
| pkoiralap wrote:
| Versity is really promising. I got a chance to meet with Ben
| recently at the Super Computing conference in St. Louis and
| he was super chill about stuff. Big shout out to him.
|
| He also mentioned that the minio-to-versity migration is a
| straight forward process. Apparently, you just read the data
| from mino's shadow filesystem and set it as an extended
| attribute in your file.
| mbreese wrote:
| I really like what I've (just now) read about Versity. I like
| that they are thinking about large scale deployments with
| tape as the explicit cold-storage option. It really makes
| sense to me coming from an HPC background.
|
| Thanks for posting this, as it's the first I've come across
| their work.
| zzyzxd wrote:
| Garage also decide to not implement erasure coding.
| trufas wrote:
| s3proxy has a filesystem backend [0].
|
| Possibly of interest: s3gw[1] is a modified version of ceph's
| radosgw that allows it to run standalone. It's geared towards
| kubernetes (notably part of Rancher's storage solution), but
| should work as a standalone container.
|
| [0] https://github.com/gaul/s3proxy [1]
| https://github.com/s3gw-tech/s3gw
| ralgozino wrote:
| Do you want to serve already existing files from a directory or
| just that the backend is a directory on your server?
|
| If the answer is the latter, seaweedfs is an option:
|
| https://github.com/seaweedfs/seaweedfs?tab=readme-ov-file#qu...
| aranw wrote:
| I've been using the minio-go client for S3-compatible storage
| abstraction in a project I'm working on. This new change putting
| the minio project into maintenance mode means no new features or
| bug fixes, which is concerning for something meant to be a stable
| abstraction layer
|
| Need to start reconsidering the approach now and looking for
| alternatives
| frellus wrote:
| https://aistore.nvidia.com
| positisop wrote:
| github.com/NVIDIA/aistore
|
| At the 1 billion valuation from the previous round, achieving a
| successful exit requires a company with deep pockets. Right
| now, Nvidia is probably a suitable buyer for MinIO, which might
| explain all the recent movements from them. Dell, Broadcom,
| NetApp, etc, are not going to buy them.
| cantagi wrote:
| They have been removing features from the open source version for
| a while.
|
| The closest alternative seems to be RustFS. Has anyone tried it?
| I was waiting until they support site replication before
| switching.
| positisop wrote:
| If it is not an Apache/CNCF/LinuxFoundation project, it can be
| a rug pull aimed at using open source for getting people in the
| door only. They were never open for commits, and now they have
| abandoned open source altogether.
| rbartelme wrote:
| Might be coming soon based on this:
| https://docs.rustfs.com/features/replication/
| pankajdoharey wrote:
| Sad to see these same people were behind GlusterFS.
| mbreese wrote:
| Well, maybe they are using that experience to build something
| better this time around? One can hope...
| bityard wrote:
| Garage is a popular alternative to Minio.
| https://garagehq.deuxfleurs.fr
|
| I hadn't heard of RustFS and it looks interesting, although I
| nearly clicked away based on the sheer volume of marketing wank
| on their main page. The GitHub repo is here:
| https://github.com/rustfs/rustfs
| dalenw wrote:
| I use garage at home, single node setup. It's very easy and
| fast, I'm happy with it. You're missing out on a UI for it,
| but MountainDuck / CyberDuck solves that problem for me.
| redrove wrote:
| I've been using this https://github.com/khairul169/garage-
| webui as a UI for Garage. It's been solid.
|
| After years of using Garage for S3 for the homelab I'd
| never pick anything else. Absolutely rock solid, no problem
| whatsoever. There isn't ONE other piece of software I can
| say that about, not ONE.
|
| Major kudos to the guys at deuxfleurs. Merci beaucoup!
| eproxus wrote:
| Yeah, that page is horrendous and looks super sketchy. It
| looks like a very professional fishing attempt to get
| unsuspecting developers to download malware.
|
| They have a lot of obviously fake quotes from non-existent
| people at positions that don't even mention what company it
| is. The pictures are misgendered and even contain pictures of
| kids.
|
| Feels like the whole page is AI generated.
| runiq wrote:
| They have a CLA that assigns copyright to them: https://git
| hub.com/rustfs/rustfs/blob/5b0a3a07645364d998e3f5...
|
| So, arguably worse than MinIO.
| stormking wrote:
| How would you run a project like this? People come and
| go. People do a one-time contribution and then you never
| hear from them again. People work on a project for years
| and then just go silent. Honestly, credit where credit is
| due, but how is a project like this supposed to manage
| this?
| speedgoose wrote:
| You could pick a license and not plan to relicense later.
| Like Linux.
| PunchyHamster wrote:
| You can have CLA without assigning copyright to the
| project.
|
| You don't need assignment to the project if you are not
| planning to change project's license.
|
| You do need assignment to the project if you need to ever
| rugpull the community and close the code
| everfrustrated wrote:
| The _only_ reason to require a CLA is because you expect
| to change the license in the future. RustFS has rug-pull
| written all over it.
| regularfry wrote:
| Or to offer it under a commercial licence in parallel.
| cromka wrote:
| I saw an article here not long about where someone explained
| they were hosting their Kopia or Nextcloud aver Garage, but I
| can't find it anymore.
|
| This was going to be my next project, as I am currently
| storing my Kopia/Ente on MinIO in a non-distributed way.
| MinIO project going to shi*s is a good reason to take on this
| project faster than later.
| adamcharnock wrote:
| We've done some fairly extensive testing internally recently
| and found that Garage is somewhat easier to deploy, but is
| not as performant at high speeds. IIRC we could push about 5
| gigabits of (not small) GET requests out of it, but something
| blocked it from reaching the 20-25 gigabits (on a 25g NIC)
| that MinIO could reach (also 50k STAT requests/s)
|
| I don't begrudge it that. I get the impression that Garage
| isn't necessarily focussed on this kind of use case.
| PunchyHamster wrote:
| From what I looked still very fresh project, to the point
| running out of date minio version will most likely be less
| problematic than latest rustfs
| nikeee wrote:
| I maintain an S3 client that has a test matrix for the commonly
| used S3 implementations. RustFS regularly breaks it. Last time
| it did I removed it from the matrix because deleteObject
| suddenly didn't delete the object any more. It is extremely
| unstable in its current form. The website states that it is not
| in a production-ready state, which I can confirm.
|
| I'd take a look at garage (didn't try seaweed yet).
| maxloh wrote:
| Although promising, RustFS is a Chinese product. This would be
| a non-starter for many.
| jasonvorhe wrote:
| Because they aren't thinking about all the chinese wetware
| they'd be writing down that decision with.
| js4ever wrote:
| I made recently an open source alternative to minio Server &
| minio UI also in Rust:
|
| https://github.com/vibecoder-host/ironbucket/
|
| https://github.com/vibecoder-host/ironbucket-ui
| candiddevmike wrote:
| It sucks that S3 somehow became the defacto object storage
| interface, the API is terrible IMO. Too many headers, too many
| unknowns with support. WebDAV isn't any better, but I feel like
| we missed an opportunity here for a standardized interface.
| tlarkworthy wrote:
| ?
|
| Its like GET <namespace>/object, PUT <namespace>/object. To me
| its the most obvious mapping of HTTP to immutable object key
| value storage you could imagine.
|
| It is bad that the control plane responses can be malformed XML
| (e.g keys are not escaped right if you put XML control
| characters in object paths) but that can be forgiven as an
| oversight.
|
| Its not perfect but I don't think its a strange API at all.
| candiddevmike wrote:
| Everything uses poorly documented, sometimes inconsistent
| HTTP headers that read like afterthoughts/tech debt. An S3
| standard implementation has to have amazon branding all over
| it (x-amz) which is gross.
| christina97 wrote:
| I mean... it's straight up an Amazon product, not like it's
| an IETF standard or something.
| drob518 wrote:
| I suspect they learned a lot over the years and the API
| shows the scars. In their defense, they did go first.
| perbu wrote:
| Last I checked the user guide to the API was 3500 pages.
|
| 3500 pages to describe upload and download, basically. That
| is pretty strange in my book.
| nine_k wrote:
| Even download and upload get tricky if you consider stuff
| like serving buckets like static sites, or stuff like siged
| upload URLs.
|
| Now with the trivial part off the table, let's consder
| storage classes, security and ACLs, lifecycle management,
| events, etc.
| PunchyHamster wrote:
| It gets complex with ACLs for permissions, lifecycle
| controls, header controls and a bunch of other features that
| are needed on S3 scale but not at smaller provider scale.
|
| And many S3-compatible alternatives (probably most but the
| big ones like Ceph) don't implement all of the features.
|
| For example for lifecycles backblaze have completely
| different JSON syntax
| jerf wrote:
| That may be what S3 is _like_ , but what the S3 API _is_ is
| this: https://pkg.go.dev/github.com/aws/aws-sdk-
| go-v2/service/s3
|
| My browser prints that out to 413 pages with a naive print
| preview. You can squeeze it to 350 pretty reasonably with a
| bit of scaling before it starts getting to awfully small type
| on the page.
|
| Yes, there's a simple API with simple capabilities struggling
| to get out there, but pointing that out is merely the first
| step on the thousand-mile journey of determining what,
| _exactly_ , that is. "Everybody uses 10% of Microsoft Word,
| the problem is, they all use a different 10%", basically. If
| you sat down with even 5 relevant stakeholders and tried to
| define that "simple API" you'd be shocked what you discover
| and how badly Hyrum's Law will bite you even at that scale.
| eproxus wrote:
| That page crashes Safari for me on iOS.
| zokier wrote:
| > That may be what S3 is like, but what the S3 API is is
| this: https://pkg.go.dev/github.com/aws/aws-sdk-
| go-v2/service/s3
|
| > My browser prints that out to 413 pages with a naive
| print preview. You can squeeze it to 350 pretty reasonably
| with a bit of scaling before it starts getting to awfully
| small type on the page.
|
| idk why you link to Go SDK docs when you can link to the
| actual API reference documentation: https://docs.aws.amazon
| .com/AmazonS3/latest/API/API_Operatio... and its PDF
| version: https://docs.aws.amazon.com/pdfs/AmazonS3/latest/A
| PI/s3-api.... (just 3874 pages)
| paulddraper wrote:
| !!!
|
| I've seen a lot of bad takes and this is one of them.
|
| Listing keys is weird (is it V1 or V2)?
|
| The authentication relies on an obtuse and idiosyncratic
| signature algorithm.
|
| And S3 in practice responds with malformed XML, as you point
| out.
|
| Protocol-wise, I have trouble liking it over WebDAV. And
| that's depressing.
| KaiserPro wrote:
| HTTP isn't really a great back plane for object storage.
| mbreese wrote:
| It was better. When it first came out, it was a pretty simple
| API, at least simpler than alternatives (IIRC, I could just be
| thinking with nostalgia).
|
| I think it's only gotten as complicated as it has as new
| features have been organically added. I'm sure there are good
| use cases for everything, but it does beg the question -- is a
| better API possible for object storage? What's the minimal API
| required? GET/POST/DELETE?
| everfrustrated wrote:
| Like everything it starts off simple but slowly with every
| feature added over 19 years Simple Storage is it not.
|
| S3 has 3 independent permissions mechanisms.
| bostik wrote:
| I suspect there is no decent "minimal" API. Once you get to
| tens of millions of objects _in a given prefix_ , you need
| server side filtering logic. And to make it worse, you need
| multiple ways to do that.
|
| For example, did you know that date filtering in S3 is based
| on string prefix matching against an ISO8601/RFC3339 style
| string representation? Want all objects created between
| 2024-01-01 and 2024-06-30? You'll need to construct six YYYY-
| MM prefixes (one per month) for datetime and add them as
| filter array elements.
|
| As a result the service abbreviation is also incorrect these
| days. Originally the first S stood for "Simple". With all the
| additions they've had to bolt on, S2 would be far more
| appropriate a name.
| ssimpson wrote:
| I thought the openstack swift API was pretty clean, but i'm
| biased.
| dathinab wrote:
| S3 isn't JSON
|
| it's storing a [utf8-string => bytes] mapping with some very
| minimal metadata. But that can be whatever you want. JSON,
| CBOR, XML, actual document formats etc.
|
| And it's default encoding for listing, management operations
| and similar is XML....
|
| > but I feel like we missed an opportunity here for a
| standardized interface.
|
| except S3 _is_ the de-facto standard interface which most
| object storage system speaks
|
| but I agree it's kinda a pain
|
| and commonly done partial (both feature wise and partial
| wrong). E.g. S3 store utf8 strings, not utf8 file paths (like
| e.g. minio does), that being wrong seems fine but can lead to a
| lot of problems (not just being incompatible for some
| applications but also having unexpected perf. characteristics
| for others) making it only partial S3 compatible. Similar some
| implementations random features like bulk delete or support
| `If-Match`/`If-Non-Match` headers can also make them S3
| incompatible for some use cases.
|
| So yeah, a new external standard which makes it clear what you
| should expect to be supported to be standard compatible would
| be nice.
| giancarlostoro wrote:
| To be fair. We still have an opportunity to create a
| standardized interface for object storage. Funnily enough when
| Microsoft made their own they did not go for S3 compatible
| APIs, but Microsoft usually builds APIs their customers can
| use.
| dbacar wrote:
| Disgusting. Build a product, make it open-source to gain
| traction, and when you are done completely abandon it. Shame on
| me that I have put this ^%^$hit on a project and advocated it.
| stronglikedan wrote:
| That can happen to any project, hence why Plan B should be
| implemented right alongside Plan A whenever humanly possible.
| uroni wrote:
| I've been working on https://github.com/uroni/hs5 as a
| replacement with similar goals to early minio.
|
| The core is stable at this point, but the user/policy management
| and the web interface is still in the works.
| sph wrote:
| Good time to post a Show HN for your project then
| giancarlostoro wrote:
| Looks like you cleanly point out their violation of the AGPL. I
| wish I were a lawyer with nothing better to do, I'd definitely
| be suing the MinIO group, there's no way they can cleanly
| remove the AGPL code outsiders contributed.
| bityard wrote:
| I don't see a contributor licensing agreement (CLA), so you
| may be right.
|
| (I personally choose not to contribute to projects with CLAs,
| I don't want my contributions to become closed-source in the
| future.)
| giancarlostoro wrote:
| Its worse than I thought:
|
| https://blog.min.io/weka-violates-minios-open-source-
| license...
|
| They think they can revoke someone's AGPL license. That's
| not at all how that license works!
| kstrauser wrote:
| I think that's exactly how that license works. Basically,
| the license is the _only_ thing that grants you rights to
| redistribute the licensed work. Copyright law otherwise
| forbids it. And the license itself only grants you the
| right to redistribute the work as long as you comply with
| its terms. If you violate them, the license no longer
| applies, and you no longer have any legal right to
| distribute the work or any derived works.
|
| I have zero knowledge about the squabble between MinIO
| and Weka. I don't know, and don't care, if either of them
| is in the right. But _if_ Weka isn 't complying with the
| terms of the AGPL, then MinIO has the legal right to tell
| them they can no longer distribute MinIO's licensed work
| at all, because nothing else grants them that privilege.
|
| If that weren't true, there'd be no teeth to the A?GPL
| whatsoever.
| kragen wrote:
| Yes, it is. Although
| https://www.gnu.org/licenses/agpl-3.0.html says
|
| > _All rights granted under this License are granted for
| the term of copyright on the Program, and are irrevocable
| provided the stated conditions are met._
|
| it also says
|
| > _You may not propagate or modify a covered work except
| as expressly provided under this License. Any attempt
| otherwise to propagate or modify it is void, and will
| automatically terminate your rights under this License
| (including any patent licenses granted under the third
| paragraph of section 11)._
|
| > _However, if you cease all violation of this License,
| then your license from a particular copyright holder is
| reinstated (a) provisionally, unless and until the
| copyright holder explicitly and finally terminates your
| license, and (b) permanently, if the copyright holder
| fails to notify you of the violation by some reasonable
| means prior to 60 days after the cessation._
|
| > _Moreover, your license from a particular copyright
| holder is reinstated permanently if the copyright holder
| notifies you of the violation by some reasonable means,
| this is the first time you have received notice of
| violation of this License (for any work) from that
| copyright holder, and you cure the violation prior to 30
| days after your receipt of the notice._
|
| This is in common with the GPLv3. It is much longer than
| the corresponding terms of the GPLv2 to remedy a sort of
| fragility in the GPLv2 which says your license terminates
| permanently if you ever violate the GPL, even temporarily
| and by accident.
|
| I have no knowledge of whether Weka did or didn't violate
| the license, but if they did violate it and refused to
| fix it, MinIO's revocation of their license is completely
| in accordance with the terms of the license as written. I
| don't think a GPL termination case has yet been
| litigated.
| roblabla wrote:
| > I don't think a GPL violation case has yet been
| litigated.
|
| It has, though it has mainly been under the "breach of
| contract" approach and not under "copyright infringement"
| approach. See https://en.wikipedia.org/wiki/Open_source_l
| icense_litigation
| kragen wrote:
| Of course you're correct. I meant to say no GPL
| _termination_ case, and I 've corrected my comment to say
| that. By that I mean cases where the defendant had cured
| their breach of the GPL but continued exercising the
| rights the GPL would have given them but for the
| termination clause.
| mbreese wrote:
| I don't think there would be an issue with removing AGPL
| contributed code. You can't force someone to distribute
| something they don't want to. IANAL, but I believe that what
| (all?) copyright in software is most concerned with is the
| active distribution of code -- not the removal of code.
|
| That said, if there was contributed AGPL code, they couldn't
| change the license on that part of the code w/o a CLA. AGPL
| also doesn't necessarily mean you have to make the code
| publicly available, just available to those that you give the
| program to (I'm assuming AGPL is like the GPL in this
| regard).
|
| So, that I'd be curious about it is -- (1) is there any
| contributed AGPL code in the current version? (2) what
| license is granted to customers of the enterprise version?
|
| Minio can completely use whatever license they want for their
| code. But, if there was contributed code w/o a CLA, then I'm
| not sure how a commercial/enterprise license would play with
| contriubuted AGPL code. It would be an interesting question
| to find out.
| giancarlostoro wrote:
| That's definitely not how its written or interpreted.
| Microsoft had to release code because they touched GPL code
| some years back I think it was for HyperV? We're talking
| about a company with many lawyers at the ready not being
| able to skirt the GPL in any way, like undoing the code.
|
| Additionally, in order to CHANGE the license, if others
| contributed code under that license, you would need their
| permission, on top of the fact, you cannot retroactively
| revoke the license for previous versions.
| mbreese wrote:
| What I'm _really_ curious about is if their most recent
| enterprise versions /code must be released under AGPL.
| And if so, can they restrict customers from distributing
| AGPL'd code through an enterprise contract?
|
| I can't see how this is a defensible position for Minio,
| but I'm not sure they really care that much at this
| point.
| kragen wrote:
| > _AGPL also doesn 't necessarily mean you have to make the
| code publicly available, just available to those that you
| give the program to (I'm assuming AGPL is like the GPL in
| this regard)._
|
| This is the crucial difference between the AGPL and the
| GPL: the AGPL requires you to make the code available to
| users for whom you run the code, as well as users you give
| the program to.
| mbreese wrote:
| But, for minio, the users aren't the public... the users
| are their enterprise customers (now). So, to fulfill the
| AGPL, they'd have to give the code to their users, but
| that doesn't necessarily mean to the public at large (via
| GitHub).
|
| But, what I don't know is -- is there any other AGPL code
| that minio doesn't own, but that was otherwise
| contributed to minio? Because, presumably, they aren't
| actually giving their customers the minio program with an
| AGPL license, rather they have whatever their enterprise
| license agreement is. If this is the case, and there is
| AGPL code that's not owned by Minio, I can foresee
| problems in the future.
| kragen wrote:
| I agree with all of that.
| uroni wrote:
| I'm not a contributor to Minio. This is its own separate
| thing.
|
| I do have a separate AGPL project (see github) where I have
| nearly all of the copyright and have looked into how one
| would be able to enforce this in the US at some point and it
| did look pretty bleak -- it is a civil suit where you have to
| show damages etc. but IANAL.
|
| I did not like the FUD they were spreading about AGPL at the
| time since it is a good license for end-user applications.
| giancarlostoro wrote:
| Oh I didn't mean to imply yours was, yours is C++ theirs is
| Go. The AGPL is fine, not a license for me, but its fine.
| I'm more of an MIT license kind of guy. If you're going to
| do the AGPL thing and then try to secure funding, make sure
| you own the whole thing first.
| bityard wrote:
| Interesting! I like the relative simplicity and durability
| guarantees. I can see using this for dev and proof of concept.
| Or in situations where HA/RAID are handled lower in the stack.
|
| What is the performance like for reads, writes, and deletes?
|
| And just to play devil's advocate: What would you say to
| someone who argues that you've essentially reimplemented a
| filesystem?
| uroni wrote:
| It uses LMDB, so if the object mapping fits in memory that
| should be pretty optimal for reading, while using the build-
| in Linux page cache and not a separate one (important for
| testing use cases). For write/deletes it has a bit of write-
| amplification due to the copy-on-write btree. I've
| implemented a separate, optional WAL for this and also a mode
| where writes/delete can be bundeled in a transaction, but in
| practice I think the performance difference should not
| matter.
|
| W.r.t. filesystem: Yes, aware of this. Initially used minio
| and also implemented the use case directly on XFS as well and
| only had problems at larger scales (that still fit on a
| machine) with it. Ceph went into a similar direction with
| BlueStore (reimplementing the filesystem, but with RocksDB).
| MrZander wrote:
| I wish I knew about this last week. I spent way too long trying
| out MinIO alternatives before getting SeaweedFS to work, but it
| is overkill for my purposes.
|
| Looks like a great alternative.
| rowanseymour wrote:
| What's the simplest replacement for mocking S3 in CI? We don't
| about performance or reliability.. it's just gotta act like S3.
| rodwyersoftware wrote:
| localstack, 100%
| onei wrote:
| I've used localstack in the past which worked pretty well.
|
| https://github.com/localstack/localstack
| atemerev wrote:
| How it makes sense? If they are no longer open-source S3 and
| cloud only, I'll just use S3.
| zerofor_conduct wrote:
| "The real hell of life is everyone has his reasons." -- Jean
| Renoir
| Aurornis wrote:
| > For enterprise support and actively maintained versions, please
| see [MinIO AIStor]
|
| Naming the product "AIStor" is one of the most blatant forced AI
| branding pivots I've seen.
| positisop wrote:
| Raising 100 mil at 1 B valuation and then trying for an exit is
| a bitch!
| evil-olive wrote:
| for maximum performance with MinIO AIStor, make sure to use one
| of Seagate's "AI hard drives":
|
| https://www.seagate.com/products/video-analytics/skyhawk-ai-...
| bityard wrote:
| And the naming conflicts with NVidia's AIStore
| (https://github.com/NVIDIA/aistore). The two products are
| extremely similar. I don't know which came first, but Minio is
| going to want to do another pivot very soon if they want to
| survive. I doubt they have the resources to stand up to
| NVidia's army of extremely well-paid IP lawyers.
| Natfan wrote:
| this is no different than grok vs groq imo. aistor and
| aistore are different names, even if they're pronounced
| similarly.
| st3fan wrote:
| What a story. EOL the open source foundation of your commercial
| product, to which many people contributed, to turn it into a
| closed source "A-Ff*ing-I Store" .. seriously what the ...
| binsquare wrote:
| I still don't understand what the difference is.
|
| What is an AI Stor (e missing on purpose because that is how it
| is branded: https://www.min.io/product/aistor)
| everfrustrated wrote:
| Might be because of this other storage product named that
| https://github.com/NVIDIA/aistore
| singhrac wrote:
| Does anyone use this? I was setting it up a few months ago
| but it felt very complicated compared to MinIO (or
| alternatives). Is there a sort of minikube-like tool I
| could use here?
| paulddraper wrote:
| It can store things for AI workloads (and non-AI workloads,
| but who's counting...)
| ljm wrote:
| Looks like AI slop Replication
| A trusted identity provider is a key component to
| single sign on.
|
| Uh, what?
|
| It's probably just Minio but it costs more money.
| bigbuppo wrote:
| About a billion dollars difference in valuation up until the
| bubble pops.
| smsm42 wrote:
| Well, you can not have a product without having "AI" somewhere
| in the name anymore. It's the law.
| orphea wrote:
| https://youtu.be/-qbylbEek-M?t=33
| btian wrote:
| What's the problem? Surely people will fork it
| nikeee wrote:
| Didn't contribute to MinIO, but if they accepted external
| contributions without making them sign a CLA, they cannot
| change the license without asking every external contributor
| for consent to the license change. As it is AGPL, they still
| have to provide the source code somewhere.
|
| IANAL, of course
| lima wrote:
| They required a "Community Contribution License" in each PR
| description, which licensed each contribution under Apache 2
| as an _inbound_ license.
|
| Meanwhile, MinIO's own contributions and the distribution
| itself (outbound license) were AGPL licensed.
|
| It's effectively a CLA, just a bit weaker, since they're
| still bound by the terms of Apache 2 vs. a full license
| assignment like most CLAs.
| NewsaHackO wrote:
| People underestimate the amount of fakeness a lot of these
| "open-core/source" orgs have. I guarantee from day one of
| starting the MinIO project, they had eyes on future
| commercialization, and of course made contributors sign
| away their rights knowing full well they are going to go
| closed source.
| daveguy wrote:
| This is why I don't bother with AGPL released by a company (use
| or contribute).
|
| Choosing AGPL with contributors giving up rights is a huge red
| flag for "hey, we are going to rug pull".
|
| Just AGPL by companies without even allowing contributor rights
| is saying, "hey, we are going to attempt to squeeze profit out
| and don't want competition on our SaaS offering."
|
| I wish companies would stop trying to get free code out of the
| open source community. There have been so many rug pulls it
| should be expected now.
| Joel_Mckay wrote:
| Like many smart people they focused on telling people the "how",
| and assume visitors to their wall of "AI"/hype text already
| understand the use-case "why".
|
| 1. I like that it is written in Go
|
| 2. I saw nothing above what Apache Spark+Hadoop with _consistent_
| object stores already offers on Amazon (S3), Google Cloud (GCS),
| and or Microsoft (Azure Storage, ADLS Gen2)
|
| Best of luck, maybe folks should look around for that
| https://donate.apache.org/ button before the tax year concludes
| =3
| PunchyHamster wrote:
| > I saw nothing above what Apache Spark+Hadoop with
| _consistent_ object stores already offers on Amazon (S3),
| Google Cloud (GCS), and or Microsoft (Azure Storage, ADLS Gen2)
|
| it was very simple to setup, and even if you just leased a
| bunch of servers off say OVH, far FAR cheaper to run your own
| than paying any of the big cloud providers.
|
| It also had pretty low requirements, ceph can do all that but
| setup is more complex and RAM requirements far, far higher
| Joel_Mckay wrote:
| MinIO still makes no sense, as Ceph is fundamentally already
| RADOS at its core (fully compatible with S3 API.)
|
| For a proper Ceph setup, even the 45drives budget
| configuration is still not "hobby" grade.
|
| I will have to dive into the MinIO manual at some point, as
| the value proposition still seems like a mystery. Cheers =3
| dardeaup wrote:
| "Ceph is fundamentally already RADOS at its core (fully
| compatible with S3 API.)"
|
| Yes, Ceph is RADOS at its core. However, RADOS != S3. Ceph
| provides an S3 compatible backend with the RADOS Gateway
| (RGW).
| Joel_Mckay wrote:
| My point was even 45drives virtualization of Ceph host
| roles to squeeze the entire setup into a single box was
| not a "hobby" grade project.
|
| I don't understand yet exactly what MinIO would add on
| top of that to make it relevant at any scale. I'll peruse
| the manual on the weekend, because their main site was
| not helpful. Thanks for trying though -\\_(tsu)_/-
| dardeaup wrote:
| What I tried to say (perhaps not successfully) was that
| core Ceph knows nothing about S3. One gets S3 endpoint
| capability from the radosgw which is not a required
| component in a ceph cluster.
| Joel_Mckay wrote:
| The risk with mixing different subjects per thread.
| Cheers =3
|
| https://docs.ceph.com/en/latest/radosgw/s3/
| PunchyHamster wrote:
| MinIO is far less complex than getting same functionality
| on Ceph stack.
|
| But that's kind of advantage only on the small companies
| and hobbyist market, big company either have enough needs
| to run big ceph cluster, or to buy it as a service.
|
| Minio is literally "point it at storage(s), done". And at
| far smaller RAM usage.
|
| Ceph is mon servers, osd servers, then rados gatway server
| on top of that.
| Joel_Mckay wrote:
| It sounds a lot like SwiftOnFile with GlusterFS, but I
| would need to look at it more closely on personal time.
| =3
| jdoe1337halo wrote:
| I use this image on my VPS, it was the last update before they
| neutered the community version
|
| quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z
| NietTim wrote:
| Same here, since I'm the only one using my instance. But, you
| should be aware that there is an CVE in that version that
| allows any account level to increase their own permissions to
| admin level, so it's inherently unsafe
| spapas82 wrote:
| This is a way too old version. You should use a newer one
| instead by downloading the source and built the binaries
| yourself.
|
| Here's a simple script that does it automagically (you'll need
| golang installed):
|
| > build-minio-ver.sh #!/bin/bash set -e
| VERSION=$(git ls-remote --tags
| https://github.com/minio/minio.git | \ grep -Eo
| 'RELEASE\.[0-9T-]+Z' | sort | tail -n1) echo
| "Building MinIO $VERSION ..." rm -rf /tmp/minio-
| build git clone --depth 1
| https://github.com/minio/minio.git /tmp/minio-build
| cd /tmp/minio-build git fetch --tags git checkout
| "$VERSION" echo "Building minio..."
| CGO_ENABLED=0 go build -trimpath \ -ldflags "-s -w \
| -X github.com/minio/minio/cmd.Version=$VERSION \ -X
| github.com/minio/minio/cmd.ReleaseTag=$VERSION \ -X
| github.com/minio/minio/cmd.CommitID=$(git rev-parse HEAD)" \
| -o "$OLDPWD/minio" echo " Binary created at:
| $(realpath "$OLDPWD/minio")" "$OLDPWD/minio"
| --version
| positisop wrote:
| Raising 100 mil at 1 B valuation and then trying for an exit is a
| bitch!
| aftbit wrote:
| Shocker... they abandoned POSIX compatibility, built a massively
| over-complicated product, then failed to compete with things like
| Ceph on the metal side or ubiquitous S3/R2/B2 on the cloud side.
| throwaway894345 wrote:
| > they abandoned POSIX compatibility, built a massively over-
| complicated product
|
| This is a wild sentence--how can you criticize them for
| abandoning POSIX support __and__ building a massively over-
| complicated product? Making a reliable POSIX system is
| inherently very complex.
| bee_rider wrote:
| I think the criticism (just interpreting the post, don't know
| anything about the technical situation) is that the
| complication is not necessary/worthwhile.
|
| POSIX can be complicated, but it puts you in a nice
| ecosystem, so for some use-cases complex POSIX support is not
| _over_ complicated. It is just... appropriately complicated.
| throwaway894345 wrote:
| Sure, but then you can make that argument about any of the
| features in Minio, in which case the parent's argument
| about Minio _as a whole_ being overcomplicated is
| invalidated. Probably the more sensible way to look at
| things is "value / complexity" or "bang for buck", but
| even there I think POSIX loses since it's relatively little
| value for a relatively large amount of complexity.
| bee_rider wrote:
| Yeah. I don't actually know if they are right or wrong,
| it depends on the ecosystem the project wants to hook in
| to, right? I just want to reduce it from "wild" to
| "debatable," haha.
| ahepp wrote:
| What would go in to POSIX compatibility for a product like
| this which would make it complicated? Because the kind of
| stuff that stands out to me is the use of Linux specific
| syscalls like epoll/io_uring vs trad POSIX stuff like poll.
| That doesn't seem too complicated?
| PunchyHamster wrote:
| No, they rebranded to AIStor and are now selling to AI
| companies.
|
| Minio is/was pretty solid product for places where rack of
| servers for Ceph wasn't an option (it does have quite a bit
| higher memory requirements), or you just need a bit of S3 (like
| we have small local instances that just run as build cache for
| CI/CD)
|
| But that's not where money is
| bouk wrote:
| big L for all the cloud providers that made the mistake of using
| it instead of forging their own path, they're kind of screwed now
| tehjoker wrote:
| How are they screwed if they can adopt the source and continue
| patching it? Writing their own would incur a greater cost.
| ibgeek wrote:
| Time to fork and bring back removed features. :). An advantage of
| it being AGPL licensed.
| cies wrote:
| I use Supabase Storage. It does S3-style signed download links
| (so I can switch to any S3 service if I like later).
| adriatp wrote:
| I had a minio server in my homelab and I have to replace it after
| the 15v because they capped almost all settings. So sad...
| thway15269037 wrote:
| So, when anyone will fork in? Call it MaxIO or whatever. I might
| even submit couple of small patches.
|
| My only blocker for a fork to maintain compatibility and path to
| upgrade from earlier versions.
| 12_throw_away wrote:
| To be fair, their previous behavior and attitude towards the
| open source license suggests that minio would possibly engage
| in at least a little bumptious legal posturing against whoever
| chose to fork it.
| spapas82 wrote:
| Minio is more or less feature complete for most use cases.
| Actually the _last_ big update of minio removed features (the
| UI). I am using minio for 5 years and haven 't messed with it or
| used any new thingie for the last 5 years (i.e since I installed
| it); I only update to new versions.
|
| So if the minio maintainers (or anybody that forks the project
| and wants to work it) can fix any security issues that may occur
| I don't see any problems with using it.
| cromka wrote:
| > Actually the last big update of minio removed features (the
| UI)
|
| AFIK they removed it only to move it to their paid version,
| didn't they?
| lionkor wrote:
| yes
| spapas82 wrote:
| Well I didn't mind when they removed it and certainly I
| didn't consider their paid version which is way too expensive
| for most use cases.
|
| The UI was useful when first configuring the buckets and
| permissions; if you've got it working (and don't need to
| change anything) you're good to go. Also, everything can be
| configured without the UI (not so easily of course).
| fithisux wrote:
| I used it for my experiments in Docker. I once or two used the
| UI, I always connected through python.
| souenzzo wrote:
| The best software is the one that doesn't change.
| liviux wrote:
| Fork in Linux foundation incoming. Minio will revert in 1-2
| years, but too late, community will move on and never return,
| reputation lost forever
| phoronixrly wrote:
| Just watch them harass fork users with proprietary stacks as
| they used to:
|
| https://github.com/minio/minio/issues/13308#issuecomment-929...
|
| https://github.com/minio/minio/discussions/13571#discussionc...
| speedgoose wrote:
| Oh no, I used MinIO once or twice for some unlicensed
| software.
|
| Should I contact a MinIO salesman to purchase an enterprise
| license ASAP or is it fine if I license my kids and advent of
| code solutions under the AGPLv3 license ?
| orphea wrote:
| > you may be violating AGPLv3 if you are using MinIO to build
| commercial products or using it for commercial purposes
|
| Yeah, this is bullshit. I wish the guy used his own advise
| and spoke to a lawyer :)
| ahepp wrote:
| Wait, what's the consensus on this? Are they saying that
| using object storage over a standard network API which they
| didn't even create, makes your application a derivative work
| of the object store?
|
| Or just that the users would need to make minio sources,
| including modifications, freely available?
|
| I guess that's kind of the big question inherent to the AGPL?
| gethly wrote:
| There is https://github.com/seaweedfs/seaweedfs
|
| I haver not used it but will be likely a good minio alternative
| for people who want to run a server and don't use minio just as
| s3 client.
| lima wrote:
| Is it stable now? Last time I checked, the amount of
| correctness bugs being fixed in the Git history wasn't very
| confidence-inspiring.
| yahooguntu wrote:
| We're in the process of moving to it, and it does seem to
| have a lot of small bugfixes flying around, but the
| maintainer is EXTREMELY responsive. I think we'll just end up
| doing a bit of testing before upgrading to newer versions.
|
| For our use case (3 nodes, 61TB of NVMe) it seems like the
| best option out of what I looked at (GarageFS, JuiceFS,
| Ceph). If we had 5+ nodes I'd probably have gone with Ceph
| though.
| rednb wrote:
| Since storage is a critical component, I closely watched it
| and engaged with the project for about 2 years circa as i
| contemplated adding it to our project, but the project is
| still immature from a reliability perspective in my opinion.
|
| No test suite, plenty of regressions, and data loss bugs on
| core code paths that should have been battled tested after so
| many years. There are many moving parts, which is both its
| strength and its weakness as anything can break - and does
| break. Even Erasure Coding/Decoding has had problems, but a
| guy from Proton has contributed a lot of fixes in this area
| lately.
|
| One of the big positive in my opinion, is the maintainer. He
| is an extremely friendly and responsive gentleman. Seaweedfs
| is also the most lightweight storage system you can find, and
| it is extremely easy to set up, and can run on servers with
| very little hardware resources.
|
| Many people are happy with it, but you'd better be ready to
| understand their file format to fix corruption issues by
| hand. As far as i am concerned, i realized that after
| watching all these bugs, the idea of using seaweedfs was
| causing me more anxiety than peace of mind. Since we didn't
| need to store billions of files yet, not even millions, we
| went with creating a file storage API in ASP.NET Core in 1 or
| 2 hours, hosted on a VPS, that we can replicate using rsync
| without problem. Since i made this decision, i have peace of
| mind and no longer think about my storage system. Simplicity
| is often better, and OSes have long been optimized to cache
| and serve files natively.
|
| If you are not interested in contributing fixes and digging
| into the file format when a problem occurs, and if your data
| is important to you, unless you operate at the billions of
| files scalability tier Seaweedfs shines at, i'd suggest
| rolling your own boring storage system.
| killme2008 wrote:
| I can't believe they made this decision. It's detrimental to the
| open-source ecosystem and MinIO users, and it's not good for them
| either, just look at the Elasticsearch case.
| apexalpha wrote:
| So how are HN reviews of GarageHQ? Or any others?
| speedgoose wrote:
| I havn't tested it since a while, but it was pretty good and a
| lot simpler than MinIO.
|
| Like in the old MinIO days, an S3 object is a file on the
| filesystem, not some replicated blocks. You could always
| rebuild the full object store content with a few rsync. I
| appreciate the simplicity.
|
| My main concern was that you couldn't configure it easily
| through files, you had to use CLI, which wasn't very
| convenient. I hope this has changed.
| realreality wrote:
| Objects in Garage are broken up into 1MB (default) blocks,
| and compressed with zstandard. So, it would be difficult to
| reconstruct the files. I don't know if that was a recent
| change since you looked at it.
|
| Configuration is still through the CLI, though it's fairly
| simple. If your usecase is similar to the way that the
| Deuxfleurs organization uses it -- several heterogeneous,
| geographically distributed nodes that are more or less set-
| it-and-forget-it -- then it's probably a good fit.
| speedgoose wrote:
| I guess this change was inevitable. But I like the
| possibility to reconstruct a broken distributed file
| storage system. GlusterFS also allowed this.
|
| My use case is relatively common : I want small S3
| compatible object stores that can be deployed in Kubernetes
| without manual intervention. The CLI part was a bit in the
| way last time, this could have been automated but it wasn't
| straightforward.
| realreality wrote:
| Garage works well for its limited feature set, but it doesn't
| have very active development. Apparently they're working on a
| management UI.
|
| Seaweedfs is more mature and has many interfaces (S3, webdav,
| SFTP, REST, fuse mount). It's most appropriate for storing lots
| of small files.
|
| I prefer the command line interface and data/synchronization
| model of Garage, though. It's easier to manage, probably
| because the developers aren't biting off more than they can
| chew.
| nazcan wrote:
| I'm quite interested in a k8s-native file-system that makes use
| of local persistent volumes. I'm running cockroachDB in my
| cluster (not yet with local persistent volumes.. but getting
| closer).
|
| Anyone have any suggestions?
| Eikon wrote:
| I've been using Minio in ZeroFS' [0] CI (a POSIX compliant
| filesystem that works on top of s3). I guess I'll switch to
| MicroCeph [1].
|
| [0] https://github.com/Barre/ZeroFS
|
| [1] https://canonical-microceph.readthedocs-hosted.com/stable/
| ahepp wrote:
| What is the use case for implementing a POSIX filesystem on top
| of an object store? I remember reading this article a few years
| ago, which happens to be by the minio folks:
| https://blog.min.io/filesystem-on-object-store-is-a-bad-idea...
| Eikon wrote:
| > What is the use case for implementing a POSIX filesystem on
| top of an object store?
|
| The use case is fully stateless infrastructure: your
| file/database servers become disposable and interchangeable
| (no "pets"), because all state lives in S3. This dramatically
| simplifies operations, scaling, and disaster recovery, and
| it's cheap since S3 (or at least, S3 compatible services)
| storage costs are very low.
|
| The MinIO article's criticisms don't really apply here
| because ZeroFS doesn't store files 1:1 to S3. It uses an LSM-
| tree database backed by S3, which allows it to implement
| proper POSIX semantics with actual performance.
| vanschelven wrote:
| Is there a good overview of recent Open Source Rugpulls in the
| vein of killedbygoogle.com somewhere?
| ncrmro wrote:
| As a note ceph (rook on kubernetes) which is distributed
| blockstorage has a built in s3 endpoint support
| valyala wrote:
| What is the purpose of MinIO, Seaweedfs and similar object
| storage systems? They lack durability guarantees provided by S3
| and GCS. They lack "infinite" storage promise contrary to S3 and
| GCS. They lack "infinite" bandwidth unlike S3 and GCS. They are
| more expensive than other storage options, unlike S3 and GCS.
| onionisafruit wrote:
| I haven't used it in a while, but it used to be great as a test
| double for s3
| maartin0 wrote:
| It's great for a prototype which doesn't need to store a huge
| amount of data, you can run it on the same VM as a node server
| behind Cloudflare and get a fairly reliable setup going
| cortesoft wrote:
| We use it because we are already running our own k8s clusters
| in our datacenters, and we have large storage requirements for
| tools that have native S3 integration, and running our own
| minio clusters in the same datacenter as the tools that
| generate and consume that data is a lot faster and cheaper than
| using S3.
|
| For example, we were running a 20 node k8s cluster for our
| Cortex (distributed Prometheus) install, monitoring about 30k
| servers around the world, and it was generating a bit over a TB
| of data a day. It was a lot more cost effective and performant
| to create a minio cluster for that data than to use S3.
|
| Also, you can get durability with minio with multi cluster
| replication.
| wasmitnetzen wrote:
| S3 is a widely supported API schema, so if you need something
| on-prem, you use these.
| spapas82 wrote:
| Minio allows you to have an s3 like interface when you have
| your own servers and storage.
| paulddraper wrote:
| Open source is not a sustainable business model.
|
| There are two ways open source projects continue.
|
| 1. The creator has a real, solid way to make money (React by
| Facebook, Go by Google).
|
| 2. The project is _extremely_ popular (Linux, PostreSQL).
|
| Is it possible for people to reliably keep working for ~free?
| Yes, but if you expect that, you have a very bad understanding of
| 98% of human behavior.
| 0x1ch wrote:
| > Kill open source features.
|
| > Gaslight community when rightfully annoyed
|
| > Kill off primary product
|
| > Offer same product with AI slapped on the name to enterprise
| customers.
|
| Good riddance Minio, and goodbye!
| spicymaki wrote:
| Stallman was right. When will the developer community learn not
| to contribute to these projects with awful CLAs. The rug has been
| pulled.
___________________________________________________________________
(page generated 2025-12-03 23:00 UTC)