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.
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.
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
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
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.
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
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ā ĀÆ\_(ć)_/ĀÆ
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!!!
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.
@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
I would add that in many cases, without Yunohost you wouldnāt have installed anything, or your would have taken forever (longer, at least) to upgrade because of the time and knowledge required. I mean, itās not targeting mainly very tech-savy people .
Yes, there are different tools that have less āupdate latencyā than Yunohost. If the trade-off if better for you (because they do not offer the same thing as Yunohost), then maybe itās better in your use case to go for it than for Yunohost
What I mean here is that yes, update latency can be an issue, and painful sometimes, yet I also want to emphasize that you are choosing your dependency : either to you alone to maintain your server and apps, or to Yunohost, which mean the community effort of other people (but you might be part of it too ) to do the work for you.
Around 10,000 Yunohost servers (according to Shodan).
We are basically doing it all of the time, in matrix channels, the forum, githubā¦ with some limited ressources
For now it requires quite a significant amount of āself-taught timeā, using the documentation, existing app or the example_ynh one, yet we provide some support and guidance if needed and possible
Also we are working on an āapp package generatorā to ease the process of creating a new app, it could help in the future
Thatās so true.
(Major) Debian version update, major Nextcloud updatesā¦ used to be take a lot longer to be ready.
Yes, thatās a very important point.
Many apps (updates) only require someone to change the source files URL, test it, and then itās done
Itās always a good start
Bonus point for that case: itās not even that itās that much niche (contributions number are not that correlated to software popularity), it thatās the issue are very difficult to solve and require very advanced knowledge. Combined with the quite niche status, it means no contributor whoās able to fix it for now.
@joeldebruijn Yeah humā¦ about this appā¦ I plead guilty. I was a naive young packager that thought could patch and maintain a fork of a seemingly simple app. Back at the time there was little to none alternative in the catalog so I went for it.
Turns out app maintainance is a tad more complex than package maintenance (and it can itself be complex).
So Owntracks for YunoHost now has little in common with the actual app upstream, and needs a huge overhaul to allow upgrades and preserve data (which Iām not sure Iām capable of, regarding database export and tables management)
Would it be worth creating a Discourse poll and/or Fediverse poll to gauge interest in a training session on how to contribute to Yunohost (for coding, documentation, translating, etc.)? And if yāall get enough interest to make it seem worthwhile then maybe there could be one?
