Earlier quoted context omitted.
Sent you an invite code.
Could you send me one? Email in my profile. Thanks.
i emailed you one
Bluesky migrates to single-tenant SQLite
231–240 of 247 posts
Re: Bluesky migrates to single-tenant SQLite
#232Re: Bluesky migrates to single-tenant SQLite
#233That looks like the PR from hell - 190 files changed, 143 commits? Mostly with names like "tidy" and "wip" Props to whoever actually reviewed that, you are a warrior
I prefer to read the unified diff and commits don't matter as much.
You do you but, at the point of publishing a branch for review, I'd insist the changes are presented as a story, with well-written commit messages that helps the reader/reviewer orient themselves and presents a coherent narrative.
Anthing else, I call it a landfill site, not a maintained repository.
In fact, I'd go as far as using their commit habit as a measure of a candidate's consideration for their colleagues.
Re: Bluesky migrates to single-tenant SQLite
#234Slightly related: is Bluesky moderated good enough or do I get lots of rightwing and conspiracy crap like on twitter currently? I‘d really love to have some more civilized hub again that isn’t full of hate and anti-intellectualism.
Haven't poked my head in there in a while, but in my experience it was more the opposite where much of the discourse is dominated by tech-left influencer types and their followers who migrated from Twitter. Choose your echo chamber I guess.
Re: Bluesky migrates to single-tenant SQLite
#235What do they mean by "Since SQLite does not support concurrent transactions" - it supports them, as long as you don't access the .db file through a file share (UNC, or NFS, etc) - https://www.sqlite.org/wal.html I've been using this to update/read db from multiple threads/processes on the same machine. You can also do snapshotting with the sqlite backup API, if you want consistent view, and to not hold on transaction…
Did you disable auto checkpointing? Wouldn’t checkpointing result in potential corruption or at least data loss if two processes do that simultaneously? Or is that scenario exhaustively prevented with a lock file?
Your post made me look more into checkpoints, and understand better the tradeoffs in sqlite+wal about it - e.g. less frequent checkpoint means larger log (wal files), hence slower reads - as reads have to go through the wal file (there is some index, but still) to vet the data. But it makes writing faster.
And the opposite more frequent checkpoints, means faster reads (no need to through bigger wal file, and smaller index), but writes are slower.
So it really depends on what's happening right now, if you can anticipate it - e.g. populating for the first time data into it (maybe decrease checkpoint updates, then turn it back on).
Or if you constantly log, and read only that much (though not sure if you have constraints, triggers whether there are no hidden reads).
Or the opposite - a "read-only" if possible version of sqlite.db would be ideally without any wal.
So your post helped understand that there is stuff that I don't know and need to look further into it.
Thanks!
Re: Bluesky migrates to single-tenant SQLite
#236Earlier quoted context omitted.
The first line of the commit message isn't about including information that couldn't be gleaned from the commit. That can be done in subsequent lines. The first line is for two purposes: * Priming the reader so they are able to quickly interpret what they're seeing when they open the commit. * Making it easy to search or scan for a specific change. The last commit message in my example would probably have included th…
> Making it easy to search or scan for a specific change. I'm trying to imagine the near infinite terms I would have to search for to find the commit where I "changed from a hash to a set". Regardless, every other thing you said could also just be done in the central PR body (and thus the merge commit) and be much easier to access. Instead of "priming the reader" it's infinitely more helpful to tell the reader why yo…
> Instead of "priming the reader" it's infinitely more helpful to tell the reader why you did something, because you can't extract that from a diff.
Again, that can go in the PR body or in subsequent lines. You have ~50 characters in that first line, which is never going to be enough to fully explain anything.
I'm also not suggesting that you eliminate the PR body: that should also include more context. All I'm suggesting is that taking the trouble to organize your commits into discrete units helps reviewers to understand how you perceive the various changes in a single PR as being related to one another, and no amount of text in the PR body will provide the same benefit as being able to look at several distinct diffs containing related changes.
Re: Bluesky migrates to single-tenant SQLite
#237Re: Bluesky migrates to single-tenant SQLite
#238Earlier quoted context omitted.
Does the BGS pull all the tenant‘s individual SQLite data? Or do the PDS push new posts to the BGS?
The BGS (which is an atproto "relay" service) subscribes to all PDS event streams on the entire network, and aggregates and relays them. This way it's possible to get all network data from a single place (the BGS) rather than having to connect to every PDS, which is simpler for consumers and dramatically reduces the workload of PDS hosts. Some details about event streams here, although the APIs are still evolving: ht…
Thank you!
Re: Bluesky migrates to single-tenant SQLite
#239Earlier quoted context omitted.
It is, but not as a "growth hack" or anything. It's just a way of limiting growth while the system is scaled (in terms of the backend and abuse prevention). There's a dedicated waitlist for developers that will get you access quite quickly: https://atproto.com/blog/call-for-developers
It's pretty hard not to see it as a growth hack given that posts can't even be viewed without an account. That seems pretty transparently to be a system to create a feeling of FOMO/exclusivity, to make it so that you don't only need an account to participate, you need an account to even see what the network is or to follow anyone on it at all. As a comparison, Cohost limited account setup when it launched as a way to…
I asked the Bluesky devs about this back in May (of 2023).
Me: "if the network is intended to be public, why are user profiles and posts currently hidden behind a login wall?"
Paul Frazee: "it was a kind of bad artifact of how we set things up initially (just trying to ship). once we realized it communicated the wrong idea it was too late, and we now need to spend a heavy bit of effort communicating before we spring it on everybody."
Re: Bluesky migrates to single-tenant SQLite
#240If anyone needs a Bluesky invite, there are three in the About section of my profile page here (note: you will need to prepend "bsky-social-" to the code).