ethanpailes

AlphaStar was absolutely dominant. I don’t know if it played exhibition matches after it got its view restricted, but surely it still performed at a very high level. The APM restriction they put on is actually a handicap in favor of the human since humans are allowed to have 2k APM, just incapable of doing so.

If you just mean general LLMs can’t beat humans yet that’s one thing, but it’s not the case that no system can do so.

A lot of the reason Chinese goods are cheap has to do with their technical competence, low labor costs and a streamlined industrial system, but they also use a lot of subsidies, currency manipulation and forced investment so you can’t really say that just letting in Chinese goods is in accordance with free market principles without considering their domestic situation.

In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.

Server costs actually matter quite a bit at the scales of the incumbents in this space. Also, speed can be an important part of UX. Scaling horizontally won’t help if the engine itself is slow enough that there is noticeable lag even with just a single document getting edited by a dozen people.

> I do like being able to use X over the nextwork but that is a problem that can be solved.

And in fact has been: https://github.com/wayland-transpositor/wprs

I will absolutely eat a whole bag of oranges in a sitting.

Sperm whales arguably farm by always dedicating at the top of the water column and measurably increasing the fertility of the seas they swim in. It seems possible that is deliberate given how much of their time they spend in the depths.

China turning the corner on emissions has far more to do with their desire to get out from under the possibility of an oil blockade locking up their economy than green pressure from the west. They also organically have an environmental movement, though not one that they are willing to kowtow to at the cost of growth.

TPUs do give Google a unique structural advantage on inference cost though.

Since the financial crisis the US economy has kept on trucking, while the EU has stagnated. This isn’t all because of the euro, but it’s definitely a disaster and I think it is reasonable to hold the euro at least partially responsible.

Since the pandemic, enforcement of traffic laws has fallen off a cliff, with a corresponding increase in traffic deaths. That is the result of a specific policy choice. Women who get pregnant experience potentially fatal complications somewhat randomly, just like victims of driving accidents are killed somewhat randomly. You probably can’t eliminate either category of death entirely with policy, but it is clear that there are policy levers that could reduce deaths in both categories. They actually seem almost exactly equivalent.

Yeah reconnecting from different terminals is a pretty tricky problem to solve (and in fact can't be solved in general because of potential skew between the terminfo db on the client machine and the remote machine). The big problem is that once you launch a shell, there is no great way to change environment variables from outside that shell, so you can't change the value of TERM for a running shell. I have thought about trying some LD_PRELOAD tricks to try to be able to call setenv() from within the shell process itself, but this always struck me as something that would require a pretty big hack.

Yeah I was expecting a lot of that, which is why I found that survey data so surprising.

Not trying to be a window manager is pretty much the reason it exists!

If you’re using a tiling window manager your window switch keybindings necessarily conflict between the manager and tmux, since if you configure the same one and then press it while focused on a tmux window, the tiling window manager will override tmux and claim the event.

Scrollback and copy paste cannot always be configured as you want. I’ve shared some specifics elsewhere in this thread.

Well potentially some, but definitely not tiling and screen splitting.

You can definitely use it in production, it is deployed internally at Google and we have a bunch of users. It doesn’t currently work on MacOS, but one of my colleagues is currently working on a port to Mac.

Oh, thanks for catching this. I'll clean it up https://github.com/shell-pool/shpool/pull/43

It's definitely not a complete alternative, but a surprising number of tmux users are only in it for the session persistence. We did a little internal (criminally underpowered and confounded) survey of some tmux users at google and found that half of them were only really using it for session persistence. I was really surprised by this and thought more people would be using all the slick tiling features that tmux has.

You definitely don't need the in-memory terminal emulator to handle resizes or allow attaching with multiple local terminal emulators, since dtach does both and does not have an in-memory terminal emulator.

> I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it

Well, we kinda cheated here. shpool_vt100 is just the already existing vt100 crate with a single critical bug fixed, so it actually wasn't much work :). Turns out having a nice package manager for a systems language comes with some benefits.

I'm actually open to adding a feature to allow multiple simultaneous connections to a single session. I never really had a usecase for it personally so I haven't prioritized it, but it is something that similar tools support and people keep bringing up. Since this isn't the first time I've heard people talking about it, I just made https://github.com/shell-pool/shpool/issues/40 to track work adding the ability to attach multiple clients to the same session.

> This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.

I'm not aware of any tool that does internal rendering and subsetting handling scrollback and copy-paste in a way that I personally find usable, so these decisions were very much intentional.

I think tmux is a great tool for a lot of people, and I tried to get into it for years, but I could just never get over the weird scrollback and copy-paste issues or the fact that it meant that I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session. If tmux works for someone, I think that's great and they should keep using it. shpool is meant for people like me who aren't very good with computers :).

