jacob2161

Chrony over NTP is capable of incredible accuracy, as shown in the post. Most users who think they need PTP actually just need Chrony and high quality NICs.

Chrony is also much better software than any of the PTP daemons I tested a few years ago (for an onboard autonomous vehicle system).

That's a good point too. It seems a bit weird to me to garbage collect connections that I know I'll just recreate in most cases, especially when they're so cheap and limited in number.

Cycling connections may cover for certain classes of bugs but I dislike doing things for this reason, but maybe there are others. I'll put some thinking/testing into it at some point.

Thanks!

Yeah, that's a good point. It's less about LOC than complexity (data structures, complicated string parsing, handling binary data, etc). And that's actually the advice I follow myself.

Some longish Bash scripts are very maintainable and reliable, because they're still quite regular and simple.

Thanks for the comments. I'm a fan.

Yeah, I think "PRAGMA optimize" here on startup is basically a no-op and only costs microseconds but I should just remove it.

Seems like the ideal thing is to spawn a goroutine and run optimize periodically. Many Go daemons I run will have uptime measured in months so running on shutdown isn't super useful there.

Another one I might add is running `PRAGMA wal_checkpoint(PASSIVE)` periodically from a goroutine, which is something I've done in some of my daemons. Because otherwise a random write suffers from increased latency due to having to checkpoint.

Probably makes sense to open a dedicated read/write connection just for running `PRAGMA wal_checkpoint(PASSIVE)` at some regular interval to keep ahead of any autocheckpointing?

Thanks for pointing this out. I don't think it's something this little helper library should try to do. This kind of thing belongs in whatever database abstraction you're building/using, if any. It's also a little trickier than it seems at first glance (RETURNING, etc).

And for many no/low concurrency situations there's no/little benefit.

Added this example to the README.

  rwdb, err := sqlitebp.OpenReadWriteCreate("app.db")
  if err != nil {
    log.Fatal(err)
  }
  rwdb.SetMaxOpenConns(1)
  rwdb.SetMaxIdleConns(1)


  // Read-only with default adaptive pool size (2-8 based on GOMAXPROCS)
  rodb, err := sqlitebp.OpenReadOnly("app.db")
  if err != nil {
    log.Fatal(err)
  }

That post is quite nitpicky, pointing to edge cases and old version behavior. The essence of it is that writing reliable Bash scripts requires significant domain knowledge, which is true.

Bash scripts are great if you've been doing it for a very long time or you're doing something simple and small (<50 LOC). If it's complicated or large, you should just write it in a proper programming language anyway.

You're assuming env is in /usr/bin?

There are real environments where it's at /bin/env.

Running a script with

  bash script.sh

Works on any system with bash in the path, doesn't require that it be executable, and is usually the ideal way to execute them.

I don't really believe in trying to write portable Bash scripts. There's a lot more to it than just getting the shebang right. Systems and commands tend to have subtle differences and flags are often incompatible. Lots of branching logic makes them hideous quickly.

I prefer to write a script for each platform or just write a small portable Go program and compile it for each platform.

I'm almost always writing Bash scripts for Linux that run in Debian-based containers, where using /bin/bash is entirely correct and safe.

Regarding verbosity, most people come to appreciate a little verbosity in exchange for clarity with more experience. Clever and compact code is almost never what you want in production code.

Stylistically, I much prefer

  #!/bin/bash
  set -o errexit
  set -o nounset
  set -o pipefail

It reminds me when I wrote a lot of Perl:

  #!/usr/bin/perl
  use strict;
  use warnings;

I also prefer --long --args everywhere possible and a comment on any short flag unless it's incredibly common.

I've been writing all my Bash scripts like this for ~15 years and it's definitely the way to go.

Yeah, I'd love to see growth improve but Bluesky is already in an exclusive club of social apps that have "broken through" in some significant way. It's not going anywhere.

And it's the only open network built on an open protocol to ever do so.

I agree there's a lot of room for improvement in making it easier.

But certain things like full-network relays/app views just have inherent bandwidth/storage/compute costs associated with them but it's definitely something a non-profit (like Internet Archive) could easily afford to do.

The PLC service could likely be hosted for ~$40/mo.

Anyone else is also free to run these services (app views, relays) and a few people already are doing this.

An atproto PDS is like a structured-data blog hosted on a web server. Anyone is free to index, relay, and render the data.

1. I believe they actually could generate (low) billions of dollars without compromising at all, if they manage to reach true mainstream scale (>1 billion MAUs)

2. I really don't care if the investors/shareholders are disappointed as long as the PBC's mission is fulfilled. Also their control is relatively limited.

Maybe I should have written added this:

Disclaimer: I am a shareholder in Bluesky Social, PBC (former employee)

Bluesky is built on atproto, which is designed to be "locked open" in a way that can't be rescinded. That was a core design constraint.

VCs funded Netscape which did more than any other company to launch the web and they made a lot of money without having to destroy the ideals of the web.

I believe this isn't as much of a problem as it appears to be at first glance because of the scale of social apps like Bluesky.

For example, Wikipedia generates >$180M/yr just by running ads for itself requesting donations. Requesting donations is the least effective monetizing strategy and yet it still works because of scale.

Donations would probably work but Bluesky has additional options. They could create a premium app for power users that just adds nice-to-have features (which may cost real money to provide and maintain), they can resell domain names, they can sell merch, etc.

Bluesky doesn't need to generate billions of dollars to be highly sustainable and profitable. It was built and scaled with fewer than 20 full time employees.

The most important and most difficult part is getting to sufficient scale, and that's mostly a matter of just making the app even better than it is today.

I posted a bit about this here: https://bsky.app/profile/jacob.gold/post/3lr5j6o7emk2t

You have a fair point about plow. I've used it enough to know that it basically works at spamming HTTP requests at a specified concurrency. When I'm doing something where I want better accuracy I've tended to use K6 and Vegeta.

> Yeah, but, unless `plow` actually follows that redirect, it's not really measuring the actual end-to-end latency...

Not in this case, since the purpose here was to measure the POST (write) not the subsequent GET (read) that a browser would do after the redirect.

(I didn't downvote you)

plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully.

The writes returned 3xx because the handler returns a redirect, so this is expected.

In the post I also showed results for a little `gohttpd` program running the CGI program:

https://github.com/Jacob2161/cgi-bin/blob/main/gohttpd/main....

See as "Benchmarking (writes|reads) using Go net/http"

It was faster but not by very much. Running CGI programs is just forking processes, so Apache's forking model works just about as well as anything else.