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

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



  • balsoft@lemmy.mltoMemes@lemmy.mlThe Big Beautiful Lie
    link
    fedilink
    arrow-up
    17
    arrow-down
    4
    ·
    edit-2
    4 days ago

    The parties are not the same. One is an openly fascist party and the other is full of meek center-right neoliberals trying to keep the status quo for their wealthy donors. However neither is trying to “fix the damage” or “make it good again”, except perhaps for the top 0.001%. Most working-class people are shafted either way. If the republicans get their way, most non-whites will be deported on enslaved in prisons, women will be enslaved at home, and the remaining working-class white men will struggle to sustain themselves and their (non-working) wives and families under the christofascist dictatorship of the capital. If the democrats somehow claw back from that, there will be less abject racism and sexism but the working class will still struggle to survive in an increasingly monopolized dictatorship of the capital.

    Ask yourself this question: which democrat policies from the last decade directly benefit the working class? I can name maybe 3 very compromised policies that are about 60 years behind most of the world.

    To paraphrase an old meme, republicans want 100 rich white men to rule over the entire world with an iron fist; democrats want 30 of those people to be LGBTQ+ women of color.

    Are democrats better? Sure, a bit better. But it’s not like just electing them will save you.


    • You write tests for functionality before you write the functionality.
    • You code the functionality so the tests pass.
    • Then, and only then, the test becomes a regression test and is enabled in your CI automation.
    • If the test ever breaks again the merge is blocked.

    I disagree. Merging should be blocked on any failing test. No commit should be merged to master with a failing test. If you want to write tests first, then do that on a feature branch, but squash the commits properly before merging. Or add them as disabled first and enable after the feature is implemented. The enabled tests must always pass on every commit on master.


  • I concede that on a feature branch, before a PR is made, it’s ok to have some failing tests, as long as the only tests failing are related to that feature. You should squash those commits after the feature is complete so that no commit has a failing test once it’s on master.

    (I’m also a fan of TDD, although for me it means Type-Driven Development, but I digress…)


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



  • Eww, no. You’re doing tests wrong. The point of tests is to understand whether changes to the code (or dependencies) break any functionality. If you have failing tests, it makes this task very difficult and time consuming for people who need it most, i.e. people new to the project. “Is this test failing because of something I’ve done? <half an hour of debugging later> Oh, it was broken before my changes too!”. If you insist on adding broken tests, mark them as “expected to fail” at least, so that they don’t affect the overall test suite result (and when someone fixes the functionality they have to un-mark them as expected to fail), and the checkmark is green. You should never merge PRs/MRs which fail any tests - it is an extremely bad habit and forms a bad culture in your project.






  • It’s hard for me to fathom living in conditions like this. I can relate to not having enough money for basic food, even though I’m fortunate enough that I was never in a position like that. But it’s incomprehensible for my brain that there is no food at all in a place. Like, even if you had some money saved up, you can’t get any food to eat. Even if some international orgs are willing to give you food for free, you can’t get it because some armed guys a couple dozen kilometers away will shoot the lorry driver if they cross the border. Hunger is not even a “punishment for being poor”, hidden away in homeless shelters, like it is in most places; it is literally everywhere around you.

    Fuck the capitalists who gatekeep basic food items behind a paywall, but I can’t even describe my feelings towards israel rn. It has turned the “open-air concentration camp” into an open-air suffering and brutal extermination camp. It’s not a war of attrition, it’s not a siege, it’s an execution by hunger.


  • PHP is far from “least bad language”. Nowadays it is an ok language, one of many. You can also write ok code in it. The main issue is that it’s really easy to write horrible shit that just barely works and will break when you look at it wrong. In fact without a lot of knowledge and experience that is the code you will probably write.

    There are much better languages for any webdev niche you can think of, and some that are just better for webdev overall (e.g. Elixir). The reason PHP is still relevant is mostly huge legacy codebases that require a lot of engineering power to maintain (because PHP is not a good language for maintenance).

    The way I look at it is that PHP is the C++ of webdev (but slightly worse).


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


  • I’m sorry to say this, but your posts are not good agitprop. They are low-effort, not very convincing, sometimes misleading, and sometimes just wrong.

    If you want to make good agitprop memes,

    1. shit on ideas and arguments, not your target audience - do not alienate all liberals by portraying them as a soyjack
    2. avoid logical fallacies or incorrect/outdated facts - we can make convincing arguments without lying or manipulation
    3. educate people - give them new information or perspective that might otherwise be downplayed or ignored by media they consume

    Hope this is useful.