dnr

I'm not an expert here but I have to say this feels like a very weak objection.

p points to P1. One thread reads through p. Another thread races with that and mutates p to point to P2. The result is the first thread reads from either P1 or P2 (but no other object).

This seems totally fine and expected to me? If there's a data race on a pointer, you might read one or the other values, but not garbage and not out of bounds. I mean, if it could guarantee a panic that's nice, but that's a bonus, not required for safety.

The inelegance to me isn't in the definition of the operation, but that it's doing a huge amount of brute-force work to mix every part of the input with every other part, when the answer really only depends on a tiny fraction of the input. If we somehow "just knew" what parts to look at, we could get the answer much more efficiently.

Of course that doesn't really make any sense at the matrix level. And (from what I understand) techniques like MoE move in that direction. So the criticism doesn't really make sense anymore, except in that brains are still much much more efficient than LLMs so we know that we could do better.

Everything you said "should" is exactly what Nix and NixOS is.

Hey, I sorta did this. Lazy substitution, at least, not lazy build. Plus a bunch of tricks to speed up downloads.

https://github.com/dnr/styx/

Lazy build sounds tricky: you don't know the contents of the package before you build it, so you don't even know what to symlink into /run/current-system/sw. I guess you'd have to have some kind of wrapper. Maybe similar to comma.

I just solved that part by setting up CI for most of my system config (integrated with the above).

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.

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.

(I work at Temporal)

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:

    (import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/nixpkgs-unstable.tar.gz") {}).go_1_21

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.

Oh wow, that just jogged a really old memory. I'm pretty sure I had that one, but can hardly remember anything else. Could it have been Xenocide?

edit: Oh, or maybe Silpheed? This is the closest thing I found with some searching: https://youtu.be/o98xKZk5FOk?t=182

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.

If "two" is acceptable for "many", look at the ODROID-HC4? I made some home NASs out of them.

Actually a huge number of packages in nixpkgs are bit for bit reproducible: https://r13y.com/

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.

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 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)?

Hate to make a boring me-too comment, but I feel the same: I've been using it a bit over a year, and I wish I had started even sooner. Now I've got two laptops and a NUC, plus two odroid-hc4's, all on NixOS. All the system configuration that used to be half-broken ansible and a pile of scripts (plus all the one-off hacks that weren't even captured anywhere) is now nice pure nix configuration. I've nix-ified builds for a bunch of personal projects too.

Yeah, it took a few months to learn, and there are still lots of rough edges, but going back to a non-Nix linux distro would feel like going back to windows. I agree with the sibling comment that it makes me feel happy and giddy, like no other technology I've learned recently.

This is one of those religious arguments where no one will every change their mind, but I feel like a trackpad is the dumbest mouse interface and can't use anything but a trackpoint (or a mouse of course).

Consider dragging and dropping: with a trackpoint you click with your thumb, then use your pointer finger to move the mouse cursor any distance you like, without moving your hand, then release. With a trackpad you press the pad and then move your finger some distance and then... oops, you hit the edge of the pad. Better abort and try again, starting the motion from the opposite pad. Except if I'm on a non-apple trackpad, and I have to click near the top of the pad, it's nearly impossible because the click hinge is near the top. Or maybe I do a finger swap to reset the drag position, and hope that the OS doesn't interpret my moment of two fingers touching as some kind of gesture.

