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.