Tiny Tiny RSS: Community

Should non-docker install even be supported in $current_year?

I too run tt-rss on my raspberry pi (model 3b, not even a recent one) and it does not have any problems with my nginx php-fpm postgres installation and cron every 30 min.

Docker, tough, I really don’t need it. Maybe snap can be an idea: still easy for beginners, still containerized, more lightweight.

you’re kidding right?

I get it, people have strong opinions on snap. But it works fine for Rocket.Chat and Nextcloud…

+1 for Docker
snap is nice in theory, not so much in practice.

It’s nothing to do with “strong opinions” on snap and how it works fine for other things. It works fine for other things on Ubuntu. Just like Flatpack works fine for things on Fedora. The problem Fox is trying to solve is how heterogenous people’s systems are. Docker homogenizes them.

Personally, I don’t think Docker is the solution, either, but that’s because I think this is the wrong kind of application to run under it. They’re cattle, not pets. TT-RSS is a pet. You run it long term. It’s not really designed to be blown away every 24 hours unless you keep your data in something that’s not containerized (by “data” I mean “the database”). At least in my view (obviously there’s reasonable disagreement).

Going “Docker only” as the supported method certainly is a nice “fire and forget” solution to trying to juggle the questions of every random “Linux enthusiast” who installs TT-RSS and then posts about their problems here. My preference would be “nothing bespoke.” For example, “run this on a supported mainstream Linux release, fully managed by you (i.e.; not shared hosting), running distribution provided packages, or you’re on your own.” That should cover all of the snowflakes without going full Docker.

Me, I plan on going full snowflake. I want to get out of the Linux game entirely and move to FreeBSD (at least for my own stuff. I still manage a swarm of Linux machines at work).

I have no idea what you could possibly have against it...
$ df | anonymise
Filesystem                            1K-blocks      Used  Available Use% Mounted on
udev                                   12279804         0   12279804   0% /dev
tmpfs                                   2460616      2328    2458288   1% /run
/dev/sda2                             959863856 479725436  431310212  53% /
tmpfs                                  12303064    145928   12157136   2% /dev/shm
tmpfs                                      5120         4       5116   1% /run/lock
tmpfs                                  12303064         0   12303064   0% /sys/fs/cgroup
/dev/loop0                               144128    144128          0 100% /snap/gnome-3-26-1604/97
/dev/loop2                                 4352      4352          0 100% /snap/gnome-calculator/544
/dev/loop3                                91264     91264          0 100% /snap/core/8268
/dev/loop4                                 1024      1024          0 100% /snap/gnome-logs/81
/dev/loop5                                91264     91264          0 100% /snap/core/8213
/dev/loop7                                 3840      3840          0 100% /snap/gnome-system-monitor/123
/dev/loop6                               144128    144128          0 100% /snap/gnome-3-26-1604/98
/dev/loop8                                56064     56064          0 100% /snap/core18/1650
/dev/loop9                                 4352      4352          0 100% /snap/gnome-calculator/536
/dev/loop10                               45312     45312          0 100% /snap/gtk-common-themes/1353
/dev/loop11                              160512    160512          0 100% /snap/gnome-3-28-1804/110
/dev/loop13                                1024      1024          0 100% /snap/gnome-logs/73
/dev/loop14                               15104     15104          0 100% /snap/gnome-characters/375
/dev/loop12                               46080     46080          0 100% /snap/gtk-common-themes/1440
/dev/loop17                              151808    151808          0 100% /snap/chromium/986
/dev/loop18                               72192     72192          0 100% /snap/dino-client/2
/dev/sdb1                             864062200 177244244  642856256  22% /data
/dev/sda1                                523248      7792     515456   2% /boot/efi
//cmpdevnas.myqnapcloud.com/public   4227420072 428804268 3798615804  11% /home/pjh/Public
//cmpdevnas.myqnapcloud.com/CMPBuild 4227420072 428804268 3798615804  11% /home/pjh/CMPBuild
//cmpdevnas.myqnapcloud.com/home     4227420072 428804268 3798615804  11% /home/pjh/Documents
tmpfs                                   2460612        80    2460532   1% /run/user/1000
shabble.co.uk:                         25140764  17674152    6170264  75% /home/pjh/mnt/shabble
/dev/loop21                               15104     15104          0 100% /snap/gnome-characters/399
/dev/loop22                                3840      3840          0 100% /snap/gnome-system-monitor/127
/dev/loop23                              164096    164096          0 100% /snap/gnome-3-28-1804/116
/dev/loop1                               155392    155392          0 100% /snap/chromium/1005
/dev/loop15                               56064     56064          0 100% /snap/core18/1668

