• 1 Post
  • 333 Comments
Joined 1 year ago
cake
Cake day: August 9th, 2023

help-circle
  • Mostly, yes.

    I’d like to find a better way to phrase "why aren’t you . . . " questions. It carries an accusatory tone in text, even if you don’t intend that. The answer is almost invariably going to be either “I didn’t know it existed” or “because reason X”. Neither case justifies the accusatory tone. Maybe if the “I didn’t know it existed” answer was something so basic that they really should have known it existed, but probably not even then.




  • You know, maybe we shouldn’t be taking estimation advice from a 1980s science fiction movie that amounts to a systematic method of lying.

    Yes, I’ve used it before. Yes, you can hopefully have everything average out in the end. Yes, project managers demand estimates. None of these are good reasons to back up how fundamentally flawed it is.






  • There’s downsides to the companies, though. Interviewing new candidates takes money, and takes time away from people already on the team. If everyone is switching jobs to get a higher salary, then companies aren’t saving anything in the long run. They also have a major knowledge base walking out the door, and that’s hard to quantify.

    It’s a false savings.

    If I were to steel man this, it’d be cross-pollination. Old employees get set in their ways and tend to put up with the problems. They’ve simply integrated ways to work around problems in their workflow. New people bring in new ideas, and also point out how broken certain things are and then agitate for change.

    This, I think, doesn’t totally sink the idea of the “company man” who sticks around for decades. It means there should be a healthy mix.




  • It’s a historical quirk of the industry. This stuff came around before Open Source Software and the OSI definition was ever a thing.

    10BASE5 ethernet was an open standard from the IEEE. If you were implementing it, you were almost certainly an engineer at a hardware manufacturing company that made NICs or hubs or something. If it was $1,000 to purchase the standard, that’s OK, your company buys that as the cost of entering the market. This stuff was well out of reach of amateurs at the time, anyway.

    It wasn’t like, say, DECnet, which began as a DEC project for use only in their own systems (but later did open up).

    And then you have things like “The Open Group”, which controls X11 and the Unix trademark. They are not particularly open by today’s standards, but they were at the time.


  • The tooling around it needs to be brought up to snuff. It seems like it hasn’t evolved much in the last 20+ years.

    I had a small team make an attempt to use it at work. Our conclusion was that it was too clunky. Email plugins would fool you into thinking it was encrypted when it wasn’t. When it did encrypt, the result wasn’t consistently readable by plugins on the receiving end. The most consistent method was to write a plaintext doc, encrypt it, and attach the encrypted version to the email. Also, key servers are setup by amateurs who maintain them in their spare time, and aren’t very reliable.

    One of the more useful things we could do is have developers sign their git commits. GitHub can verify the signature using a similar setup to SSH keys.

    It’s also possible to use TLS in a web of trust way, but the tooling around it doesn’t make it easy.



  • I setup my opnsense firewall for IPv6 recently with Spectrum as an ISP. I followed this howto from The Other Site:

    https://www.reddit.com/r/OPNsenseFirewall/comments/xmurda/psa_howto_ipv6_on_spectrum_formerly_twc_time/

    Even as someone who has a background in networking, I’d have no idea how to figure some of that stuff out on my own (besides reading a whole lot and trying shit that will probably break my network for a weekend). And whatever else you might say about Spectrum, they have one of the saner ways to implement it; no 6to4 or PPPoEv6 or any of that nonsense.

    I did set the config for a /54, but Spectrum still gave me a /64. Which you can’t subnet in IPv6. Boo.

    Oh, and I’m not 100% sure if the prefix is static or not. There’s no good reason that it should change, except to make self-hosting more difficult, but I have a feeling I’ll see it change at some point.

    So basically, if this is confusing and limiting for power users, how are average home users supposed to do it?

    There are some standardization things that could make things easier, but ISPs seem to be doing everything they can to make this as painful as possible. Which is to their own detriment. Sticking to IPv4 makes their networks more expensive, less reliable, and slower.



  • I’d like something akin to XML DOM for config files, but not XML.

    The one benefit of binary config (like the Windows Registry) is that you can make a change programmatically without too many hoops. With text files, you have a couple of choices for programmatic changes:

    • Don’t
    • Parse it, make the change, and rewrite it (clobbering comments and whitespace that the user setup; IIRC, npm does this)
    • Have some kind of block that says “things below this line were automatically set and shouldn’t be touched” (Klipper does this)
    • Have a parser that understands the whole structure, including whitespace and comments, and provides an interface for modifying things in place without changing anything around it (XML DOM)

    That last one probably exists for very specific formats for very specific languages, but it’s not common. It’s a little more cumbersome to use as a programmer–anyone who has worked with XML DOM will attest to that–but it’s a lot nicer for end users.




  • Per your edit, you’re misunderstanding what Bitwarden does and why it’s different than normal web site password storage.

    Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you’ve stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It’d be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.

    Typical website auth isn’t like that. They have to actually match your transmitted password against what’s in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.