• 0 Posts
  • 1.13K Comments
Joined 1 year ago
cake
Cake day: August 9th, 2023

help-circle





  • 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.






  • Lots, but only a few that are worth a damn. I’ve come to call them “Han Solo Simulators”.

    Its a genre that seems to attract a lot of half baked game designers. Make a big universe sandbox where you fly a spaceship to space stations and planets and moons and trade stuff and do pirate shit or anti-pirate shit. Lots of people have this idea, only a few make anything good out of it. Doesn’t seem like it can go wrong, and yet . . .

    Battlecruiser 3000 AD is a particularly infamous case of 90s Internet lore. By all accounts, it did eventually patch the game up enough to be decent, but it took years to get there. At release, the game’s installer would crash for most people. However good it might have ended up, the Internet drama was better than the game ever could be. Look up “Derek Smart” if you’re interested.

    The X series is one I want to like, but it’s been really buggy for me. Like rage quit when it destroys my progress kind of buggy. I haven’t played X4, though.

    No Man’s Sky was an infamous mess at launch. Unlike Battlecruiser 3000 AD, it did eventually change its reputation, but it was a long, hard road. I played it a few years ago and found it uninteresting, but basically playable.

    And then there’s Star Citizen. I’ll just leave it at that.

    Anyway, the Elite series is probably the most successful for single player or smaller multiplayer, and Eve: Online for massively multiplayer.





  • 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.