It also breaks all the "legacy" far more secure extensions (which do all the sensitive bits in the local native app) in favor of the godawful new extensions that load your entire fucking vault into the browser's memory and do all the cryptography in JavaScript.
I see that #1Password 8 came out today. It may look pretty, but moving to Electron more than doubled the memory usage (149.6MB to 362.9MB) and made a bunch of controls weirdly non-native. Really disappointed in Agilebits, which historically was one of the best Mac-first software firms.
uspol, scotus
Does this #SCOTUS draft ruling also kill Lawrence v Texas?
So we all understand that the "pay remote employees the same salary everywhere" thing is going to lead to massive universal salary cuts for software engineers after a couple of years and even us getting priced out of SF/NYC/etc, right?
"Great pay" for rural middle America is poverty wages to anyone who wants to live in a developed urban area in the US...
Upgraded one of my personal machines to #debian bullseye today. This machine started out life running squeeze and has basically never had a major problem across 12 years of updates. All it runs is bind9, courier-imapd, postfix, apache, wireguard, and znc, but still, you gotta hand it to the Debian team for having amazing upgrade processes.
There's got to be a better way to do a #soc2 audit than taking literally thousands of screenshots and sending them to the auditor. I refuse to believe that when, say, Google gets audited every year they upload screenshots of every in-scope tool's authentication settings.
My alma mater (#HarveyMuddCollege) canceled alumni weekend because something like 17% of the student body is currently quarantined because of positive #COVID tests, if anyone was wondering how that's going
So as far as I can tell, the "easiest" supported way on #systemd to inspect another user's systemd jobs is to start a new session with `sudo machinectl $USERNAME@` and then use `systemctl --user` there; there seems to be no way to get `pam_systemd` work through sudo or any similar mechanism (without messing around with undocumented internals like $XDG_RUNTIME_DIR).
Is it that weird for a sysadmin to want to see services and jobs running as different users? This seems like a basic, day 1 requirement.
I'm sure this is great for all 7 people running Linux on the desktop but it makes it *so much harder* to actually run services on a server than sysvinit.
Argh fucking #systemd; user sessions seem to be totally useless. Oh, you want to have a non-privileged user able to manage services? Well, you can't use `systemctl --user` unless you want to literally log in as the privsep user, because `pam_systemd` doesn't work with `sudo` or `su`.
Maybe instead you want to use polkit to simply allow the user to interact with the system instance for some units? Too bad, because there are 0 lookup props exposed to polkit for the relevant action, so you can't do that.
Does anyone know the rationale for why Requires=foo in #systemd unit files doesn't imply After=foo?
I wrote up some observations on the new California digital vaccine record, in case anyone was curious exactly how they worked: https://www.roguelazer.com/2021/06/cdph-digital-vaccine-record/