I assume the larger portion of what's "untenable" is "short commutes"; spending multiple hours of unpaid personal time in a car per day just driving to and from work so that you can have the place you sleep be affordable is a huge downside of a lot of in-person jobs that used to be taken as more of a default pre-pandemic, before so many places showed "yeah we could let you work from home but we just don't want to".
The downsides of an open floor plan can be at least partially countered by headphones, but there's much less that you can do on an individual level to make up for having that much of your personal time locked up in pure transit.
For me personally, 90% of it boils down to "unix baseline". I do most of my development work remotely on linux servers of varying flavors, but OSX + homebrew means that I can pretty easily use the tools I write for one machine on my local systems as well.
Beyond that, I've just got a lot of random applications for streamlining my workflow and day-to-day usage that would take a long time to find equivalent tools for, and I'm long past the days when "spending a weekend fucking with settings" was something I want to do. OSX, I just back up my machines and if/when I need to replace them, it's just "plug the new one into the backup drive, restore from backup".
Maybe someday the year of the linux desktop will actually happen, but I'm not holding my breath either.
Yes, I keep running into this. I leave trailing commas in my JSON as it evals fine in Python. Then my C++ code, using boost::property_tree chokes on it. property_tree also needs double quotes, not the single quotes in this example.
I use it for just about everything work-related, but given that my day job is literally "connect to sets of remote servers and bang out code" it'd be insane not to. Some of my coworkers still use screen, but tmux + wemux having the automatic "scale to the smallest attached screen" + "automatically follow the driver in pair mode" means there's a lot less "can you shrink your window"/"which window are you in now?" types of interruptions.
Apart from that, I've got a perpetual tmux running on my linode for irssi, and I've also got tmux running locally-- being able to set up multiple sessions connected to the same tmux server means that I can have a different tmux session per physical monitor, which means both a shared tmux copy/paste buffer and the ability to easily flip from window to window depending on what I want on which monitor. Ctrl+B for the local tmux, Ctrl+A for remote tmux means that there's no weird double-control-characters necessary. Add in some sneaky scripts to symlink login SSH agents to a known location that's exported to all tmux sessions for ease of git and you end up with a really clean overall workflow.
Honestly, I think that we're already moving that direction-- Patreon is comparatively recent, but more and more people are finding that it's actually a viable "microtransaction/subscription" model for online content. The idea of paying a subscription model for some of the things on Patreon would have seemed silly a couple years ago, but I think we're starting to hit the ads-to-content noise/ratio level where people are actually seeing what the alternative looks like.
I started with and loved Mercurial as a DVCS, and it still has some QoL commands that Git requires some hoop-jumping to get at, but ultimately the deciding factor was the inability to permanently delete branches. Since branched dev work would fairly regularly have generic names or the names of the developer working on it, it would always end up being forked and merged instead of branched and merged, which led to a ridiculous number of headaches in our build system.
We still use mercurial for most of our repositories just because they're dated and not likely to see more than a handful of commits a year, but most of our active development work has already converted to git.
Well, IMHO, nowadays this classifies as bad design. It may have been the better design, but currently git's nomenclature is the standard and not complying to it will only hurt mercurial.
Mercurial and git were initially released within a couple of weeks of each other. To change terminology now would break ten years of backward compatibility.
I used bookmarks back when I used Hg, which is a couple of years ago, but I had some problems with them. From time to time bookmarks wouldn't update remotely. This made me always push twice, to make sure the bookmark was updated. They've hopefully fixed that now, but it was one of my main gripes with Hg. That, and that the Jira version we switched to didn't support bookmarks.
Not sure what the difference between "forked and merged" and "branched and merged" is. You can use rebase/histedit to delete branches in mercurial if you want to.
If they have that much trouble taking the flags off of people's accounts, it wouldn't surprise me to find out that there's no codified correlation between "has the AP running" flag and the "is running a Comcast router+modem" flag.
I set up service with my own equipment from the start, and after all the account setup I received a dozen notices that all these wifi points were available. It was never specified as a "must have a Comcast router" condition.
I find it interesting that you say that, because my first thought was that this would be a step down from git pulling my dotfiles. All you need is to have a simple script that goes ln -s .zshrc ../.zshrc in your .dotfiles repo and getting a new shell up and running is as simple as running git pull && .dotfiles/setup.sh.
I like the idea of this in theory if you have machines that are frequently touched/overwritten, though, if you just want to have a baseline of sanity on them automatically when you log in.
The downsides of an open floor plan can be at least partially countered by headphones, but there's much less that you can do on an individual level to make up for having that much of your personal time locked up in pure transit.