• 3 Posts
  • 635 Comments
Joined 1 year ago
cake
Cake day: August 9th, 2023

help-circle
  • Hitler didn’t take power democratically. Neither did Mussolini or Franco. They each found cracks in how liberal democracy worked in their respective countries. Those cracks were usually the places where the system was decidedly undemocratic, which in those three cases, was generally something where the old nobles still had some power and they lined up behind fascists to save them from leftists.

    America never had nobles, but it does have plenty of cracks in its liberal democracy to be exploited by fascists.

    So to answer your question simply, no, there are no instruments to fix this. Congress can potentially either reign Trump in with legislation, or even impeach him, but I don’t expect either one to happen. If the GOP can be swept out of Congress in 2026, then we can maybe start to fix some things without resorting to extralegal methods. Even that is only a starting point.

    I do know for sure that we can’t go back to the old trajectory as if Trump was just an outlier.



  • Compared to NASA, SpaceX is developing at a breakneck pace. The SLS has its roots in the Constellation program from 2005 which itself came from the 2004 report “Vision for Space Exploration”. That was when NASA finally admitted the Shuttle was never going to live up to its original goals and it had to go.

    Ares V is a reconfiguration of Shuttle hardware into a more traditional rocket. It’s still taken two decades and has one test launch to show for it.

    SpaceX is the only Musk company I’ll defend, and it also seems to be the one that’s best at keeping Elon from fucking around with them internally.

    That said, the whole point of commercial launch systems is that it’s not just one company doing it. Blue Origin might finally have something to show off soon, but there’s nobody else at a reasonable development level. Virgin Galactic only seems interested in space tourisim. (Edit: for completeness sake, I should also add that ULA is a joke.) A bunch of small companies are doing R&D, but few have even a single small launch yet. If it’s just going to be SpaceX, might as well make it a government-run company like the USPS.





  • Yeah, that’s my thinking, too. But the library only takes b64.

    Edit: also, if anything, this system reduces the benefit of strong typing. You can feed whatever string you want into it and the compiler will say it’s OK, even if it would fail at run time. If it were a Vec<u8>, then the compiler can check things. Especially if you do something to let the compiler enforce the length (if possible).

    Or hand over a UUID object directly. Yeah, it ties it to a specific library, but it’s either that or you’re not taking full advantage of strong typing.

    Or just have a sensible default implementation.


  • None of this has much to do with type safety at all. A dynamically typed language might have a Salt object that has a constructor that takes a base64 string. If its common uuid library doesn’t output base64, then you can’t use it directly.

    Nor does a specific uuid library matter much. It just needs to be able to output base64 strings, which is an uncommon uuid encoding, but it’s out there.

    Nor does type safety prevent providing a sensible default implementation.

    The crate uses phc strings, which store the salt together with the hashed password, so no, it can handle it all on its own.

    There was just no thought into how components work together.



  • Edit: for any possible future readers, there is a sensible default that I hadn’t found yet during this work in progress. It’s just in a different struct: SaltString::generate().

    I’d like it better if things were designed to work together better.

    Right now, I’m working on a password storage system using the password_hash crate. You need to provide the salt yourself; this is already a bit silly for not providing a simple default that just gives you 16 bytes from a CSPRNG, but let’s continue.

    You read the Salt struct documentation, and it talks about UUIDs being pretty good salts (well, using v4, anyway). So that pushes you toward the uuid crate, right? Except no. That crate doesn’t produce formats that the functions on the Salt struct will accept, like base64. So maybe the uuid_b64 crate will do it? I don’t think so, because that crate uses a URL-safe version of base64, and it’s not clear Salt will take that, either.

    You’re now forced to use a cumbersome interface from the rand crate to make your salt. I’m still working through some of the “size not known at compile time” errors from this approach.

    All of which would work better if there was a little thought into connecting the pieces together, or just providing a default salt generator that’s going to do the right thing 90% of the time.

    Don’t get me started on how Actix hasn’t thought through how automated testing is supposed to work.










  • Rebuild from scratch gets a bad reputation sometimes because it’s the go-to response of a junior programmer with a little experience. They know the system could be done better, and it seems like the fastest way to get there is to throw out everything.

    What often happens next is the realization that the existing system was handling far more edge cases than it initially appears. You often discover these edge cases when the new system is deployed and someone complains about their use case breaking. As you fix each one, the new system starts to look worse than the old while supporting half its features.

    This often leads people to prefer refactors rather than rewrites. Those can take a lot longer than expected and never quite shed what made the old system bad. Budget cuts can leave the whole project in a halfway state that’s worse than if it was left alone.

    There are no easy answers, and the industry has not solved this problem.