• 0 Posts
  • 58 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle



  • One day you will inherit a code base so bad that you’ll end up commenting old code

    Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…

    Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)

    Your so called comment standards and principals are fine if you are building something from the ground up

    Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…
















  • philm@programming.devtoProgrammer Humor@programming.devYes
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    8 months ago

    but effectively it’s bash, I think /bin/sh is a symlink to bash on every system I know of…

    Edit: I feel corrected, thanks for the information, all the systems I used, had a symlink to bash. Also it was not intended to recommend using bash functionality when having a shebang !#/bin/sh. As someone other pointed out, recommendation would be #!/usr/bin/env bash, or !#/bin/sh if you know that you’re not using bash specific functionality.


  • installer

    You mean the “new” installer GUI? I never used it TBH, I always did partitioning (and everything else) via CLI, not sure about that. But NixOS (gnome version) has GParted and all other kinds of partitioning tools on board, so just partition it as you think it’s best and then generate a config via nixos-generate-config as described in the manual. One tip, when going down that rabbit hole (when you’re committing at least): Start with Nix flakes right away. Checkout all kinds of dotfiles in github of other users (and on github there are a lot of configurations that can be source of inspiration).