Of course normal people stay loggged in.
What’s the objection to two factor with?
Of course normal people stay loggged in.
I’m not normal people, and now every login has an extra layer of faff because github doesn’t get to leave its cookies on my machines while I’m doing other things.
(Yeah yeah hardware security token but that’s just another thing to go wrong…)
You log out of the website, they make you log back in. that seems perfectly reasonable to me. Your complaint is that they make you use authentication that greatly reduces the risk of a bad actor gaining access to the account. (And I will assert, from actual knowledge, that in my employer’s case, this is absolutely true. Two factor, even not-good two factor (sms, I’m looking at you), vastly slices account hijacking. TOTP and fido are even better.)
There are workarounds for you, iike using a dedicated browser for github, a browser container for them, or reinjecting the auth creds back into your browser. Yes, they’re not ideal.
Basically, you’re complaining that security is hard and causes pain? Have you moved to management?
More seriously, I use yubikeys. They’re pretty unobtrusive, and reliable. (our security people are happy with reliability, and we have a lot of them in use, so I tend to think that’s true even for people who are rougher on gear than me.) I leave one in my ork laptop al the time, and another my desktop’s keyboard’s mouse port. (which is in my home office. I wouldn’t leave it all the time if it were in an office.) I get a prompt, I reach over with a pinky and tap it. My personal laptop has a shortage of usb ports, so I don’t leave it plugged in, and end up using totp for stuff. It’s annoying, but I don’t need it 50 times a day, like I do at ork.
I’m complaining that because browsers are built for advertisers and the modern web is a garbage fire, this sort of silly dance needs to be made universal. Now when I log into github it wants a password and TOTP.
When the machine room is hotter than outside and multiple alarms are going off, more has gone wrong than “a ten minute power outage this morning”. (Also your excuse for not letting us keep our rackmount UPS was that your power was utterly reliable.)
Things you don’t want to hear from your testers at 1530 on a Friday:
“Is there a way to restore these complicated tests that I accidentally deleted?”
Followed up from your sysadmin:
“I could roll the database back to this morning, but I can’t guarantee that it will be fast, or that the data won’t be duplicated/deleted”
Hah. I had a cluster die my last o call rotation because the closet the equipment is in over heated. Why did it over heat? Between last summer and this one, the building alarm system got fixed, and they can’t prop the door open.
Our answer would have been “Yes, just look in the .snapshot directory underneath the directory where they were.”
Keeping all your users’ working directories on a snapshotting file system costs money, and keeping all your test data in individual files is not cool and shiny, but the combination makes accidental deletes (which are noticed) no problem at all. We worry about deletes that weren’t noticed, but ones in the test data will mostly be noticed within 24 hours when they cause test failures.
It’s not the test data that they deleted, it’s the test cases and results. It’s manual acceptance testing of bespoke scientific software, so no automated test failures (we have automated tests, but not for UAT). We use a commonly used piece of test management software which is regularly backed up, so nothing is actually gone, it’s just a question of which recovery method has the lowest combination of risk and inconvenience for other teams.
An interaction I had on Twitter yesterday:
Me, responding to Person A: “X is not a feature I’ve seen on commercial 3D-printers.”
Person B: “Then you’ve not looked at (similar features) A, B and C.”
Me: “What printers are those features on?”
Person B: “Oh they’re not commercially available, they’re homebrew.”
I am now writing the incident report for this. We do not have a root cause of “clowns run the building”. I may need to ask for it.
Does PEBCAK count for this thread? I wrote a whole rant and then deleted it, but suffice to say I’ve had a bad time courtesy of someone at work, and right now I’m greatly appreciating the way my cat is purring at me. (Less appreciative of the claw marks he just left getting down from my shoulders, but it’s still a net win.)
I scheduled a recurring block for the last few hours of Friday afternoon, to keep nimwit program managers from scheduling last minute friday afternoon meetings on me (which has happened the last three weeks…). I was deep in the python mines, and my calendar interrupted me to tell me I had a focus block coming up.
Yes, I have edited rthe series not to have a reminder…
So programmers don’t have “read-only Fridays” like network guys do?
We don’t, though there’s a “land? After 1 pm on friday?” click through if you push your changes. But even if there were,most of my work takes hours to write, over the course of days or a week or more. (I did some time tracking earlier this year. Half of my landed diffs took < 10 minutes, the other half average 12 hours of actual work.)
I wish we had “no hot-fix Friday”…
On Friday, I had some changes for the build system. Negotiating with the build-mistress let me put out the ones that could not be done via config files in my trial build trees for the new family of Windows compilers. That was OK.
Then she discovered that TechOps, installing some new tools on the Macs, had changed the compiler version on them. I un- and re-installed Xcode, and found that made no difference. The new tools packages had installed a new set of command-line tools, making them inconsistent with the installed Xcode. Snarl…
In our Sprint Retrospective today someone wrote “I don’t like agile” on a (virtual) post-it note.
Only taken 67 Sprints
New hire? Foo to ten characters.
Been with us all 67 Sprints.
Agile is relatively new to our business so a lot of engineers are used to Waterfall and being able to spend longer periods of time than 3 weeks on a task.
(In a previous role I once spent 4 months working on the same problem.)
The chap’s point was that there’s a significant overhead in breaking a task up into manageable pieces and completing each of those to a satisfactory level, i.e. the definition of done.
There’s a few things to unpack there and I don’t necessarily completely disagree with his point of view. It was a useful discussion to have I think.