bdarnell

Google Reader's maintenance/downtime page was a Clerihew (preserved at readerisdead.com)

    Google Reader's
    built with electrons and leptons, meters and liters.
    We're off dealing with those particles
    so we can bring you your articles.

This misfeature can show up in surprising places. Any use of assembly (`.s`) files in a Go program will by default add the executable-stack flag, as we discovered in CockroachDB: https://github.com/cockroachdb/cockroach/issues/37885

I also like this larger hexagonal one: https://rampion.github.io/RegHex/

It's mainly for fun, but to find cases where it might be useful, think about symlinks into this filesystem. `ln -s /bashfs/somescript.sh /etc/hosts` and then your hosts file can be dynamically generated without any changes to programs that read it. It can be a clever way to sneak dynamic behavior into contexts where there would normally just be a static file.

Don't destroy it, embrace it. AMP is the low-javascript web many of us pine for. If browsers implemented AMP natively (and it were properly standardized), it would be great, and it has tons of potential for things like RSS readers. Google's heavy-handedness here has a lot of problems, but if they've managed to get publishers on board with a move away from the JS quagmire we should be pushing in the same direction and not fighting against it.

> if I'm using CockroachDB and don't want to manage it myself, my only option is Cockroach Labs.

Cockroach Labs is not your only option; you can also use other providers that have a license agreement with us. Our first partner in this area is ObjectRocket: https://www.objectrocket.com/blog/cockroachdb/introducing_co...

I'd like to thank our friends at TimescaleDB for the idea to use schema control as the dividing line (they're doing the same thing in their license)

(Cockroach Labs founder)

The details are in the "additional usage grant" clause: https://github.com/cockroachdb/cockroach/blob/8acfe8ffd0028c...

We decided to draw the line at whether the end user has direct control over table schemas. If users can specify the schema to be used, it's a database service and needs a license. If you're fitting everything into a generic schema (even if the user can specify things that look like new columns in the UI), it's an application and doesn't need a special license.

I think this is an argument for not giving root/superuser all possible permissions by default. It's OK that granting the `pg_execute_server_program` permission gives access to this feature, but it should still be something you have to opt in to, instead of making database superuser equivalent to the host user that the database runs as.

For comparison, in CockroachDB (disclosure: I'm a co-founder of Cockroach Labs), we don't have any features that let you execute server programs, but we do have something analogous to `pg_{read,write}_server_files` via the BACKUP, RESTORE, and IMPORT commands. In order to use these commands with a target on the server's filesystem, though, the database `admin` role isn't enough. The server also needs to be started with the `--external-io-dir` flag (and file operations will be limited to that directory). This gives an extra layer of opt-in before filesystem operations are allowed.

Here's the NEWS file for the curious: http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=e...

> Note, I don't believe it's necessary for _all_ transactions to be strictly serializable, but I would make the argument that all read-write transactions should be in order to prevent the anomaly in the article. In other circumstances it's reasonable to make the tradeoff and accept potentially stale data.

How exactly does the "free checking" example work?

Is it two transactions, where each transaction is responsible for checking the total balance across all accounts? Or is it three transactions, where a third read-only transaction verifies the sum of all accounts?

If it's two transactions, I think the anomaly as described is prevented even by non-strict serializability, because the additional reads force the transactions to conflict. If it's three transactions, then what we're really concerned with is the read-only transaction. What does it mean to mix some strictly-serializable transactions and non-strictly-serializable ones?

T.V. Raman (author of Emacspeak) has said that "S-Expressions are a major win" for visually-impaired users because they give you a good way to navigate the code structurally ("go to beginning of expression" is more accessible than "go up one line").

https://tvraman.github.io/emacspeak/manual/Emacspeak-And-Sof...

This is significant for programs written in Go, which tends to make system calls directly instead of using the libc wrapper functions. LD_PRELOAD trickery often doesn't work with Go programs for this reason.

In theory `information_schema` is supposed to be universal, so you could do `select table_name from information_schema.tables`. However, getting useful information out of `information_schema` tends to require fairly complex queries and still has quirks and differences between databases.

Performance isn't the only thing to consider. For example, tcmalloc and jemalloc both have good profiling/debugging tools, and these are the biggest reasons why I choose one of them for any large C/C++ project. I've also found that jemalloc is easier to integrate into complex build systems than tcmalloc, so jemalloc is my first choice in most cases.

I learned Python 1.4 on DOS (with DJGPP). I think there were binary releases, but you couldn't use them if you needed any third-party C modules. There was no dynamic linking on DOS so you needed to statically link any C code you were using into python.exe. This was a huge pain but it also taught me a ton about both C and Python.

I'm also a fan of emacs shell and tramp, and use functions like this to start shells on remote boxes without the extra dired/whatever step:

  (defun shell-foo()
    (interactive)
    (let ((default-directory "/ssh:bdarnell@foo:/home/bdarnell/"))
      (shell "*shell-foo*")))

> When would you need to revoke an individual cert and why wouldn't that be better handled by just shutting down the VM or container instead?

You revoke a cert when it's somehow been compromised and something other than the VM/container that's supposed to has it gets a copy of it.

What "standard auth options" do you have in mind for node-to-node auth? The ones that come to my mind are even more of a pain to set up than TLS certs.

It's true that setting up a secure cluster is kind of annoying right now. But the kubernetes templates (https://github.com/cockroachdb/cockroach/tree/master/cloud/k...) do support secure mode now, and the plan is to provide more like this so it's not something that everyone has to solve by hand.

If you know or can predict the addresses or hostnames you'll be using, then it's possible to generate one cert and reuse it for multiple nodes. This isn't ideal from a security perspective since you lose the ability to revoke individual certs, but since we don't (yet) support CRLs/OCSP it's not much of a loss.

Adding an option to skip hostname checks for node certs might make this less of a pain (it would then be trivial to share one cert for all nodes if that's what you want to do). We'll consider that and see if it compromises any important security properties.

Some of those have been done, but not all, so it's still not possible to use CockroachDB with the Django ORM. The biggest blocker (IIRC) is that the default set of migrations that Django performs on a new database uses ALTER COLUMN TYPE.

Some of the features from those lists we have implemented include ALTER COLUMN SET DEFAULT, pg_table_is_visible(), UUID, extract(), and (some) schema changes in transactions. 1.2 will add (at least) INET types and sequences.

The basic tools (pip and virtualenv) have been the same for years. Posts like this are about layers that people have built on top of the same underlying tools. There's a lot of them, but that's because different people have different preferences, not because those preferences are changing over time. There's no need to chase the latest trend here (if indeed there is a trend).

Yes, exactly. bin/pip inside the virtualenv installs into that virtualenv.

You can use virtualenv without `bin/activate`. Just refer to `bin/python` (and other scripts in `bin/`) explicitly. Don't bring in the magic until you need it. And when you need it, consider what kind of magic you need. If you're typing `bin/` too much, do you need something that adds `bin/` to your path, or do you need to write a script for this task that saves you from having to type both `bin/` and a bunch of other command-line flags?

(I do add my virtualenv's `bin/` directory to my path, but mainly so my editor can find the right tools, so I do it from elisp instead of bin/activate in a shell)