Will YunoHost be able to keep up with all updates?

Hi there,
I am still relatively fresh and use YH now for 2-3 weeks. The goal was to replace a self-operated Docker server and to have the whole administration a bit more comfortable.

In practice, however, I notice that integrating new apps and keeping existing apps up to date is very slow. Current example is n8n. The app has received numerous updates and security fixes. But for over 6 months the app has not been updated.

Please do not take it badly. I am aware that this is all done on a voluntary basis. But I ask myself how realistic it is to keep the project healthy, if there are even more apps. Is this scalable?

I’m thinking about going back to Docker setup to be able to test new apps that YH doesn’t have and also do timely updates and security fixes myself. On the other side, I love the idea and comfort of YH.

2 Likes

Welcome!

Will YunoHost be able to keep up with all updates?

Over time, yes. If your software model is to be always on the bleeding edge of new versions, then yes, that might conflict with YunoHost adding a variable latency, depending on the app.

But I ask myself how realistic it is to keep the project healthy, if there are even more apps. Is this scalable?

We develop automated update processes to minimize the time needed on app upgrades.
However, the human hand is oftentimes required. Volunteers, as always, are most welcome if you can find some time to give back to the community. :wink:

1 Like

My experience with YunoHost vs work :
YunoHost can be quite slow for certain apps to upgrade, but anyone with some knowledge (very few for simple upgrades) can help the whole community and upgrade the git repo (by posting a pull request).

At work, we have years old outdated computers, because all is done by hand and we do not have enough time for all of them.

So, yes, YunoHost can be late, but less late than some servers managed by hand :stuck_out_tongue:

PS : I’m using YunoHost for years

4 Likes

Fully understand this. But I would say, there’s a lot of room between being always “on the bleeding edge of new versions” and the current state. I do not have so much examples, but for n8n, like mentioned in the first post, we’re talking about a huge gap of 6 months. The current n8n YN version is 0.221.2. The current version of n8n itself is 1.9.3. That’s not even close :wink:

Is there a documentation how to doing this upgrade pull requests?

Very good point!

I went to take a look at the documentation for packaging apps in English at:

…but it only shows in German even though the other pages are in English, and there appears to be an English translation at https://github.com/YunoHost/doc/blob/master/pages/06.contribute/10.packaging_apps/packaging_apps_intro.md :thinking:

1 Like

Yes: GitHub - YunoHost-Apps/n8n_ynh: n8n package for YunoHost, and surely somewhere in our own documenation.

The file was misnamed. It’s fixed now, and will soon be synced to the website.

2 Likes

Hi everyone,

I face the same predicament with dotclear2. I am willing to assist but I need to be trained. Is there a way by which the most senior people in supporting YNH could train people like me so that I could in turn assist others, and do what cannot be done due to lack of hands ?

I have no idea about the numbers involved ? Is the YNH community a matter of tens, hundreds or thousands or miilions (I guess not) people ?

I have time. I have some knowledge. I can spend time and money to travel. I am ready to invest my resources in order to assist. But I need training.

Could the community think of a way to do this ?

WBR,

Q

2 Likes

For dotclear2, it seems that a bot can do the upgrade by itself, but the last upgrade failed so it may need someone to look into it : Upgrade to version 2.27.3 by github-actions[bot] · Pull Request #68 · YunoHost-Apps/dotclear2_ynh · GitHub

For many applications, the upgrade process is the same : a link to the new version (have a look in this example), then a bot will test it (install it, install an old version and upgrade it, remove it, many things…) and then a human can approve the pull request.

And of course, you can upgrade an app on your server with the pull request you just did, so other people will not act as a test subject :wink:

1 Like

Not trying to be provocative but I think we are doing pretty good compared to how many contributors there is.

14 Likes

And to also complement eric : it’s a bit weird that everybody in system administration seems perfectly normal to literally “reinvent the wheel”. In programming, anybody re-coding what’s already done in 10 library will be thought of as a madman, yet in the self-hosting community, it seems perfectly sensible for everybody to re-setup pretty much the same stack, all with the same pitfalls, until ultimately people will get “tired of maintaining their stuff” and give up. At the same time, people will argue that it is “cool to learn” and “better to know how your stack works”. Sure, re-implementing an HTML parser by hand is cool, and the lesson learned is usually “that stuff is way more complex than it sounds and I should definitely use as many libraries as I can in my life rather than wasting my time solving what’s already solved by other people”.

Yet sure enough, people think they can just easily set up their own server by just spinning a few docker, without realizing that the full life of a server is also : certificates, backups, fail2ban/security, upgrades, front-end server / reverse proxy, dns configuration, monitoring/diagnosis, and a shitload of time debugging countless boring micro-issues …

In the end, if every person implementing their own self-hosting stack in their own corner contributed 2% of their time to any sort of “common” self-hosting stack that anybody can easily setup and maintain, we would live in self-hosting utopia since quite a while. Instead, quite a lot of people are like “I tried X and Y and Z but none are perfect so watch me spend 3 weeks setting up everything by hand myself and giving up 8 months later” ¯\_(ツ)_/¯

9 Likes

Having used YNH for 2 years now, for everything, I do understand the want or need for constant upgrades, but personally I find it annoying sometimes…! If it’s working then leave it alone except if there is a critical security upgrade. The amount of times I’ve done an upgrade and its failed… Hate that. Jeeez!!!

1 Like

It also depends in “how niche” an app is.

My main motivation to pick up self hosting again was to have my own fediverse instance.
After a decade hiatus of having my own server, because of not trusting myself to be able to secure it I was glad to have my own server again with Yunohost. BUT:

Mistake 1:
Instead of installing Mastodon I wanted something small, like Pleroma (thats more niche in some ways). But development of Pleroma seemed slow so I choose a fork: Akkoma (thats even more niche). But de YH app for Akkoma has 2 bugs. You loose the webinterface for the configuration client and now also I cant attach images to toots. I cant fix this myself, no community to maintain it, just one volunteer (Lapineige for which I’m gratefull).

Mistake 2:
I wanted a personal GPS tracker and instead of just an app with local GPX file storage I wanted something online, so I choose OwnTracks. Turns out the YH app package uses a really old version which has NO EXPORT function. Changerequests get no response on the forum here and on Github neither. So now I cant get my data out of my own webserver. Not with my skills anyway.

My conclusion: Yunohost is really great to have a reasonable secure webhost server for MAINSTREAM apps with a community big enough to have more than one person maintaining YH apps.
Otherwise the app stays behind forever.

3 Likes

@webserviceXXL I’ve been using Yunohost for more than 7 years now. My apps aren’t at the “bleeding edge” but all of them are working perfectly well and most of the time I don’t even bother upgrading them, unless I have heard of a new feature I really need.

What I can tell you that with the great work of packagers and contributors, the upgrades have been faster and faster over the years. I remember being stuck with Nextcloud kept 2 major versions behind the official release for more than 1 year because of a complicated major debian version transition. Was it a problem ? Honestly, no… Now, Nextcloud packagers even start their work before the official release !

Except for a few very difficult apps such as Nextcloud, most of the apps are very simple once you have understood the general concept of what is a package. Building an app is not very simple and can be time consuming but maintaining an app is impressively easy ! It’s often a matter of a less then 10 lines pull request and 10 minutes testing with the CI and ideally on your own test server.

I would say that the danger is getting greater if you start installing and using very niche apps, as stated above. You could come up with a situation where the packager has decided not to put any more energy on it.
In such case or if you want to be on the “bleeding edge” then the best is to be the packager of the app :smiling_face:

8 Likes