Last time I was in a role which involved on-call rotation:
> expected duties (only answer on-call, do other work, etc)
Only answer pages. My employer did shifts a bit differently from most companies - only six hours per shift, no fixed schedule (decided a week in advance) and only outside of work hours (pages during work hours were handled by whichever sysadmins were on duty), which worked quite well to avoid burning out sysadmins. On-call shifts were paid, and shortages of volunteers were rare.
I'd expect to spend maybe fifteen minutes per shift fixing things, on average (this is in managed hosting, so a page could be any of our customers' services).
> how deep does your on-call dive into code to fix, vs triaging, patching, and creating follow up work to fix permanently?
In my case (sysadmin for a managed hosting company) the code involved was often not under our control; the standard practice was to escalate to the customer if the cause of the outage was a bug in the application. The usual process when suspecting a bug was to track it down if possible (the codebases were usually unfamiliar, so this wasn't always the case), work around it as best we could (e.g., temporarily disable a buggy search indexer which was leaking memory, et cetera), and then get in touch with the customer (by email if the workaround was expected to last until work hours, by phone if not). Occasionally I'd fix the bug in-place and send the customer the patch, but this was technically outside scope.
> priority order of work (on-call tickts vs regular work vs existing on-call tickets vs special queue of simple tasks)
The only priorities were resolving the pages at hand and arranging followup where needed (usually raising a ticket to be followed up during work hours).
> what happens when the current on-call can't complete in time?
Generally the on-call sysadmin would resolve whichever pages they had acknowledged; in the event of an extended outage the acking sysadmin was expected to brief and hand over to the person on the next shift.
> how do you manage for other teams' risk? (ie their api goes down, you can't satisfy your customers)
In practice, we could escalate to anyone in the company for a serious outage we were unable to handle ourselves. This was pretty rare, as a small ops-heavy company, but everyone had access to everyone else's cell phone number and an outage-inducing bug was usually sufficient cause to wake someone up if it couldn't be worked around.
I've run barebones hypervisors in production for years; KVM is head and shoulders above everything else I've tried. libvirt and virsh provide a reasonably nice interface if you don't need web-based tooling, and of course config management makes everything a lot easier to maintain. I haven't used salt, but if it has mature tooling for what you need, KVM would be a no-brainer for me.
Loading this webpage I downloaded ~12KB. For comparison, I went to the NYT homepage and downloaded ~1.2 MB. For people with shitty downlinks like you and I, the absence of exorbitant quantities of Javascript and images makes a lot of difference - a lot more than time-to-first-byte.
I didn't realize this was ever in question - of course you can't trust Tor exit nodes not to snoop on your traffic. You can't trust your ISP or friendly local intelligence agency not to snoop on your traffic either; this is why end-to-end authentication and encryption is a useful thing. (Not meant as a criticism of Chloe's research, it's certainly valuable data).
The modern use of the word was spawned by a book by Thích Nhất Hạnh[0] called The Miracle of Mindfulness. It was then codified into clinical practice by (among others) Marsha Linehan, who incorporated the book's ideas (in combination with behavioural therapy) as dialectical behavioural therapy, which was the first evidence-based treatment for borderline personality disorder[1]. Since then it's been a prominent feature of popular psychology (and real psychology, though in a more restricted context).
It always seems odd to me that every time someone makes a post about the benefits they experienced from going sober, a bunch of people feel the need to defend their own drinking habits out of the blue (even though no-one is attacking them). Congratulations on a sober year, OP.
I'm not sure I'd refer to psychostimulants as nootropics, although I'm aware many people do. The neurological tradeoffs involved in catecholamine reuptake inhibition are relatively well-known and uncontroversial; to me, much more interesting are the implications of long-term racetam use. History (and homostasis) seems to indicate that there are probably tradeoffs involved, and the fact that we have no idea what they are makes me more than a little nervous.
What? I must say, this is the first I've heard of this trend. Personally, I might be a little querulous when interviewing a dev who used Windows by preference (though this would be irrelevant once they'd demonstrated or failed to demonstrate technical skill), but I've never worked with a hiring manager who'd discount a web dev who used a Linux-based operating system.
This is uninformed, dangerous and wrong. Author should go back to school or crack open a first-year-med physiology textbook and learn how metabolism works. The article isn't even internally consistent.
This is laughable from a privacy perspective. So you delete the emails immediately after they're viewed? We're expected to take your word for this? Are you saying you don't back up your data at all? How do you handle secure removal from backups? How do you perform the deletion? Do your servers use journalling filesystems? Do you expect us to trust (say) Gmail not to prefetch image data embedded in HTML emails? What happens if you get raided?
Internal XMPP. Poor ejabberd isn't handling our growth in traffic very well and gets oomkilled and/or swaps itself to death with depressing regularity, so we're trying prosody (over the protests of the internal-IRC faction).
You are absolutely correct. You can also type `who` for a list of users who are currently logged in. You can even `cat /etc/passwd` for uids and home directories. That's how UNIX security works (not via obscurity). If your password's not strong enough to resist a bruteforce, change it and/or get a VPS (which, incidentally, commonly get pwned by Chinese botnets if you insist on using a weak password and don't switch to pubkey-only auth).
Yeah, there's a reason the article doesn't present any actual evidence for its claims. I'm sure that the author believes what he is saying, but no, statistics doesn't work that way. The article should be cut out and stuck in an undergrad psychology textbook under 'confirmation bias'.
[0] https://en.wikipedia.org/wiki/Ear_candling