not sure what you’re talking about here tbh, docker has excellent support for persistent data for containers.

what, distro packages for tt-rss? don’t get me started on that. the rest of it is pretty much there already (i.e. no shared hosting, no saas)

as long as you’re having fun with it (you won’t, not after you have to deal with portupgrade a few times) or need zfs (you almost certainly don’t) go ahead, but freebsd is essentially dead.

it hasn’t been relevant for over a decade, forever stuck in 2007 or so. a friend of mine has recently finished, uh, undeploying last remnants of freebsd in a rather large Moscow-based hosting provider.

if you want to run obscure ancient stuff for the sake of it, you might as well migrate to solaris.

Oh, no, I meant distribution provided packages for Apache/Nginx, PHP, MySQL/PostgreSQL, etc. “I’m running Ubuntu, but I decided to try out MySQL beta, and now tt-rss doesn’t work.” None of that.

As for tt-rss itself, git master or go home.

that makes sense, until you get someone running arch. :slight_smile:

Not a big fan.
From a developer perspective I understand your point.
But for the end users/admins who are not used to docker it will certainly increase complexity and I am not sure on whether this will increase problems or questions asked or make things easier.

Would appreciate to continue with syncing git. Was working without problems for me for quite some time…

Since everyone is jumping on the band wagon, I would hate to feel left out: I could not care less if it is docker or vanilla git with sysadmin mojo. If both work, I will stay on the later 'cause that is what I am used to and it works for me. If Fox decides to only support docker, I will move to that. If Fox moves to $whatever only, I will learn that and use it. In the mean time, I will continue to stoke up on fuel, weapons, and provisions expecting the coronavirus apocalypse to start soon…

tbh, I’m clueless to what docker (or Linux containers for that matter) is/are all about at this point so as_long_as I can continue to ‘git pull’ tt-rss to my self-hosted server all is good.

I’ll second this motion.

Actually, this is so tricky and user specific… I don’t like the idea too much, but I completely understand.
The user should have do most to identify problem first and be able to fully reproduce “on brand new distro installation” otherwise should dig their owns. But completely “fuck all non-container” isn’t good idea, by my opinion.

Isn’t the whole point of docker to reduce the complexity?

Depends on your point of view.
From the articles I read about docker it reduces complexity for hosting/web application providers or IT departments with several applications supported by docker.
In this case: yes it does.

When you just run TT-RSS on a VPS and nothing else and have no clue about docker, its dependencys and functionallity or what is persistent and what could be updated etc… I do not think it reduces complexity.

Prsonally I am happy with the git pull, but understand that others might want something simpler. I don’t want the extra overheard of another fpm, php, postgresql running but that is me. I don’t see that having the git pull and then docket container are at odds. we need the base source tree to create the container from. This means to me that creating the container is just a later step in the build process and that this isn’t an either or…

this is completely wrong.

installing via docker is orders of magnitude easier than going through all the motions to install fpm and required php packages, nginx, database server, git clone tt-rss into a correct location, fix permissions, etc etc etc.

let’s not even talk about all the stuff you need to know so this setup has some semblance of security and your host is not compromised in the next 5 minutes because you decided to put something like wordpress in /var/www next to tt-rss.

also, “having no clue” about containerization is not an excuse. go get a clue then. and stop deploying services directly on your host.

Please do me a favor and tell me, how we keep the underlying Docker-Container base image, php, fpm, nginx, … up to date as the process for dong it isn’t “apt-get update”.

we’ve already established that you don’t know what you’re talking about in your previous post itt, you don’t really need to dig yourself further.

also, imagine i probated you for questions you could easily google answers to.