> Our Founder! of this project is battling cancer. Your Stars and Forks are appreciated.
I'm sorry to hear this, but I'm also surprised that this is the first thing I learnt about this project, and that it is written in the third person. It detracts from the project.
I don't have a problem with mentioning cancer, but they should've mentioned which cancer to raise awareness and help others. The ribbon icon is gold which means pediatric/childhood cancer?
Asking for stars and forks is where it gets weird. I understand a crowdfunding program but how is this going to help?
Makes it even weirder that this is a completely anonymous, we don't know who works on it, and actually the project pretends to be authored by "AI". look at commit history and contributors
I don't want to be cynical here, my dad was diagnosed with cancer too but this just feels like some LLM was given a prompt to maximize stars and forks and this is how that went. I am very sorry to say this.
Although not disclosed on this page, the author's name is mentioned on their other projects[0].
> Our founder, Todd Bruss, is currently battling Cancer. Through it all, he continues to pour his heart into InkPen. Your support and encouragement mean the world.
The author has posted about their project on LinkedIn as well[1].
Open-source maintainers don't owe anyone perfectly-manicured marketing copy on their landing pages. Honestly, the fact that is the first thing you learn humanises the username behind the keyboard
> the fact that is the first thing you learn humanises the username behind the keyboard
The username is macOS26. The name is "Agent!". As in "Agentic AI for your entire Mac Desktop". All commits are made by this entity.
Until someone here told me there is a real guy behind it I sincerely gotta say, it looks like there's no human behind the keyboard and actually there's no keyboard at all.
Combined with cancer message on top it made me think some LLM "agent" is trying different tricks because it was prompted to achieve maximum stars and forks. I feel shitty for saying this but how not to be cynical because literally that's what we degraded to thanks to "ai".
> Combined with cancer message on top it made me think some LLM "agent" is trying different tricks because it was prompted to achieve maximum stars and forks. I feel shitty for saying this but how not to be cynical because literally that's what we degraded to thanks to "ai".
AI might increase the volume of shitty things on the internet, but it's not like GitHub accounts weren't anonymous before AI, and it's not like people weren't using scammy tactics to boost their star count before AI.
If the fear of AI turn us into worse people in our interactions, that's kind of on us, not AI
This is a complexity that makes it harder, but not insurmountable.
It would be reasonable to say that if you run the file sync in a mode that keeps everything locally, then Backblaze should be backing it up. Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
> Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
When you have a couple terabytes of data in that drive, is it acceptable to cycle all that data and use all that bandwidth and wear down your SSD at the same time?
Also, high number of small files is a problem for these services. I have a large font collection in my cloud account and oh boy, if I want to sync that thing, the whole thing proverbially overheats from all the queries it's sending.
Reading your comments, it sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files. I know you haven’t technically said that, but that’s what it sounds like.
I assume you don’t think that, so I’m curious, what would you propose positively?
> I know you haven’t technically said that, but that’s what it sounds like.
Yes, I didn't technically said that.
> It sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files.
I don't argue neither, either.
What I said is with "on demand file download", traditional backup software faces a hard problem. However, there are better ways to do that, primary candidate being rclone.
You can register a new application ID for your rclone installation for your Google Drive and Dropbox accounts, and use rclone as a very efficient, rsync-like tool to backup your cloud storage. That's what I do.
I'm currently backing up my cloud storages to a local TrueNAS installation. rclone automatically hash-checks everything and downloads the changed ones. If you can mount Backblaze via FUSE or something similar, you can use rclone as an intelligent MITM agent to smartly pull from cloud and push to Backblaze.
Also, using RESTIC or Borg as a backup container is a good idea since they can deduplicate and/or only store the differences between the snapshots, saving tons of space in the process, plus encrypting things for good measure.
This. You should not try to backup your local cache of cloud files as if those were your local files. Use a tool that talks to the cloud storage directly.
Use tools with straightforward, predictable semantics, like rclone, or synching, or restic/Borg. (Deduplication rules, too.)
My understanding of Backblaze Computer Backup is it is not a general purpose, network accessible filesystem.[0] If you want to use another tool to backup specific files, you'd use their B2 object storage platform.[1] It has an S3 compatible API you can interact with, Computer Backup does not.
But generally speaking, I'd agree with your sentiment.
But if the files are only on the remote storage and not local, chances are they haven't been modified recently, so it shouldn't download them fully, just check the metadata cache for size / modification time and let them be if they didn't change.
So, in practice, you shouldn't have to download the whole remote drive when you do an incremental backup.
You can't trust size and modification time all the time, though mdate is a better indicator, it's not foolprooof. The only reliable way will be checksumming.
Interestingly, rclone supports that on many providers, but to be able to backblaze support that, it needs to integrate rclone, connect to the providers via that channel and request checks, which is messy, complicated, and computationally expensive. Even if we consider that you won't be hitting API rate limits on the cloud provider.
Sometimes modification time of a file which is not downloaded on computer A, but modified by computer B is not reflected immediately to computer A.
Henceforth, backup software running on computer A will think that the file has not been modified. This is a known problem in file synchronization. Also, some applications modifying the files revert or protect the mtime of the file for reasons. They are rare, but they're there.
The problem is, downloading files and disk management is not in your control, that part is managed by the cloud client (dropbox, google drive, et. al) transparently. The application accessing the file is just waiting akin to waiting for a disk spin up.
The filesystem is a black box for these software since they don't know where a file resides. If you want control, you need to talk with every party, incl. the cloud provider, a-la rclone style.
> even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today
Citation needed. A human engineer can grok a lot in 10 days, and an agent can spend a lot of tokens in 10 days.
It might not be Cloudflare's fault, but it is their problem. If their customers can't use their products sporadically, it doesn't really matter why. Cloudflare taking a principled approach hurts their users in the short term, so they have to make a business trade-off between pragmatism and principle. Currently they're choosing principle, so it's reasonable to be angry at them for the short term issues that causes.
Geohot is famous for not being as smart as he makes out. Famously said he'd go to Twitter when Musk bought it and help Musk fix search, because "how hard can it be". Then left in shame 3 months later having achieved nothing except figuring out that It's A Bit More Complicated Than That(tm).
Comma does some cool stuff, if relatively entry-level, and this post is good napkin-maths and was a fun read, but there is so much more depth and a hundred ways in which this post is wrong or over-simplified to the point of near irrelevance.
That someone thinks they can personally "fix search" in a few months at a multi-billion dollar social network that just fired half its engineering staff, however, does.
The GTA fix shows humility, literally the first sentence of the "recon" section is "First I wanted to check if someone had already solved this problem". Geohot wasn't interested in if anyone had tried and failed to "solve search", or why it might be a difficult problem. He assumed that Twitter were a bunch of idiots.
The whole approach of the GTA fix author is curious and humble. Very low ego.
It can back on to git if you want, so a migration doesn't have to be all-at-once. It already has all of these features and more. It's stable, fast, very extensible.
jj truly is the future of version control, whereas git plus some loosely specified possibly proprietary layer is not.
I'm excited to see what ersc.io produces for a jj hosting service and hopefully review UI.
I'm sorry to hear this, but I'm also surprised that this is the first thing I learnt about this project, and that it is written in the third person. It detracts from the project.
reply