Sighs at the next 229Gb required update to Flight Simulator 2020
Flatpak Is Not the Future
121–130 of 410 posts
Re: Flatpak Is Not the Future
#122My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a…
The (unofficial) JetBrains flatpaks have never worked for me for that reason, I don't know why flatpak keeps them around. I recommend JetBrains Toolbox[0] for managing their IDEs.
Re: Flatpak Is Not the Future
#123This clearly shows how old I am (or have become), it is a (crappy) calculator:
>Note that the app package itself is only 4.4 MB.
Calc 98 is huge at 495 KB:
http://www.calculator.org/download.html
Xcalc (RPN) is around 200-240 KB:
Re: Flatpak Is Not the Future
#124Earlier quoted context omitted.
The .deb file should remain where it was when you downloaded it, dpkg just installs the contents of the .deb file.
Where is the contents of the .deb files put?
--root=dir
Set the root directory to directory, which sets the
installation directory to «dir» and the administrative
directory to «dir/usr/local/var/lib/dpkg».Re: Flatpak Is Not the Future
#125Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…
> There's no way you can make a software run on all systems without requiring at least some infrastructure. Do you want your 64-bit AppImage to install everywhere? To bad! it requires 64-bit glib to be installed.
Distributing applications with multiple architecture binaries and the correct one selected at run time is a solved problem. The original MacOS did it as far back as the 68k/PPC transition and the concept has been supported by NeXT/MacOSX Application Bundles since the beginning.
Re: Flatpak Is Not the Future
#126So Linux desktop is dead and MS wins it after all?
"Why do people continue to not use our glorious FOSS Desktop solution that can't even handle simple application management without a hundred different tools?"
People who desire to see more widespread Linux Desktop usage will some day have to come to terms with the original conception of the phrase "The customer is always right". If you continue to ignore what people want, don't be surprised when they don't show up.
Re: Flatpak Is Not the Future
#127I think this article is not providing adequate alternatives.
Most programs link against quite a bit more than libstdc++ and you clearly can't expect users to install a bunch of packages to get their program running. Those extra libraries usually take up most of the space in a package. If you include all the shared libraries you need, apart from the system libraries in your distribution, you pretty much have an AppImage already, just as a tarball instead of a squashfs image.
I think GOGs path is not horrible, but it is much less effective at making Linux a viable alternative as a gaming platform. They literally only support Ubuntu 16.04 and 18.04.
It also struck me as odd, that the author was complaining about the complexity introduced by Proton. What is Valve supposed to do?
Re: Flatpak Is Not the Future
#128> How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game? If the steam runtime didn't exist, most gamedevs would only target the most popular distro - probably the current Ubuntu LTS, and you would have to…
And realistically if they could only target a single distro, they would likely not bother making Linux builds at all.
Re: Flatpak Is Not the Future
#129Earlier quoted context omitted.
Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.
A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.
Is that bad because you don't have the space to store it or is it bad because you don't like it in principle?
If its the former then its a non issue. Storage is cheap and plentiful and code takes up little space relative to other assets such as multimedia content.
If its the latter then I don't know what to tell you other than practical issues are more important than style ones when making practical software. The community has voted and decided that classic package management doesn't cut it and easy of installing software is important.
And I have to agree with them. Time and time again we've been shown that friction to users doing whatever it is they want is the biggest barrier to adoption. Its easy for tech types like ourselves to get stuck in the weeds of the computer. But to most its a means to an end and if it isn't facilitating that then they will find another.
Re: Flatpak Is Not the Future
#130So Linux desktop is dead and MS wins it after all?
It hardly had a chance thanks fragmentation and hard core beliefs in compiling everything from source, up to around 2005 I was still a believer, nowadays I don't care.