“do it again, I wasn’t looking”

  • 0 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: September 25th, 2023

help-circle


  • You’re remembering correctly, every other logic gate can be built from NAND gates, which is the foundation of this sort of minimal-instruction-set exercise. Beyond that, you need to be able to move data and change your program counter (jump, often conditionally). Then, if you want parity with modern instruction sets beyond just being turning complete, you need return and interrupt for control flow.



  • Bookmarking your comment so I can come back to it in a couple hours, if I hopefully remember to.

    But yes, almost. I don’t think the interrupt is necessary and the return isn’t under certain architectures. I have a doc on my computer somewhere where I was investigating what the absolute minimum was to make a turning complete machine and, to my recollection, there was only 4-6 instructions that were absolutely necessary. The ones I remember off the top of my head are NAND, MOV, JUMPIF, and then I believe I included NOP in accordance with some principle. RET and INT were convenience features in this design.






  • If I were to fully elaborate, I’d be typing for hours, so I’ll sum up:

    • pip - default behavior is to install to system-wide site packages. In a venv, it will try to upgrade/uninstall system packages without notice/consent unless you specify --require-virtualenv. Multiple things can fuck up your ENV to make the python binaries point to system-wide, while your terminal will still show you as in a venv. Also why TF would package metadata files need to be executable? Bad practice, -1/10
    • nix - they acknowledged years ago that they should probably have some kind of package signing and perhaps an SBOM or similar mechanism, but then did nothing to implement it and just said “oh well, guess we’re vulnerable to supply chain attacks, best not to think about it”
    • brew - installing packages parallel to your system packages manager, without containers. My chief complaint here is that brew is a secondary package manager that people might treat as a “set and forget” for some packages, rarely updating them. So what happens when a standard library used by a brew package is vuln? A naive Linux user might update their system packages but totally forget to update brew. And when updating brew, you can easily hit max_open_file_descriptors because kitchen sink

    From there, it’s all extremely nit-picky and paranoid-fueled-- basically, none of the package managers I mentioned are conducive, in my eyes at least, to a secure and intuitive compute environment.

    Unfortunately, there’s not much I can do about it except bang pots and pans and throw maintainers under buses when the issue that has been present for years rears it’s ugly head. Because they are the only ones who can change this, and pressure is the only thing that might motivate them to.






  • Not to be confused with the fallacy that these essentials are exclusively the product of exchanging money-- while you can pay for better health and better safety, there are also things you can do with little to no money to improve those for yourself, though the freedom to do so unfortunately is not default and financial security does empower an individual to better use what resources are available to them-- maybe not everyone can trivially access hiking trails, or be in the health for it, and even then they should have a good pair of shoes, a water bottle, and reliable mode of transportation to/fro the trails, which again not everyone has unfortunately.

    Imo, the idealistic answer is to work to ensure everyone an essential baseline level that can reliably empower them to live as healthy and opportune of lives as is reasonably possible, while of course having in place infrastructure and accomodations to those less fortunate in health and/or opportunity. I’d like to think this is more than a utopian idea, and closer to a reality than one might originally think, or perhaps I was somewhat unique or grossly digressed from the status quo in pessimistically believing that we might be far from this being a reality. Perhaps my pessimism was also influenced by my financial stress at the time, among the other throes of life.




  • I’m not a lawyer, but under the definition of “Infrastructure” on page 5, they state that they will construe WhatsApp Infrastructure and Partner Infrastructure accordingly, which to my untrained eye is prima facie evidence to their acknowledgement that these are separate systems, at least one (the Partner’s) of which is not under their custodianship and not named as subject of the first stipulation you quoted. In other words “do not make it so WhatsApp’s own infrastructure would run GPL material” and potentially “do not send GPL material through our systems”

    The second one I interpret to mean “nothing with licenses that apply that runtime operation is copy left”


  • I created a GitLab account long before they implemented this, but never used it. Went to post an issue related to self-hosted GitLab on their issue tracker, and it told me my account was banned. I wrote an email to support and they essentially said “an automated system identified your account as a bot and banned you during an account clean up some years ago to cut back on malicious users”. I informed them that this was not at all reasonable, as I’ve never even posted anything on any GitLab account, and that I would be advising my organization to never pay for any GitLab product or service unless legal writes up the contract terms, because I have no faith in them as a vendor.

    Seriously, fuck GitLab. And if anyone from that org wants to discuss this with me, they can pipe their email to /dev/null