I am so sick of AI generated README's, they follow the samn damn format.
As you can imagine, "story telling" isn't something everyone has mastered, so it does make the job easier. But I do get your point.
Show HN: CallFS – S3-style object store in one Go binary (MIT)
11–20 of 31 posts
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#12I am so sick of AI generated README's, they follow the samn damn format.
I'm so sick of these vibe coded apps. They all end up having security issues. Definitely wouldn't trust it.
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#13I am so sick of AI generated README's, they follow the samn damn format.
As you can imagine, "story telling" isn't something everyone has mastered, so it does make the job easier. But I do get your point.
We don't want story telling. We just want a clear, few lines long paragraph that tells everything you need to know about the software
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#14I can't quite square up your "speaks the S3 API" with https://github.com/ebogdum/callfs#file-operations seeming to do its own thing, which for sure would not leverage existing tooling And it would have been better if in your "static binary" sentence you had included its dependence upon both PostgreSQL and Redis
I had the same question, and started looking more deeply at the project. Would be interested to hear if this was built by OP or vibe-coded.
> if this was built by OP or vibe-coded
I hope we start to see some etiquette / conventions developed around this, especially for open source projects.
if I showed up to a dinner party with homemade cookies, my friends would be appreciative.
if I showed up with store-bought cookies, my friends would probably still be appreciative.
but if I showed up with store-bought cookies and tried to claim they were homemade, my friends would probably feel insulted. even if the cookies were amazing, they'd be overshadowed by my dishonesty about them.
the problem, of course, is that if we had some standard section in a readme for expressing the spectrum between "0% LLM output, entirely whittled by hand as a labor of love" vs "100% LLM output, human eyes have never actually looked at any of it" we'd have LLMs hallucinate that readme section, saying they were human-coded.
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#15I was wanting this to exist today :) Thanks for sharing the work
https://github.com/juicedata/juicefs
https://github.com/seaweedfs/seaweedfs is excellent as well
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#16Earlier quoted context omitted.
I had the same question, and started looking more deeply at the project. Would be interested to hear if this was built by OP or vibe-coded.
A bit of both, as you can imagine, there are so many tedious tasks that consume time for so little in return, so yeah.
So you're trying to get buy-in for a tool, when you yourself don't see the point in confirming it works? Those "tedious tasks" are software development.
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#17Earlier quoted context omitted.
A bit of both, as you can imagine, there are so many tedious tasks that consume time for so little in return, so yeah.
So you're trying to get buy-in for a tool, when you yourself don't see the point in confirming it works? Those "tedious tasks" are software development.
What, you mean writing documentations and readme?
Of course I'm using this. I have a homelab with 12 PI's, this tool helps me play with files between all of them, any way I want. Might not be the world changing usage you were hopping for, but for me it's enough.
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#18Earlier quoted context omitted.
I had the same question, and started looking more deeply at the project. Would be interested to hear if this was built by OP or vibe-coded.
> if this was built by OP or vibe-coded I hope we start to see some etiquette / conventions developed around this, especially for open source projects. if I showed up to a dinner party with homemade cookies, my friends would be appreciative. if I showed up with store-bought cookies, my friends would probably still be appreciative. but if I showed up with store-bought cookies and tried to claim they were homemade, my…
Will not argue, pro or against, everyone is entitled to their own opinion. But this reminds me of the early 2000 interviews when every one was asking if you used Google search, and now we use "google it" as a verb.
There was a meme at one point with a dude at an interview answering that with something like this: If you google a recipe, it doesn't mean the food is done, you still need someone to cook it.
As for the "xx% LLM" or not, I would argue the same for "xx% Googled", "xx% Stackoverflow" "xx% Learned in school vs copied from the interned", "xx% actual development and engineering vs library importing and glueing".
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#19I am so sick of AI generated README's, they follow the samn damn format.
I'm so sick of these vibe coded apps. They all end up having security issues. Definitely wouldn't trust it.
You have a very good point.
Definitely, no one would force you to use something you don't find as trustworthy or valuable.
Re: Show HN: CallFS – S3-style object store in one Go binary (MIT)
#20Earlier quoted context omitted.
So you're trying to get buy-in for a tool, when you yourself don't see the point in confirming it works? Those "tedious tasks" are software development.
What, you mean writing documentations and readme? Of course I'm using this. I have a homelab with 12 PI's, this tool helps me play with files between all of them, any way I want. Might not be the world changing usage you were hopping for, but for me it's enough.
> I have a homelab with 12 PI's, this tool helps me play with files between all of them
did you have your LLM write the Show HN description too?
because you've gone from "We started CallFS" and "our small team" to "I play with it in my homelab"
if this is a homelab-level project, there's absolutely nothing wrong with that. but you should be careful not to mislead people, even unintentionally, about the stability/maturity of the project.
especially when the project involves data storage. vibe-coding a game is one thing, if it has bugs then you might miss a power-up or get stuck on a level with no way out. when a vibe-coded storage system has bugs, you're potentially losing or silently corrupting user data.