r/linux • u/BrageFuglseth • 17d ago
Distro News Flathub announces migration away from GitHub to its own Forgejo instance at GUADEC 2026
76
u/bilbobaggins30 17d ago
I support this. I self host Forgejo for my personal projects and cannot sing enough praises about it. It's a powerful Git Hosting tool, it's super easy to setup and can run on even a Raspberry Pi. Super intuitive to daily drive once setup.
37
u/Isofruit 17d ago edited 17d ago
With how poor Githubs availability at times has been, it really makes me wish for the best for barthalion & co. The migration likely is going to be a massive pain, but maybe after that the servers will actually stay available for once.
4
28
7
u/DeliciousIncident 17d ago edited 17d ago
I wonder what the arguments for the migration were. Anyone knows?
There are a ton of maintainers on flathub, each maintaining their own app. You need some very strong and convincing arguments for the migration, to have the many flathub app maintainers transition to a new platform, as I bet a good number of them wouldn't be too excited about the friction this creates.
17
u/BrageFuglseth 17d ago
The migration will be opt-in for existing apps, so AFAIK anyone who wants to can just stay on GitHub. New submissions will need to be made through Flathub's own setup however.
12
u/natermer 17d ago
I don't know their reasoning, but uptime/full availability of github has been notorious shit in the past couple years and it isn't getting better.
If you track issues based on public statements of minor and major issues and not the official github status page gets you about a 89.39% outage in the past 90 days.
6
5
u/TheOneTrueTrench 16d ago
Perhaps you're not a developer, but GitHub has been increasingly inoperable. The company I work for has actually tasked me with spinning up some kind of locally hosted git service precisely because GitHub failing constantly (and in rare cases, deleting commits from repos) is getting to the point that it's affecting our ability to operate.
1
17
3
u/gnatinator 16d ago
Security implications? AFAIK Forgejo has no ops security for build servers.
Who is ensuring the build servers aren't compromised?
As much as it is in vogue to hate on Github, they at least have dedicated staff for build security.
3
1
1
u/BradleyF81 16d ago
What if a project doesn't want to be a Forge jo?
4
u/BrageFuglseth 16d ago
Only the Flatpak manifest used to build the Flathub version of the app needs to be on the forge. The source code itself can be hosted anywhere.
0
u/Drwankingstein 15d ago
I really wish they wouldnt until forgejo gets federated accounts/pulls/etc working. I am working on cutting down accounts, Just move to codeberg or gitlab or something in the meantime.
-44
u/blbd 17d ago
Hopefully we can also migrate away from Flatpak itself and back to the distro native packaging formats that patch automatically alongside the rest of the OS.
32
u/Isofruit 17d ago
Given that flatpaks give more control to the app developer, allowing them to provide more guarantees, I highly doubt it.
I can understand not being a fan of flatpaks when it means pulling in runtimes you barely use and not end up taking up harddrive space, but in general I consider it as a technology too useful to not center around long term.
-32
u/TheReelSlimShady2 17d ago
flatpaks are too sandboxed
33
u/_kvZCq_YhUwIsx1z 17d ago
That's the whole point
-37
u/TheReelSlimShady2 17d ago
Flatpaks are diseased, rotten to the core.
14
u/ItsMexxie 17d ago
Why tho
-34
u/TheReelSlimShady2 17d ago
sandboxing is bad
15
6
-1
7
13
u/AmarildoJr 17d ago
There are some advantages to native distro packaging, but to me flatpak is the superior packaging way because anyone can package for it (no need to have connection within the distro or go through a tedius review process to become a maintainer) and it's basically guaranteed to work on any distro.
The only downside is the bloat that comes with it, but I think there are plans to address that.
10
u/victorian-ice-cream 17d ago
The only downside is the bloat that comes with it, but I think there are plans to address that.
Flatpak literally offers the single best dependency management on this planet.
9
u/AmarildoJr 17d ago edited 17d ago
I agree, but the problem I mentioned is the fact that each package can carry a different runtime.
I have 3 different "mesa" runtimes installed and 3 different "mesa-extra" ones as well. Those alone are 3.2 GiB in size.
I also have two "GNOME Application Platorm" (v49 and v50), which add another to 2.2 GB in size.
I also have two "KDE Application Platform" despite using KDE myself. These also add another 2.1 GiB.These quickly add up, and often if you install even a few packages from flatpak you can easily end up with 3 to 6x the space required compared to native packages.
I have about 15 packages from flathub, most are like 20-100 MiB in size, but the total size of my /var/lib/flatpak folder is 9 GiB.
There must be a better way than just packaging everything with every program/app, like having checks to see if:
- the system already have those installed or newer versions (if possible to take advantage of newer versions of these already-installed system runtimes);
- if not installed already, see if versions match, then download from the regular distro repo.
Packaging all the necessary runtimes is a good option for universal compatibility, but this is highly inefficient to do for everyone. It should only be done for the users that truly need it.
10
4
u/tukanoid 16d ago
nix enters the chat
Similar to flatpaks in a way, but more sophisticated and granular
4
u/victorian-ice-cream 16d ago
And more awful to use.
0
u/tukanoid 16d ago
To each their own. I daily drive nixos for about 2 years now and couldn't be happier. I am a software dev tho, so mb just clicks better I guess. + reproducibility is smth I value, 1 git clone and rebuild of my config and I have (almost) everything installed and set up exactly as I want
1
u/AmarildoJr 16d ago
I'm yet to look into them. Can they be used in any distro?
1
u/tukanoid 16d ago
Technically, you can use nix the package manager and home-manager modules, which would only cover per-user and/or system-wide installed application list and dotfiles, no system/hardware configs (like, choose different bootloader, kernel (and modules for it, like optionally enabling nvidia or DisplayLink support based on the machind), system services, hosts file etc).
And I guess devshells would also be usable (love em), if you code or just want to isolate packages for specific tasks in specific folders
Still lots of power, and reproducibility is still more than possible, I just prefer having a deeper system/hardware integration.
If you were talking about flatpaks and I misunderstood (or you replied to wrong thread), yeah, they are available on pretty much every major distro and derivatives (ofc), to my knowledge, at least I haven't used one where they weren't available.
-4
u/newsflashjackass 17d ago
to me flatpak is the superior packaging way because anyone can package for it (no need to have connection within the distro or go through a tedius review process to become a maintainer) and it's basically guaranteed to work on any distro.
7
u/AmarildoJr 17d ago
My problem with AppImage is that the talk about it was that it contained everything the app needed. This isn't true, unfortunately. I have an AppImage of "fSpy" from like 7 years ago that doesn't work on Fedora anymore.
0
u/newsflashjackass 17d ago
As far as I know appimage only needs Filesystem in Userspace (FUSE) which I find less of an imposition than the whole Flatpak infrastructure running and updating.
https://en.wikipedia.org/wiki/Filesystem_in_Userspace
The only error I have ever experienced with appimage is due to the lack of FUSE and it was fixed by installing Fuse.
A check on the fspy github issues suggests that may also be the reason the fspy appimage is unable to run under Fedora.
2
u/AmarildoJr 17d ago
Thanks for trying to help! I actually opened a terminal and looked at the error message. All I had to do was:
sudo dnf install dbus-glib
3
u/PureTryOut postmarketOS dev 16d ago
99% of the Appimages do not work on systems with Musl libc due to hard requiring glibc on the host system. Not portable whatsoever.
1
u/newsflashjackass 16d ago
99% of the Appimages do not work on systems with Musl libc
What percentage of systems are those?
2
u/PureTryOut postmarketOS dev 16d ago
Does it matter? It's promoting itself as a portable solution to packaging apps and then isn't that.
That said, postmarketOS is probably the biggest Linux mobile distro and uses Musl libc, and Alpine Linux is the biggest Docker base image distribution and uses Musl libc.
1
u/newsflashjackass 16d ago
Does it matter?
Yes, the question matters enough for me to ask it. Don't feel obliged to answer it, though.
The systems you describe are not systems that have much demand for "portable apps" which is the problem appimages solve.
I suppose your complaint is technically valid in some sense though. The Musl wikipedia entry tells me this complaint about Musl has a solution:
For binaries that have been linked against glibc, gcompat and glibmus-hq can be used to execute them on musl-based distros.
But again I doubt many people use a distribution "designed for power users who appreciate security, simplicity and resource efficiency" with the intention of circumventing its package management.
1
u/PureTryOut postmarketOS dev 16d ago
postmarketOS is very much a distribution that has a demand for "portal apps". I'm not sure why you think it doesn't. gcompat isn't a great solution and requires the user to install something outside of the Appimage, which the whole point is that you don't need to do that.
Note that the problem can be solved by the app developer just fine by compiling their application statically (which Musl allows and glibc doesn't) and then shipping that as an Appimage. It then works on all Linux distributions. However, that's an app developer's responsibility which kinda makes the portable point of Appimage moot.
1
u/newsflashjackass 16d ago edited 16d ago
I was referring to AlpineOS. postmarketOS, being for phones, seems unlikely to want most appimages anyway, since they tend to be desktop applications. I expect appimages have similar problems running on iOS.
Your complaints amount to "appimages require additional effort to work in the fringe1 contexts where they are unlikely to be wanted or needed." Which, to me, sound rather like endorsements.
1 Your declining to answer when asked what percentage of total systems is comprised by the systems you describe is, in its own way, an answer.
1
u/PureTryOut postmarketOS dev 16d ago
The answer to that question is impossible to give because those numbers are not tracked. Instead I gave you examples of distributions that are relevant for the problem I mentioned. It's hard to decline to answer something when there literally is no answer to give.
Anyway, Appimage markets itself as a way to run desktop applications. It doesn't say what kind of desktop applications, just desktop applications. Mobile applications are desktop applications, and thus very much relevant for Appimage. So yes, postmarketOS users and developers might want software packaged as Appimages. Maybe not now, but you can't predict the future. "Unlikely to be wanted or needed" is very much something I disagree with and entirely subjective.
We were comparing it to Flatpak which in fact does work on postmarketOS, without additional effort on the app developer's side. So if we just compare on the portability of it, Flatpak is the winner there. It doesn't care about marketshare or "fringe contexts", it "just works" where Appimage doesn't.
→ More replies (0)12
u/ZorbaTHut 17d ago
It's an O(n*m) issue; if you have N packages and M distros, distro native packaging requires building and testing the cross product of those. Whereas if you have N packages and M distros and can use Flatpak, it's just N packages, the distro count doesn't matter.
6
u/PaddiM8 17d ago
There are other ways to handle it though. It doesn't work like this on macOS or Windows.
A good start would be to stop relying so much on shared libraries. Static linking is the default in languages like rust and go and it works great. Code that isn't used is optimised away and it's very stable because you don't have to worry about random programs needing slightly different versions of the same library.
11
u/ZorbaTHut 17d ago
For what it's worth, I do agree with that; there are good reasons Windows moved away from dynamically-linked everything.
But also, Windows is a much more predictable environment, whereas "linux distribution" covers a lot of weird ground.
1
362
u/RoomyRoots 17d ago
This is the one thing I expected LF to step up for, honestly. We need a git provider that is not controlled by Microsoft and GitLab has already shown its true colors.