Anyway, it does take some time to get used to, so you won't get it in a few minutes or even a few hours. Try a week. Also make sure you're using a lenovo one (the dell/toshiba ones aren't as good), and very importantly, that you have a fresh cap. Worn out caps make it really frustrating.

Isn't that exactly the point, and why it's so great? It's a single algorithm that's tune-able across that wide range of speed/ratio trade-offs using a single parameter. So you can just use one thing for almost every application instead of picking between three different things.

(Yes, I know that one parameter controls multiple different settings internally, so there are multiple dimensions if you're willing to dig that deep.)

Anyway, my recollection from looking at benchmarks a while ago: zstd used at similar ratios to lzma compresses in similar time but decompresses much faster, and it's also faster than gzip when set to comparable ratios to that. lz4 is still faster than the fastest zstd modes, and lzma at the most extreme settings still gets better ratios that the best zstd can do. But there's a huge wide swath in the middle where zstd beats them all, and that's quite valuable.

No relation to the link, but does anyone else remember these books?

Algebra the Easy Way - https://www.goodreads.com/book/show/6781.Algebra_the_Easy_Wa...

Trigonometry the Easy Way - https://www.goodreads.com/book/show/2077099.Trigonometry_the...

Calculus the Easy Way - https://www.goodreads.com/book/show/3074478-calculus-the-eas...

I read these in 5th grade or so and learned most of middle school and high school math just from those.

They're written as a fantasy novel in which the characters discover the relevant math concepts as part of the story. I know, you're thinking that's a silly gimmick and it can't possibly be any good, but it was actually done quite well. At least until the later parts of Calculus where the situations have to get pretty contrived.

Highly recommended, at least for precocious kids who like math and fantasy novels.

I want to understand what you're saying, but at first glance this is contradictory: housing prices are driven by density, and housing prices are increasing in Ketchum. But Ketchum didn't increase density, and neither did anywhere nearby as far as I can tell. So what is driving the increase there?

I've visited Ketchum and think I have an idea, but I'd like to hear your explanation.

Don't forget supporting small strings (<= 7 bytes) in the pointer itself using tag bits. No allocation or dereferencing required.

I came looking for this comment too. A nice chair helps but the actual fix is to do deadlifts. And squats too. Even just getting up to being able to do 100% of body weight will help a ton.

The trick is: as soon as you notice it drifting, take your finger off it and let it come to a stop. If you keep pushing opposite the drift it'll never stop.

Also, if you haven't in a while, replace your cap. I replace mine every year or so and it makes it perform much better. You don't have to push as hard, which also reduces the drift problem.

Chrome stable 89.0.4389.90 was released on March 12: https://chromereleases.googleblog.com/2021/03/stable-channel...

Version bump in nixpkgs: https://github.com/NixOS/nixpkgs/commit/5f8b95113983c8f31d63... on March 13 (one day later)

Released in nixos-unstable on Mar 16 11:11:22 UTC (four days later)

Backport to 20.09: https://github.com/NixOS/nixpkgs/commit/26ba8cd77b5a4408799f... on March 13 (one day later)

Released in nixos-20.09 on Mar 16 16:31:31 UTC (four days later)

Again, four days is not great for a Chrome zero-day. NixOS doesn't have a professional security team, and if you need that assurance, maybe you can't use it. But please don't exaggerate and muddy the facts.

Most of the delay is due to hydra having to build everything that came in ahead of that change on the master branch, and sometimes the master branch is just broken.... I wish there was a fast-track process that could bump urgent security changes ahead of other ones, but it seems like it could complicate things a lot.

Of course, as I said above, it's relatively easy for you to update your local install without waiting for all that, if you're aware of the release and its severity.

The claim that Chrome was not updated on the unstable branch for weeks is wrong.

The two releases in question are:

88.0.4324.96 on Jan 19: https://chromereleases.googleblog.com/2021/01/stable-channel...

88.0.4324.146 on Feb 2: https://chromereleases.googleblog.com/2021/02/stable-channel...

The commits updating them in nixpkgs are:

https://github.com/NixOS/nixpkgs/commit/5b6d3c4b13e50540d044...

https://github.com/NixOS/nixpkgs/commit/4fe69d33aeb6dac647e4...

The first landed in master on Jan 19 (the same day), the second landed in master on Feb 3 (one day late).

The way nix works, the CI has to build and verify a large chunk of packages before it gets promoted to unstable. So when did they hit nixos-unstable? It's not possible to tell from git alone, but the history of the channel is archived here: https://channels.nix.gsc.io/

I did the search and the first release hit nixos-unstable on Jan 21 18:20:45 (UTC), and the second on Feb 6 08:30:17 (UTC). So around two days and four days.

The backports to nixos-20.09 hit that branch on Jan 26 16:55:17 and Feb 6 13:45:20, so seven days and four days.

I'm not sure what the parent commentor was doing that led to them missing these updates.

To be clear, this is not a great record. I was running nixos-20.09 and I updated my system ahead of the channels (which is fairly easy, not at all difficult as the parent comment implies). But it's not "weeks", and it's not that bad for a volunteer project.

Yes, exactly: https://github.com/NixOS/patchelf

It's a key part of how nix works.

That's wrong. The google-chrome packages in nixpkgs are "built" by downloading the official releases (in .deb format I think) and massaging them a little. It takes a few seconds.

When the zero-days came out, I just updated the upstream-info.json file in my local nixpkgs checkout (look at previous chrome version bump commits for how to do it) and rebuilt my system. I didn't have to wait for any PRs or merges or CI/hydra. Granted, it requires a little nix knowledge, but if you've been running nixos you can probably figure out how to do it in a few minutes.

You're right, condescension is the wrong word. I apologize.

I do think it's misplaced confidence, though. Look at the upvotes/downvotes on the comments in the type-ahead issue thread. What the gnome developers are saying is clearly unpopular, and what the person who filed the issue and others are saying is clearly popular. Yes, of course, that's not a representative sample of all users. But was there ever a representative sample taken? What gives them the confidence to declare that the search behavior is superior, and so far superior that it must completely subsume the old behavior without even an option? No evidence is presented in that thread. They only say "This was a decision made a while ago, because people believed that searching can provide the same functionality." On what evidence is that belief based on, and what would be sufficient to overturn it? How large of a user outcry would there need to be? If this were my software and 59 people thought that one of my decisions was wrong (the largest vote count in that thread), I would start to strongly question my assumptions. No such questioning appears to be happening here.

To respond to your specific replies:

technical review

This is a design question, not a bug. It's not about the code. The complaint is obviously valid.

I don't think it would be much benefit for there to be a setting

Of course, anyone who will keep a setting in one position doesn't see value in there being a setting. I don't either: I'd be even happier if it always worked the old way, instead of a setting. But that's what settings are for, where there's multiple valid ways for something to work and not everyone agrees.

technically viable

The old behavior is obviously technically viable, it worked that way for many years. So again, that's irrelevant, unless you're arguing that a setting to switch the behavior is too technically difficult, which seems implausible.

Once the decision has been firmly made, there's little purpose to accepting further feedback after that.

Of course there is! If you don't accept further feedback, how will you ever know if your decision was wrong? This is the crux of it: a decision was "firmly" made by some developer based on who-knows-what criteria, and then no feedback is accepted, no matter how loud.

losing users

I'm not a gnome user and never will be, but I'm forced to accept these decisions because they affect the gtk file dialogs also, and I can't exactly quit every piece of software that uses gtk.

I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue:

I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.

I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.