Mama told me not to come.

She said, that ain’t the way to have fun.

  • 2 Posts
  • 351 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle






  • Use Lua, it uses one-based arrays. This is nice for a few reasons:

    • last element is array[length]
    • zero can be reserved for the type (especially nice for representing XML: 0 = node name, 1-N = children, named table entries = attributes)
    • very rarely see + 1 and - 1 in my code

    It feels wrong coming from C, but it’s actually really nice, especially since the reasons C does it don’t apply (i.e. index is just a memory offset).









  • It’s fine, it just grabs the network settings from the gluetun service.

    Btw, your post is hard to read due to formatting. Surround the code block with triple backticks at the top and bottom like this:

    ```
    code goes here
    ```

    Example:

    services:
      gluetun: # This config is for wireguard only tested with AirVPN
        image: qmcgaw/gluetun
        container_name: gluetun
        ...
        ports:
          - 8888:8112 # deluge web interface
          - 58846:58846 # deluge RPC
      deluge:
        image: linuxserver/deluge:latest
        container_name: deluge
        ...
        network_mode: service:gluetun
    


  • Awesome, thanks!

    In terms of architecture, which is preferred:

    • separate pod per “app” (e.g. NextCloud), but all one network
    • separate pod and network per app
    • everything in one pod

    I’d like to have one gateway, Caddy, so my cert renewal and proxying are all in one place, and I’d like those proxy configs to look like http://<container>

    I’d prefer my containers not be able to talk to each other unless I specifically allow it. The second option would get me that, but I think it would force me to expose ports for each app to the system.

    TL; DR - Can I have a “Caddy” pod that can see exposed ports from other pods, but hide those ports from regular system users? If not, I’ll probably do the first option. I also want to be able to expose ports to the host on a per app basis if needed.





  • Two main options for self-hosting:

    • OnlyOffice - focus on compatibility with MS Office formats, but full disclosure, it has ties to a Russian org (R7? Product is marketed as R7-Office), but the primary developer seems to be Latvian (Ascensio System SIA)
    • Collabora CODE/LibreOffice Online - Collabora CODE is a community edition of a for-profit office suite based on LibreOffice (maintained by The Document Foundation) by a company in the UK

    Both have integration with NextCloud and probably other cloud suites (I think Seafile supports both?), and I think they can both be used standalone. OnlyOffice also has client versions that can be used separately or with a cloud version.

    Some technical differences:

    • rendering - OnlyOffice renders in the client, Collabora renders on the server and sends images back to the client; both support collaborative editing
    • format support - OnlyOffice focuses on MS Office formats, LibreOffice focuses on open formats, though both have support for multiple formats; you’ll likely get more rendering differences vs MS Office w/ Collabora, though both have their issues
    • features - OnlyOffice has limited features, Collabora has whatever features LibreOffice has (read: lots)

    I personally use Collabora, mostly since I use LibreOffice anyway, so I’d rather deal with some jankiness w/ the server-side rendering than deal w/ jankiness due to MS Office support. I use it through NextCloud, though I’m trying out Seafile and may swap to that instead.

    Editing spreadsheets on mobile works for me, but it’s janky. Not sure how the OnlyOffice experience is though. Fortunately, I mostly just use it to edit a couple cells pretty rarely (think budgeting), so it gets the job done.