1,121 karma · joined July 5, 2017
What features from iTerm make you love it so much?
And iTerm won't have a way to restore them, right? The `tmux resurrect` plugin can save and restore all your sessions, even after restarts. At the moment I have 45 tmux sessions running and I'm not worried in the slightest about not being able to pick up exactly where I was for every project.
Also, tmux is a nice way to "bury" your "windows." Hiding an iTerm window can only be done by covering something with it or minimizing it, but a tmux session can be detached from/attached to at will, and when you're detached it doesn't add cruft to your window management.
I used to be hardcore "use Google services for everything," and while I still use a lot of them, I'm gradually replacing them with more disparate and often self-hosted options. I supposed I lose out on a lot of that integration, but personally I've found that I kinda just don't need it. The integration offered by living in an "ecosystem" has always been a kind of vague promise, defined more by what it potentially enables rather than what it actually delivers. At the end of the day, how much integration do I really need between my docs and my emails?
Even business use-cases for this stuff still require a lot of "going to the bazar," whether it's in the form of employees writing bespoke code, paying for another company like Zapier to actually do the heavy lifting for you, etc. This of course is the raison d'etre of LLMs in the workplace -- offering a comfortable interface, natural language, for making use of all this data and finally real-izing the mostly wasted potential for integration we've been living with for the last decade or so. It's "no code" on steroids, but IMO like most "no code" solutions, it too will fall short, promise too little juice for too much squeeze, and "the bazaar" will continue to live on.
Every time I write it, I find myself wanting a language with just a few more batteries included.
Underlying all of these discussions is an attempt to reduce issues of portability to 0. It's a good goal, but IMO interpreted languages will by-definition never be the solution.
I've started reaching for Go in situations in which I'd usually reach for Bash or Python, and it's a godsend, because I can control for portability at compile time. If you make compiling for various GOOS and GOARCH targets the norm, portability is never an issue again.
I have a big beefy TrueNAS machine at home and run various Linux VMs for dev work, accessed via Tailscale; mosh-ing or ssh-ing in via Blink Shell is pretty much flawless. I can even institute my "Cmd = tmux prefix" trick that I do in iTerm (via mapping hex codes), so for me it's essentially the same dev workflow as my M1 MacBook Air, albeit with a worse keyboard and a smaller screen, but with the added benefit of LTE, which IMO is a fair trade off until we (Tim Apple, please) get LTE on the Mac lineup (not holding my breath).
The only thing I've been finding myself wanting is a larger screen and a better keyboard, and the 13-inch could potentially deliver both. It's a pretty appealing device.
That said, I of course wish that Apple would just let me treat it like a real computer and not have to connect to Linux VMs to get any work done, but hey, it's still a nice experience if it lines up with your workflow.
Also, this really isn't a problem -- just blast out of the old venv, make a new one with a new version, and you're good.
Also, the issues the article you link are things that damn near every programmer will eventually need to know. Things like PATH are IMO the basics -- if you don't understand this or how to `$packageManager install` something, you're gonna have a rough time programming in general, regardless of language.
Excellent point. This is a large part of why I don't agree with iMessage "exclusion" somehow rising to the level of antitrust.
iMessage doesn't make Android texting worse, it just reveals how bad it already is.
Whether or not the tech can actually live up to the hype doesn't mean execs/VCs/etc won't try to get there anyway. That will, at best, result in a ton of volatility, as those trying to utilize AI figure out that it actually can't do what they want, and then have to hire engineers again, etc...
I don't know. Who knows where this is heading.
I'm quite wary of the long-term implications and downstream effects of that occurring at scale. AI is typically presented as "the human's hands are still on the wheel," but in reality I think we're handing the wheel over to the AI -- after all, what else would the endgame be? By definition, the more it can do without requiring human intervention, the "better" it is. Even if replacing people isn't the intention, I fail to see how any other effect could usurp that.
Assuming AI keeps developing as it has been, where will we be in 20 years? 50? Will anyone actually have the knowledge to evaluate the code it produces? Will it even matter?
Perhaps it's because Dune is in the air, but I'm really feeling the whole "in a time of increased technology, human capabilities matter more than ever" thing it portrays.
On the other hand, I shudder to think of the millions of man hours required to arrive at this solution, when simple UI guidelines, or better yet, an API, would have solved my problem far more simply and efficiently.
Can you share a link? Very curious to read.
They quite literally are not. Autoimmune diseases are, by definition, when the immune system targets the body. Allergies are when your body flags things that are not your body.