tmux does support scrolling and copy-paste, but they often work subtly differently than the way they do in a native terminal. For example, when I try putting `set -g mouse on` in `~/.tmux.conf`, scrolling mostly works fine but if I scroll up and then start typing or press up, I won't jump right to the bottom of the session the way I'm used to in native Alacritty (which I will often do as a way to return after scrolling back through a bunch of print output). This isn't a huge deal, and you can definitely get used to it, but it can be frustrating if you like how your normal terminal emulator works and don't want it to change.

Oh thanks for mentioning EternalTerminal. I should add it to the comparison section in the README. It looks like it is similar to mosh in that it does stuff at the network level whereas all these other tools are purely remote-machine side programs, but it seems like it is a bit simpler than mosh. From a scan of their docs it sounds like they have the local terminal do all the rendering the way `shpool` does and don't try to muck about with any sort of predictive rendering the way mosh does. Does that sound right to anyone knows it well?

Yeah that's a good point, "lightweight" was probably not the best term. I meant lightweight in terms of the cognitive overhead of picking up a new tool, not really in terms of performance. I would expect that shpool will perform better on some workloads and tmux will perform better on others (though in both cases they are probably good enough).

The main difference is that tmux is a power user tool that you generally invest in configuring and tweaking to get just right, while shpool is meant to be set up quickly to solve the specific problem of dropped connections and then mostly forgotten about.

Screen is discussed along with tmux in the [comparison section](https://github.com/shell-pool/shpool#tmux-and-gnu-screen) of the README. For most of the section I just say `tmux` because saying `tmux` or `screen` can get annoying and they have a very similar set of features.

If the national review doesn’t count as the usual crowd, I don't know who does.

https://www.nationalreview.com/corner/the-scottish-governmen...

> more complicated design/brainstorming has been slower

Could you say a little more about why you feel this to be the case? I haven't noticed much slowdown at all.

Oh, another issue worth mentioning specifically when you are using the jackc/pgx driver is that pgx maintains a prepared statement cache under the hood for performance reasons, but the statements in the cache can be invalidated by query migrations. So if you do `SELECT * FROM foos WHERE field = $1` and then run `ALTER TABLE foos DROP COLUMN bar`, the next time you run that query you will get an error. This used to just be broken until you restarted the process to clear the cache, but I've patched pgx to make it invalidate the cached prepared statement when it sees one of these errors (it still returns the error though since jackc thought a retry would be too complicated). I added an automatic retry to opendoor/pggen to make it so users don't need to worry about this kind of low level detail. You may want to consider that for sqlc as well. The other option is to advise users to disable the cache by setting it's size to zero (I forget the exact config option, but jackc said there is one when I first brought up the issue).

Thanks for the correction! When I read the generated code, I just focused on the scan call. Since pggen doesn't parse the SQL, there is no great way to detect `SELECT ` and rewrite the query, so I hadn't considered this as a possibility. Parsing the SQL really opens up a lot of cool possibilities for you.

You already know this but in case anyone else is reading, another super cool thing that sqlc can do is infer good names for query arguments in go code by looking at what they are compared to in the SQL code. Thus for a query like `SELECT FROM foos WHERE created_at > $1`, the generated go wrapper would have a `createdAt` arg instead of having it be named something like `arg1`. Since opendoor/pggen doesn't parse the SQL, you need to explicitly override the argument names if you want to provide better names. Of course the names won't be perfect with sqlc's approach, but they will be better than `arg1` and it's still a very cool detail. It might not be obvious how neat this is if you haven't had to implement it, which is why I mention it.

If you want a code generator like this that has support for that kind of thing, https://github.com/opendoor/pggen can automatically infer these kinds of relationships based on foreign key relationships and emit slices of pointers to connect the records together in memory. It can even figure out 1-1 relationships if there is a UNIQUE index on the foreign key. There is a little mini-DSL for specifying exactly how much of the transitive closure of a given record you want to get filled in for you.