• 8 Posts
  • 142 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2024

help-circle

  • There’s no need for the middleman in this scheme. Instead, a much simpler solution would be:

    1. Website A gives you a randomly generated $TOKEN
    2. You go to Government and ask it to sign something like The person with $TOKEN is of legal age. You have to provide your ID or whatever here, but the government doesn’t know who made the token.
    3. You go back to website A, it checks the signature of the message and lets you through

    This can be automated in some way; maybe with a browser extension or some referrer-less redirect sort of thing.

    It’s still fundamentally shitty though, because now the government pretty much knows that you want to watch adult stuff, it just doesn’t know which adult stuff exactly.

    A better (but almost impossible to implement) solution would be for the government to issue everyone a smartcard as an identity document (many countries already do, but without the following features). On that smartcard is a private key, with the corresponding public key signed by the government. The smartcard can then sign any $TOKEN with true statements about you, e.g. The person with $TOKEN is of legal age, or The person with $TOKEN is called $NAME, or The person with $TOKEN has a driving license, etc. You have to connect it to your computer in some way so the website can talk to it, but it should be trivially doable with almost any modern smartphone. This way, everyone has the ability to attest stuff about them without the government being directly involved.

    The reason this won’t work is because it would be quite expensive to do and would take a long while to implement.


  • The article is clearly mostly manipulative bullshit. The arguments about “incompatibilities” between uutils and coreutils being used as an “extend” strategy is just bonkers, the point of uutils is to be a 1-to-1 compatible toolset, and there’s no reason to doubt the developer’s intention there. Even if they do introduce some extra features, most software projects that actually matter will not be using them, because compatibility with coreutils will remain important for decades to come.

    The kernel of truth hiding in there is that Rust’s “preferred” licensing under MIT/Apache is indeed a problem, and it should have been GPL (or at least MPL) everywhere from the beginning, especially for libraries. This is probably the worst aspect of Rust indeed, but not enough to outweigh all the awesome technical parts of it.


  • Yeah, but also the price of a coin is a reflection of how much people “want” it, which increases liquidity, making it easier/cheaper to finalize your transfers. It’s a tradeoff as usual. E.g. with Bitcoin, you can find people willing to exchange cash for BTC and BTC for cash at exactly market rates, making your losses for a transfer equal the transaction fee. I don’t think I could do that with some random memecoin.


  • I don’t think all of crypto is always a scam. It can be useful in some instances, e.g. sometimes it’s the cheapest way to do cross-border money transfers (apart from just traveling with cash). It’s also the most private of the available digital payment schemes. But yeah unfortunately most of its use (which is as an “investment”, rather than just a money transfer utility) is a scam and a pyramid scheme. BTC shouldn’t cost $100k (or whatever it’s up to now).








  • I agree with your overall point, that having a single consistent functional language for package descriptions and build scripts is a great thing, and that bash is awful, but your reasoning is somewhat flawed. The main drawbacks of bash are somewhat rectified in Nix because bash is very much contained/sandboxed, which prevents arbitrary damage to the system, and there are some nice defaults in stdenv too.

    The Guile version supports a more powerful functionality, which is that evaluation of a package can have several extra results (called outputs). It is over a year that I read about that in the Guix documentation and yet I recognize it immediately.

    Nix also supports multiple outputs (in fact this is where the concept of outputs in Guix came from)

    the code tells me that it is removing examples.

    You could also do that with Nix in an easier and more declarative fashion, either by adding a comment, or by doing this:

    postInstallPhases = [ "removeExamplesPhase" ];
    removeExamplesPhase = ''
      rm -f "$out"/lib/{basic-server,helloworld,postcollector}
    '';
    

    Scheme has much safer and more robust string handling. The code will not do harmful things if a file name contains white space or happens to be equal to ‘echo a; rm -rf /etc/*’.

    Bash is just two double quotes away from doing this too. See code above for an example

    Scheme strings handle Unicode well

    Bash also handles Unicode well

    If there is an error, it will not be silently ignored as is the norm in shell scripts which are not written by experts, but will throw it.

    Nixpkgs stdenv sets set -eu which has a similar effect. If that code fails, the entire build will fail too.

    the code has less redundancy. For example, the bash version mentions three times the subfolder “lib”, the Guile version only once. This makes it easier to refactor the code later.

    This is also really quite easy to rectify in bash, see code above.



  • Well, Nix language is also full of hacks, idiosyncrasies and stupid decisions. I say that as someone who’s writing it “professionally”, i.e. as part of my job. Scheme is way less “unexpected”. But there are other parts of Guix which are pretty weird or just bad, like the “channels”/“pins” management situation.



  • One aspect of Guix I found to be really fascinating: That there is basically no conceptual difference between defining a package as a private build script, and using a package as part of the system.

    This is true for Nix as well.

    The two main advantages of Guix are the language (which is well-known and comes with lots of good tooling and other support) and the package bootstrapping.


  • There’s nothing technically preventing using TPM without secure boot. This is a limitation imposed by OEMs. In fact I have a separate hardware encryption key that I encrypt my (laptop) drive with, and even I don’t (can’t) know the private key. I only know the pin that is needed to unlock it. If motherboard OEMs implemented something like this on the motherboard, with the ability to decrypt the bootloader partition before booting into it, this would solve everything.



  • Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).

    An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there’s no need for key enrolment into firmware, and firmware manufacturers don’t have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer’s key; if you flash something unsigned, a warning pops up Android-style before every boot).

    If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.