> It's a trick I learned from pg for keeping the focus on content rather than personalities.
IMO none of us would’ve bothered reading this if it were just some random person’s commencement address. I personally would’ve been bummed if I skipped this post just because I didn’t find the nonsense title (nonsense unless you read the article) interesting enough.
A number of people would likely have recognised the title and publication date and inferred authorship. The piece is well-known.
I don't fully agree with HN's views on authorship. It's often inferrable through domain names (which serve as something of an authorship proxy, and are often weighted internally to HN's ranking algorithm). I'd much prefer there was more metadata on articles, and remember Slashdot's practice of providing a brief summary blurb with some fondness. (Slashdot itself is sadly largely irrelevant, at least for discussion. As an article aggregator it has ... some uses.)
Also included in his memoirs starting with “Surely you must be joking, Mr Feynman!”, well worth reading if you can get over the occasional sexist bits.
I’m sure I’m not the first to point out that Junio (the appointed git “shepherd”) works at Google where mercurial is the “recommend local vcs” internally instead of git.
The `tmux -CC` is pretty dope. I’m still surprised that not more terminals have picked it up yet.
Most GUI features (new tab, new split, scroll, search, copy/paste, etc.) just work, and it all syncs with `tmux`.
Be aware though that it can be a bit buggy if you have a fancy `tmux.conf`, and that if you rely on any `tmux` plugins then most of those simply won’t work.
What benefit would you get if tmux itself became a control mode client?
You'd get pretty much same experience, with textual splits, modeful keyboard shortcuts to access scrollback & copy/paste etc. — which I'm not saying is bad but tmux already does that. Well, I suppose over ssh it'd allow you to access remote tmux session(s) from a local tmux, so maybe allowing little more flexibility mixing panes from multiple remote hosts(?) But still pretty much similar.
The whole point of control protocol was to allow native [G]UI where each pane feels like a native standalone terminal, no?
1. Ability to use local tmux configuration for tmux sessions over ssh. So I don't have to worry about using the default bindings when connecting to a host that doesn't have my tmux config, mouse support is already enabled, etc.
2. Ability to combine and organize remote panes alongside local panes, or panes from other remotes
3. Avoid ending up with nested tmux, where I have a remote tmux session inside of a pane of a local tmux session, which is a pretty terrible experience.
I'd also love it if linux terminals supported it too, but that doesn't seem terribly likely to happen anytime soon.
I looked into this at one point. IIRC it turns out control mode was only added to tmux by the iterm2 dev, for use in his own project. So I guess he didn't care about adding support to tmux itself.
On that front: I've been using wezterm which includes a built-in tmux+mosh functionality, and it works quite well. It gives you first-class scroll/copy/paste management and multi-windows, plus session re-attachment. Probably 50% of my use of my mac is just SSHing in to my Linux box, and wezterm works great for that.
Last I tried there’s 2 major limitations, one is that the version on both ends has to be compatible, another is that it seems the wezterm at the host must be available in the system default PATH. This makes it hard to adapt to arbitrary remote systems that you have limited control of. Tmux+mosh doesn’t have these limitations (well I’m sure the mosh client and server must be compatible to each other but given it is so stable that the last 2 updates are 5 years apart there won’t practically be any problems).
Yes, the versions between client and server do need to be in lock-step. As far as needing to be in the system default path, I haven't run into that: when I initially started using it, I had dropped the executable into ~/bin and that seemed to work (that is in my shell path).
It depends how the rc files are initialized though. I remember last I check I couldn’t get it work on one system (that I don’t have control over those in /etc and those set in my home is not initialized at that stage.)
Mosh implemented a flag to include in the client side: —server=… which solves this problem.
The last time I used it, which was probably pushing 5 years ago, it was a big drain on the battery. It was enough that I went back to Terminal.app. Anyone else experience that? Has it improved?
"All things being equal" is doing the heavy lifting there. All things are no longer equal though, which is the point. The time/effort to produce art has effectively become zero.
> The time/effort to produce art has effectively become zero.
But not so the effort needed to produce "unique art".
When everybody can push a button to produce "art"
then how do you make the results of your button-pushing unique?
The value of art is in its uniqueness, and originality.
Using AI to generate art based on input training models is not that different from photography. Each generated art-piece is like a photograph taken from different viewpoint. And when everybody can use the same programs to generate their "art" the results are bound to be more or less non-unique, non-original.
The scary part for artists may be that now programmers can create new original generated works of art. You can be an artist without knowing how to draw.
Then again we could have a conventional artist with a unique style who would train an AI model to only generate versions of their existing paintings. Laws may need to be adapted to make it illegal to generate art based on someone else's existing art. Lawsuits will follow.
The effort required to produce 1 particular "bored ape" or any of their many many knock-offs tended to zero. They were technically unique, sure, both by url and by content. But also mass-produced, low-effort, cookie-cutter variations, cheap and ugly. As to the last, "ugly" - without getting into "But is it art?" - if it is; it's really bad art.
Ceteris Paribus (all things being equal) is one of the economist's favorite phrases, along with 'on the other hand'. And to be fair, it's hard to predict how a change will affect things if everything else changes as well. It is a huge assumption though.
It blows my mind how much RenTech does with some ~300 employees. I recently had a phone screen with them (no offer otherwise I wouldn’t be writing this) and all of my communication was with this MIT math PhD. No HR, just the PhD.
Compare them with a Big N that has 10,000s of SWE’s. It’s a safe assumption that each engineer is individually less talented but even so, how do they iterate/experiment with such few employees?
What kinds of questions were asked during the interview process? I don't think I'll ever have the chance to work there, but I'm extremely curious about the vetting process for a place with such a notorious hiring bar.
