Shrysr asks the definition of a public toilet computer – does it apply to all online machines? Diana Coman says it’s a matter of what’s running on the machine and how open it is to the network; definitions vary. Shrysr asks for Diana’s definition – is she strict in only doing certain activities on public toilet computers? Shrysr wants to improve his data security – he’s put sensitive data on Evernote for convenience, and wonders if he should store his private keys and mail server on Linode VPS.
BingoBoingo cautions against running one’s own mail server: keeping up with standards can be time consuming, and big inbox providers can distrust one’s mailings. He says no to valuable private keys on Linode: people have lost Bitcoin for doing so. Diana echoes – storing private keys on someone else’s machine is particularly bad.
Diana emphasises that one’s private key is one’s identity in #o; anything done with that key is done by oneself; losing one’s key is the death of one’s identity – one will have to start over anew with a fresh key/identity.
Conversely, Diana points out that government data has nothing to do with security (notwithstanding pretense to the contrary) – handled as it is over insecure channels and methods. She considers all government/school/civil admin data public; therefore fit for public toilet PC use.
Diana explains that “private” means default-closed/“no”, with exceptions; whereas public is the opposite. Thus, a public toilet computer will allow most things, whereas a private computer will mostly forbid.
Linking to Diana’s Open Sores article, Shrysr wonders why open source code is such a shitshow – despite the voluntary nature and developer turnover, aren’t there best practices/guidelines to maintain codebases? Is CI/CD just another Docker – ie. an ineffective scam? Linking to Diana’s Brave New Code article, he wonders if it’s possible to lower barriers to entry, whilst maintaining quality. Diana explains CI/CD is a nebulous term; insofar as it means code signed by a trusted person, it’s fine. The barriers are the shit-blockers; charitably, one might say the problem is lowering the wrong barriers, but this wrongness is itself caused by bad incentives; isn’t the root cause of the shit influx.
Pondering bad incentives, Shrysr asks if quantity of GitHub contributions being used as a stand-in for competence is a case. After linking to examples of good code, Diana agrees, noting two core problems: no ownership of code, and the “more lines added = better” (rather than worse) mindset. Shrysr can’t see the sense in the current codebase situation, noting the similarly baffling job environments he’s worked. As example, he mentions interacting with senior CAD engineers unable to identify basic product differences. Beginning to see the shit surrounding him, he understands the anger BingoBoingo feels toward the software industry; maybe he’s feeling it, too.
I wonder what Diana means by code ownership – reputational responsibility, a la V? How can something immaterial be owned? I can vaguely recall a #t discussion in which MP defined ownership as the ability to destroy the owned item – I’ll add finding that thread to my reading list.
Comment by Daniel Godwin — October 5, 2020 @ 10:30 pm
Lmao. Did you *read* the linked piece?
Comment by Diana Coman — October 6, 2020 @ 7:02 am
I planned to read it today, with a fresh mind. Seems I still need to get into my thick skull that it’s OK to publish works in progress: “Here’s my summary so far, though I still need to read the articles”, and NOT OK to present things as finished, when they’re not. Better to do it thoroughly, properly, the first time – even if it takes longer/prevents immediate completion.
Again, I’ve created more work for myself, by having to go back and fix.
Comment by Daniel Godwin — October 6, 2020 @ 10:52 am
[…] below is the corrected, completed version of Ossasepia Log Notes 6. I’d neglected to read the Collection of Pearls article prior to publishing, which resulted […]
Pingback by Ossasepia Log Notes 6, Corrected « Young Hands Club — October 6, 2020 @ 10:21 pm