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).
$ 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. 
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.