Comment by detritus | Hacker News Reader

Comment by detritus | Hacker News Reader

Y'all might want to get to the point a bit quicker in your pitch. A lot of fluff to wade through before the lede..

"Garage is a distributed storage solution, that automatically replicates your data on several servers. Garage takes into account the geographical location of servers, and ensures that copies of your data are located at different locations when possible for maximal redundancy, a unique feature in the landscape of distributed storage systems.

Garage implements the Amazon S3 protocol, a de-facto standard that makes it compatible with a large variety of existing software. For instance it can be used as a storage back-end for many self-hosted web applications such as NextCloud, Matrix, Mastodon, Peertube, and many others, replacing the local file system of a server by a distributed storage layer. Garage can also be used to synchronize your files or store your backups with utilities such as Rclone or Restic. Last but not least, Garage can be used to host static websites, such as the one you are currently reading, which is served directly by the Garage cluster we host at Deuxfleurs."

Thanks for the feedback! We will definitely be adjusting our pitch in further iterations.

I'm the layest of laymen, is Garage "a distributed Dropbox"?

It's the layer below: a sound distributed storage backend. You can use it to distribute your Nextcloud data, store your backups, host websites... You can even mount it in your OS' file manager and use it as an external drive!

Who owns the servers?

You own the servers. This is a tool to build your own object-storage cluster. For example, you can get 3 old desktop PCs, install Linux on them, download and launch Garage on them, configure your 3 instances in a single cluster, then send data to this cluster. Your data will be spread and duplicated on the 3 machines. If one machine fails or is offline, you can still access and write data to the cluster.

Then, how does Garage achieve 'different geographical locations'? I only have my house to put my server(s). That's one of the main reasons I'm using cloud storage. Or is the point that I can arrange those servers abroad myself, independent of the software solution (S3 etc)?

Garage is designed for self-hosting by collectives of system administrators, what we could call "inter-hosting". Basically you ask your friends to put a server box at their home and achieve redundancy that way.

Great, thanks. It would be great to add this in the main explanation (how to get access to servers).

Is the data encrypted at rest, or should I encrypt the data myself?

The content is currently stored in plaintext on the disk by Garage, so you have to encrypt the data yourself. For example, you can configure your server to encrypt at rest the partition that contains your `data_dir` and your `meta_dir` or build/use applications that supports client-side encryption such as rclone with its crypt module[0] or Nextcloud with its end-to-end encryption module[1].

[0]: https://rclone.org/crypt/

[1]: https://nextcloud.com/endtoend/

I'm not quite sure who the article is actually written for. If it's written to generate interest from investors, or for some other such semi/non technical audience then please ignore this (although the fact that I can't tell who it's written for is in itself a warning signal).

If it's written to attract potential users, however, then it's woefully light on useful content. I don't care in the slightest about your views on tech monopolies - why on earth waste such a huge amount of space talking about this? What I care about are three things: 1) what workloads does it do well and, and which ones does it do poorly at (if you don't tell me about the latter I won't believe you - no storage system is great at everything). 2) What consistency/availability model does it use, and 3) how you've tested it.

As written, it's full of fluff and vague handwavy promises (we have PhDs!) - the only technical information in the entire post is that it's written in rust. For users of your application, what programming language it's written in is about the least interesting thing possible to say about it. Even going through your docs I can't find a single proper discussion of your consistency and availability model, which is a huge red flag to me.

This article broadly explains the motivation and vision behind our project. There are many object stores, why build a new one? To push self-hosting, in face of democratic/political threats we feel are daunting.

Sorry it didn't float your boat. You're just not the article's target audience I guess! (And, to answer your question: the target audience is mildly-knowledgeable but politically concerned citizens.)

I agree this is maybe not the type of post you'd expect on HN. But, we don't want to _compete_ with other object stores. We want to expand the application domain of distributed data stores.

> I can't find a single proper discussion of your consistency and availability model

LGTM, I would be dubious too. This will come in time, please be patient (the project is less than 2 yo!). You know Cypherunks' saying? "We write code." Well, for now, we've been focusing on the code, and we want to continue doing so until 1.0. Some by-standers will do the paperware for sure, but it's not our utmost priority.

Thanks for the response. It's great that you're trying to build something that will allow folks to do self-hosting well, I'm fully on board with this aim. My point about the political bits though, is that even for folks that agree with you, pushing the political bits too much can signal that you're not confident enough in the technical merits of what you're doing for them to stand on their own.

Re: the paperwork vs code thing - While a full white paper on your theoretical foundations would be nice, IMO the table stakes for getting people to take your product seriously is a sentence or two on the model you're using. For example, adding something like: "We aim to prioritise consistency and partition tolerance over availability, and use the raft algorithm for leader elections. Our particular focus is making sure the storage system is really good at handling X and Y." or whatever would be a huge improvement, until you can get around to writing up the details.

The problem with "we write code" is that your users are unlikely to trust you to be writing the correct code, when there's so little evidence that you've thought deeply about how to solve the hard problems inherent in distributed storage.

It was actually deliberate to present our project through the political lens, today.

You will find a more streamlined presentation of Garage on our landing page at https://garagehq.deuxfleurs.fr/

Technical details are also documented (although it is insufficient and needs an overhaul): https://garagehq.deuxfleurs.fr/documentation/design/

Thank you for your comments!

For the average user it shouldn't matter what its written in, but lately I've returned to the theory that language choice for a project signals a certain amount of technical sophistication. Particularly, for things like this, which should be considered systems programming. The overhead of a slow JIT, GC, threading model, IO model, whatever basically means the project is doomed to subpar perf forever and the cost of developing it has been passed on to the users, which will be forced to buy 10x the hardware to compensate.

> For the average user it shouldn't matter what its written in,

True.

> but lately I've returned to the theory that language choice for a project signals a certain amount of technical sophistication.

Sometimes it can signal the opposite, if you think a given language/framework/other is not a great tool for the job. For a relatively new project it can be a sign that there might be otherwise avoidable growing pains later.

From an open source standpoint what a project is written using can be very important from the point of view of what you are familiar with. If the project progress or support vanishes (for instance if the core maintainers move on to other things for whatever reason, or there is a significant license change making future work on the core project incompatible with your use) would others be able to maintain it securely in a fork and if no one else steps up would you be able to (at least until you migrated onto something else)?

Reply on news.ycombinator.com