pseudonym

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.

It's also slightly stricter with syntax; you can't have extra ending commas. {'foo' : 1, 'bar' : 2,} is valid Python but not valid json.

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.

Doesn't help in this situation-- you need to be able to install the base executable for the browser extensions to function.

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.

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.

>Malicious or Stupid?

Funny, for a second I couldn't tell if this was about Glassdoor itself or the people who browse it from work.

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.

Is it still a social engineering hack if a well-known celebrity with their personal info broadcasted all over the internet decides to use that personal info to secure their account? Or rather, is that a social engineering hack on Apple, or the celebrity themselves?

And what should Apple do, in this situation? If your names show up in tabloids, don't allow you to answer certain security questions? Require 2FA if your name is mentioned on Google more than a certain number of times?

I don't feel this is an Apple problem any more than it would be if someone created their iCloud password and then posted it on their Twitter.

While I wouldn't disagree with the stupidity of "security questions" answered straight, I don't know if this is something to lay on Apple's doorstep, because anyone with a modicum of knowledge either lies or supplies "custom" security questions-- it's basically a "if you forget password A, remember password B" system. But explaining that to users who have issues with a password is a lot more far-reaching and widespread than any one company.

Additionally, making "security questions" passwords in and of themselves is going to tremendously increase the volume of your support tickets. At some point, you need to make a cost/benefit analysis and make a decision including that, not just looking at "what's more secure if we assume our users are stupid".

If you really want a niche market, though, "social media security consultant" for celebrities would probably make you a pretty penny nowadays...

>But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves.

While true, it just seems (to me) that if that's the only problem you're solving (which is to say, not needing to type the command "ssh host" and let your key log you in) and it's at the expense of not being able to properly ForwardAgent (which I require very heavily in my line of work), then it's a lot of work for negative return.

But, again, to each their own. As mentioned below, if your latency over a phone connection is so bad that this helps you, then by all means, use it. :) I'm just noting that for pretty much everyone I work with, this would be a step backwards.

You only make the initial instantiation once.

- SSH to remote

- on remote, run "screen"

- get disconnected from remote

- SSH to remote, .bashrc runs "screen -DR" and you resume from where you left off

You only have to create the initial screen session once, and it persists until you explicitly shut it down or restart the remote machine.

If your workflow doesn't include tmux or screen, then I feel like your problem's already been answered. If you really wanted to, you could just add a "/bin/screen -DR; exit" to your remote .bashrc and the screen integration would be completely invisible after the initial instantiation.

As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).