• 0 Posts
  • 7 Comments
Joined 1 year ago
cake
Cake day: July 28th, 2023

help-circle

  • Anafroj@sh.itjust.workstoSelfhosted@lemmy.worldCost-cutting tips?
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    Basically, yes. You can configure most cron programs to mail task output to you (it’s usually done by setting the MAILTO variable in the crontab, provided sendmail is available on your system).

    I use that to do things like:

    0 9 11 10 * echo 'lunch with John Doe at 12:20'
    

    It sends me a mail, and I can see the upcoming events with crontab -l. If it’s not a recurring event, I then delete the rule.


  • My favorite cost cutting tip is to avoid big webapps running on docker, and instead do with small UNIX utilities (cron instead of a calendar, text files instead of note taking app, rsync instead of a filehosting dropbox-like app, simple static webserver for file sharing, etc). This allows me to run my server on a simple Raspberry Pi, with less than 500mb of used RAM in average, and mininal energy consumption. So, total cost of the setup:

    • Raspberry Pi : 77€ x 2 = 144€ (I bought two to have a backup if the first one fails)
    • MicroSD 64gb : 13€ x 2 = 26€ (main and backup)
    • average energy consumption : 0.41€ (2kWh) per month

    With that, I run all services I need on a single machine, and I have a backup plan for recovery of both hardware and software.

    Getting used to a UNIX shell and to UNIX philosophy can take some time, but it’s very rewarding in making everything more simple (thus more efficient).




  • Obligatory check : are you sure you really need a forge? (that’s the name we use to designate tools like Github/Gitlab/Gitea/etc). You can do a lot with git alone : you can host repositories on your server, clone them through ssh (or even http with git http-backend, although it requires a bit of setup), push, pull, create branches, create notes, etc. And the best of it : you can even have CI/CD scripts as post-receive hooks that will run your tests, deploy your app, or reject the changes if something is not right.

    The only thing you have to do is to create the repos on your server with the --bare flag, as in git init --bare, this will create a repos that is basically only what you usually have in the .git directory, and will avoid having errors because you pushed to a branch that is not the currently one checked. It will also keep the repos clean, without artifacts (provided you run your build tasks elsewhere, obviously), so it will make all your sources really easy to backup.

    And to discuss issues and changes, there is always email. :) There is also this, a code review tool that just pop up on HN.

    And it works with Github! :) Just add a git remote to Github, and you can push to it or fetch from it. You can even setup hooks to sync with it. I publish my FOSS projects both on Github and Gitlab, and the only thing I do to propagate changes is to push to my local bare repos that I use for easy backups, they each have a post-update hook which propagates the change everywhere it needs to be (on Github, Gitlab, various machines in my local network, which then have their own post-update hooks to deploy the app/lib). The final touch to that : having this ~/git/ directory that contains all my bare repos (which are only a few hundred MB so fit perfectly in my backups) allowed me to create a git_grep_all script to do code search in all my repos at once (who needs elasticsearch anyway :D ) :

    #!/usr/bin/env bash
    # grep recursively bare repos
    
    INITIAL_DIR=$(pwd)
    for dir in $(find . -name HEAD -exec dirname '{}' \;); do
      pushd $dir > /dev/null
      git grep "$*" HEAD > /dev/null
      if [[ "$?" = "0" ]]; then
        pwd
        git grep "$*" HEAD
        echo
      fi
    
      popd > /dev/null
    done
    

    (note that it uses pushd and popd, which are bash builtins, other shells should use other ways to change directories)

    The reason why you may still want a forge is if you have non tech people who should be able to work on issues/epics/documentation/etc.


  • This. Also, anybody who can identify you as the owner of the host (be it through Whois or through hosting service records) can associate your name to everything posted on that instance, thus profiling you, your tastes and your opinions easily (it’s insane the amount of personal information we can leak on social media, even when thinking we’re not). Clearly not something to do in countries where you can be harassed or worse for your opinions, and probably best avoided everywhere, if privacy is a concern for you. There is some virtue in being immersed in the masses (that’s actually a common anonymisation strategy, from merging streams comes plausible deniability).