Temporal can also run on Cassandra, which scales much larger than Postgres (if you put in enough effort). It can also be replicated across regions for high availability. It's already running some pretty huge use cases.
You're looking at the docs for "visibility". Visibility is a separate eventually-consistent data store off to the side that's used for certain queries so it can be scaled independently of the main data store, and indexed in fancier ways. The main data store for all the stateful and transactional stuff has always, and probably will always, support Cassandra. For visibility, the recommendation for high scalability is currently Elasticsearch.
Temporal may have properties that make it not a good fit for a particular use case, but scalability is really not one.
I'm also using NixOS and working on Go projects, and had to deal with out-of-date Go releases. Nixpkgs generally does get the latest Go versions pretty quickly, but only in the unstable channels, they're not backported to NixOS releases. You can just grab that one package out of nixpkgs-unstable or nixos-unstable, like:
It wasn't quite immediately, it would take a few hours to detect+revert. And that was only the root fs, there were other places to hide things if you really wanted. But then there were other detection systems too. (Probably fairly different now, I left in '11 too)
The idea that the capabilities of LLMs might not exceed humans by that much isn't that crazy: the ground truth they're trained on is still human-written text. Of course there are techniques to try to go past that but it's not clear how it will work yet.
> The idea that the capabilities of LLMs might not exceed humans by that much isn't that crazy: the ground truth they're trained on is still human-written text.
This is a non sequitur.
Even if the premise were meaningful (they're trained on human-written text), humans themselves aren't "trained on human-written texts", so the two things aren't comparable. If they aren't comparable, I'm not sure why the fact that they are trained on "human-written texts" is a limiting factor. Perhaps because they are trained on those instead of what human babies are trained on, that might make them more intelligent, not less. Humans end up the lesser intelligence because they are trained less perfectly on "human-written texts".
Besides which, no one with any sense is expecting that even the most advanced LLM possible becomes an AGI by itself, but only when coupled with some other mechanism that is either at this point uninvented or invented-but-currently-overlooked. In such a scenario, the LLM's most likely utility is in communicating with humans (to manipulate, if we're talking about a malevolent one).
Get a fresh cap! The caps only last about a year of heavy use. You can find replacements on amazon and elsewhere. It doesn't even matter if it's really oem, a fresh third party one will still be much better than a worn oem one.
That's not "a huge number of packages", that's just the 1500 from the minimal installation. nixpkgs has over 80000. And amusingly enough, Nix itself is one of the (two) non-reproducible packages from the minimal install.
That’s great! This is only testing about 2% of the packages in Nixpkgs, but I bet if you weighted by package use that number would look a lot more impressive. Good work, maintainers!
But I stand by: this is the product of a lot of hard work by dedicated people working towards perfect reproducibility and not (as I thought the original article implied) something that Nix gives you for free.
> I just want to list what I want and let the tooling make it happen.
That's just what Nix does?
It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.
The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix.
I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image).
Configuring with a program vs using a plain structured file have different trade-offs.
Does anyone write k8s manifests in raw yaml? They're so complicated that they're generated using some templating language (helm or kustomize or whatever is popular these days, I'm a little out of the loop). So you still have something programmatic. Think of Nix as just a better and more principled templating language. (I mean, look at NixOS configs: they're much closer to "plain structured files" than "programs".)
The promise that I see (I haven't seen this fully realized but it should be possible) is that instead of yaml plus some ad-hoc templating language plus dockerfile plus makefile, everything is in a single language top to bottom.
The Fastmail UI is indeed snappy, except when it suddenly decides it has to reload the page, which seems to be multiple times a day these days (and always when I need to search for a specific email). Can you make it do what one of my other favorite apps does: when there's a new version available, make a small pop up with a reload button, but don't force a reload (until maybe weeks later)?
(I work at Temporal)