• 1 Post
  • 29 Comments
Joined 11 months ago
cake
Cake day: July 24th, 2023

help-circle


  • You can also do the following to prevent unwanted writes when something is not mounted at /mnt/thatdrive:

    # make sure it is not mounted, fails if not mounted which is fine
    umount /mnt/thatdrive
    
    # make sure the mountpoint exists
    mkdir -p /mnt/thatdrive
    
    # make the directory immutable, which disallows writing to it (i.e. creating files inside it)
    chattr +i /mnt/thatdrive
    
    # test write to unmounted dir (should fail)
    touch /mnt/thatdrive/myfile
    
    # remount the drive (assumes it’s already listed in fstab)
    mount /mnt/thatdrive
    
    # test write to mounted dir (should succeed)
    touch /mnt/thatdrive/myfile
    
    # cleanup
    rm /mnt/thatdrive/myfile
    

    From man 1 chattr:

    A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file’s metadata can not be modified, and the file can not be opened in write mode.
    Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

    I do this to prevent exactly the situation you’ve encountered. Hope this helps!






  • It’s probably best to limit yourself to a used laptop.

    Reading and writing code is nothing more than reading and writing text, and for that you don’t need a fancy gpu or screen.

    What I would recommend you look for in a laptop is

    • an SSD instead of an HDD
    • more cpu cores (at least 4 cores)
    • more memory (RAM) (at least 8GB, preferably 16GB+)

    More memory and cores will help you with compiling and running your code.

    And make sure you take regular backups! You never know when your disk will fail.

    Also make sure to check linux compatibility before you buy. Laptops used to be a pain (10+ years ago), and it’s gotten a lot better, but it’s not always perfect. Just search for “[brand] [model] linux” or try to find the model on the archlinux wiki.




  • Exactly, ansible is basically imperative, where write the steps declaratively.

    Whereas nixos is more like a compiler that compiles to a working linux install.

    If I added the software myprogram and a config file at /etc/myprogram.conf, that’s pretty easy in both. But if I needed to to then remove those it gets different .

    With nixos it’s at easy as removing the two lines that add the program and the config file; after the next “compile”, the file is gone and myprogram is no longer available in the PATH.

    With ansible you need to change the relevant step to use apt remove instead of apt install and to change the config file step in a step that removes the file.

    Don’t get me wrong, ansible is still better than writing a lot of bash scripts, especially if you don’t have people with a lot of shell experience.

    But tools like nixos and guix are on a whole other level.


  • Exactly, if we do a back of the napkin calculation:

    Bitcoin

    Users

    There are 200 million bitcoin wallets, let’s be generous and say those are all owned by unique individuals.

    Total energy consumption

    Bitcoin used about 114 TWh in 2021[1]

    Bitcoin currently uses about 150 TWh annually

    Energy consumption per user

    150 TWh / year 
    ————————— = 0,75 TWh / user / year
    200 million users
    

    Banking system

    Users

    There are over 8 billion people on the planet today, let’s assume 4 billion of them have access to the global banking system.

    Total energy consumption

    The global banking system used an estimated 264 TWh in 2021[1]

    If we assume the same consumption increase rate for banking, that’s about 348 TWh/year currently.

    Energy consumption per user

    348 TWh / year 
    ————————— = 0,087 TWh / user / year
    4.000 million users
    

    With these numbers, bitcoin uses almost 10x the energy per user annually.

    There are of course a myriad of things one can argue over whether it makes a fair comparison, none of which I feel like arguing, since this is just a really simple estimate with a lot of assumptions.

    1: I used the numbers in this article uncritically, if you have better numbers you can run your own calculations.



  • because bash isn’t always in /usr/bin/bash.

    On macOS the version on /usr/bin/bash is very old (bash 3 I think?), so many users install a newer version with homebrew which ends up in PATH, which /usr/bin/env looks at.

    Protip: I start every bash script with the following two lines:

    #!/usr/bin/env bash
    set -euo pipefail
    

    set -e makes the script exit if any command (that’s not part of things like if-statements) exits with a non-zero exit code

    set -u makes the script exit when it tries to use undefined variables

    set -o pipefail will make the exit code of the pipeline have the rightmost non-zero exit status of the pipeline, instead of always the rightmost command.



  • The best thing is to use a different device, period.

    Since the company is lord and master over the device, in theory, they can see anything you’re doing.
    Maybe not decrypting wireguard traffic in practice, but still see that you’re doing non-official things on the device that are probably not allowed. They might think you’re a whistleblower or a corporate spy or something.

    I have no idea where you work, but if they install a CA they’re probably have some kind of monitoring to see what programs are installed/running.

    If the company CA is all you’re worried about, running a browser that uses its own CA list should be enough.


  • Maybe your drive(s) fail and you want to reinstall. Then you already have a setup with all your software and config files installed. Just reinstall NixOS and re-apply your configuration (or build your own Install ISO ).
    And if you ever get a new laptop/desktop/VM/VPS you can do the same.

    Don’t forget to take backups, regardless of your setup tho.

    The reproducibility also leads to some surprise features, like being able to wipe your entire system on every boot. Since NixOS always puts the necessary files in the correct place, this is perfectly fine. If you then add some mechanism to persist specific data across reboots (a separate partition, or the Impermanence module), you will remove all kinda of randomly accumulated files on every boot.

    This means I have very small backups, because I have three kinds of data: stuff that is wiped on every boot, stuff that is persisted but not backed up (/nix/store, all kinds of caches) and stuff that is persisted and backed up (documents, repositories, media).

    None of my OS’s files are in the backups, which makes of them a lot smaller than my previous arch install.