• 0 Posts
  • 29 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren’t allowed to commit UB still. In C++ land I’d venture to guess most any developer won’t care - that’s a bug with your code and not the data structure.

    It’s also more strict because rusts referencing rules are a lot harder then C’s, since they’re all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.




  • The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You’d functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that’s it. It’s like saying “instead of reinventing functionality by building both ext4 and btrfs, why don’t we just improve ext4”?

    The two are practically entirely different.


  • It being objectively better then SVN or CVS doesn’t mean that it’s the best we can do. Git has all sorts of non-ideal behaviors that other VCS’s don’t. Pijul’s data structure for instance is inherently different from git and it can’t be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.

    One example is pijul specifically let’s you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means “cherry picking” a commit and then merging a commit doesn’t effectively merge that commit twice resulting in a merge conflict.

    That’s one example how one VCS can be better.


  • Not OP, but personally yes. Every code forge supporting only git just further enforces git’s monopoly on the VCS space. Git isn’t perfect, nor should be treated as perfect.

    The above is probably the reason why so many alternative VCS’s have to cludge themselves onto git’s file format despite likely being better served with their own.

    Interesting new VCS’s, all supporting their own native format as well for various reasons:

    • pijul
    • sapling
    • jujutsu

    Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you’re okay with not new:

    • mercurial
    • fossil
    • darcs

    VCS’s are still being itterated on and tooling being super git centric hurts that.










  • The point is to minimize privilege to the least possible - not to make it impossible to create higher privileged containers. If a container doesn’t need to get direct raw hardware access, manage low ports on the host network, etc. then why should I give it root and let it be able to do those things? Mapping it to a user, controlling what resources it has access to, and restricting it’s capabilities means that in the event that my container gets compromised, my entire host isn’t necessarily screwed.

    We’re not saying “sudo shouldn’t be able to run as root” but that “by default things shouldn’t be run with sudo - and you need a compelling reason to swap over when you do”





  • This is about PKI. An HTTPS server has a TLS cert, and that TLS cert is signed by / created by a certificate authority (or CA). When you connect to a service over HTTPS, a TLS handshake happens. The handshake starts by the client asking a server to setup a session, and the server hands back it’s certificate. This certificate can be used to encrypt traffic, but not decrypt it. The client makes sure the certificate is signed by a CA it trusts (such as let’s encrypt).

    Once the client has this certificate, it sends a key to the server in encrypted form, and the server decrypts it. They both now use this key to communicate.

    The MITM server can’t compromise the session because: If it swaps the certificate (or in other words, the encryption key the server sent), that key won’t be trusted because it isn’t signed by a CA the client trusts.

    If the MITM tries to send its own shared key signed by the servers certificate - it doesn’t really matter since it can’t read the clients messages anyways to get the shared key from the client. If it forwards it, then you effectively have two separate https sessions with their own keys, and the server will treat them as distinct.