[–] 13 points 3 months ago

Of the total cargo, 7,215 kg consisted of mountaineering supplies, including oxygen cylinders, ropes, and ladders, delivered from Base Camp to Camp 1, while 2,858 kg of waste accumulated at Camp 1 was transported back to Base Camp.

DJI said it aims to remove around 10,000 kilograms of waste from Everest's high camps during each future climbing season.

  • source
  • [–] 3 points 9 months ago* (1 child)

    If you go with dual booting this is what worked for me when I have done dual boot, so windows doesn't mess with boot options:

    1. Window have to be installed first or already there.
    2. With a Live ISO use a tool like gparted and shrink windows main partition from the right.
    3. During installation, choose custom partitioning to manage the free space
    • Make a secondary /boot/efi partition so linux boot is installed there.
    • Make the / root partition for linux and optional make a partition for /home.
    • Finish the installation.
    1. Boot into UEFI and change boot order to that secondary /boot/efi.
    2. Reboot and profit.

    That way grub will be running from the secondary /boot/efi, and it will detect and add windows and the primary /boot/efi

    Windows only sees and care about the first /boot/efi and will only mess with that, so even if it does change something it doesn't matter.

  • source
  • [–] 2 points 11 months ago

    As far as I know, Dockge, Portainer, Coolify, etc. can have different stacks folders, and they will not show, warn you or not let you manage stacks outside their designated paths.

    For your main question, it is possible to build your image on the same system, you would need at least terminal access to do so, and then use the local image with docker compose or Dockge or other, you just would need to reference its image name instead of a URL (to differentiate images I build I prefix their name with local as 'local/service-name'), and it would not pull from anywhere but use the one you already built, you could do it on any folder on the system or inside the stacks folder you have with Dockge

    If you do it on Dockge's stack folder, create a folder for your service, with a docker-compose.yml file inside (with just this it will appear in Dockge), then pull the repository on this folder, and make sure you have the proper Dockerfile to build the image, you can then either build the image first or reference the Dockerfile on your docker-compose.yml. This way when you do docker compose up or in Dockge you press the Start button, it will build the image with the Dockerfile and use it, if it doesn't find the image.

    The other option I know is to have a local image registry (I have done this with Forgejo), so pull the repository on any folder on your system, build it and push it to your local registry, and then just use the local registry URL on your docker-compose-yml

  • source
  • [–] 6 points 1 year ago*

    then the easier method is to install Caddy as docker and use the containername:containerport method?... did I understand correctly?

    Yes, if the only exposed port to the host or outside, is 443 from caddy container, then the only way to access any of those services is HTTPS through caddy.

  • source
  • parent
  • context
  • [–] 19 points 1 year ago* (last edited 1 year ago) (2 children)

    I've installed caddy directly on my unbuntu server, but I admin my Jellyfin (and eventually Nextcloud) with Docker via CasaOS interface... is this a problem? Do I need to run Caddy in docker too?

    The difference between having caddy or any other reverse proxy in docker alongside other apps/services, is that instead of having to expose ports for every container to the host, and then linking every service/app as, localhost:<host-port> to caddy, you can have them on the same docker network and use <container-name>:<container-port> and only expose 80 443 to the host, meaning that the only way to access app/services is through caddy, that way if you disable port 80 after configuring SSL certificates, you can only access services with HTTPS.

  • source
  • [–] 47 points 1 year ago* (last edited 1 year ago) (6 children)

    A friendly reminder that it is best to wait a bit before updating, in case there are any bugs still there, happened a few days ago with Forgejo, that a mayor bug was detected after initial release of v13.0

  • source
  • [–] 1 point 1 year ago* (last edited 1 year ago)

    You could use aliases on your .bashrc for git (and a bare repo), that would let you manage your $HOME and /etc directly with git without using symlinks, only downside is having them separated in two aliases and two repos.

    # user config repo
    alias dotfiles='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
    
    # system config repo
    alias etcfiles='sudo git --git-dir=$HOME/.etcfiles --work-tree=/etc'
    

    It is also recommended that you run:

    <alias> config --local status.showUntrackedFiles no
    

    in the terminal for both the dotfiles and etcfiles aliases (you can pick the aliases and git-dir names you want)

    The aliases help you have a custom named folder instead of .git located in a custom path, and you can manage them without symlinks as you use git directly on the file's original location, this would solve your issue of other solutions that depend on symlinks

    Note: you could technically have the root directory --work-tree=/ as a work tree to use only one command, but It is not recommended to give git the possibility to rewrite any file on the entire file system.

    Some reference links:

    Text

    Video

  • source
  • view more: next ›