41–50 of 117 posts
Make it executable
$ chmod a+x Subsurface.AppImage
and run!
$ ./Subsurface.AppImage
That was easy, wasn't it?"
No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?
"To run an AppImage, simply: Make it executable $ chmod a+x Subsurface .AppImage and run! $ ./Subsurface .AppImage That was easy, wasn't it?" No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?
"To run an AppImage, simply: Make it executable $ chmod a+x Subsurface .AppImage and run! $ ./Subsurface .AppImage That was easy, wasn't it?" No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?
You need .desktop files in /use/share/apps
All other major operating systems (can) work like this; download something > click it > it works. No need to launch terminal, set executable permissions and type the name of file.
Video introduction to AppImage (linked on the AppImage website): https://www.youtube.com/watch?v=mVVP77jC8Fc Also, a side point -- is it wrong to want people to spend more energy on building fat binaries? To me they are the ultimate in portability (by definition), and investing in projects like musl libc and distributions like alpine, languages like go and rust that build portable static binaries is so much more acce…
What if another heartbleed happens? Wouldn't it be better to update a single shared library?
Also shared libaries assumed your software will work on a different version of a library which is quite a bold assumption that may or may be true depending on the phase of the moon
It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single u…
Private developer wants to distribute binary + shared dependency libs. On Windows they package it into an installer which unpacks it into the target destination & everything works. On MacOS the user gets a folder that acts like file within which everything is stored. Additionally there are reliable releases so something targeting a minimum of MacOS 10.14 has a reliable way to specify that in the toolchain & know that…
I see that as the biggest net win of the current system although it may seem inefficient or bureaucratic. I do not trust the authors. The only modicum of sanity and trust comes from the fact that debain/fedora maintainers are actually on your (the user's) side and have strong rules and guidelines about everything. Desktop linux doesn't have that much meaningful isolation or sandboxing that malicous apps cannot circumvent. It's only now that we are seeing some efforts in this direction. Still, it's quite far from something like android where you can quite safely run arbitrary applications.
It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single u…
I don't believe it was "solved", and I don't believed it was caused by people "moving fast and breaking things".
Linux became HUGE, in terms of the number of people involved, and there is no master body that would govern anything. As an application developer, you could build against libfoo, then your app break on debian because they never updated libfoo besides some strange monkeypatch, and be broken on redhat because they decided to fix bug #12494 differently from the developers of libfoo.
God himself has decided it's too hard, too complex and too much of a clusterfuck of competing motivations to expect that RedHat/Debian/FooBarLinux will reliably all provide the same shared library. And the user doesn't case, bandwidth the cheaper than disk, and its most certainly cheaper that user's time.
So know what you are paying with.
It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single u…
Libcurl is the only one I frequently use that seem to take it seriously, there might be others but frustratingly few will indicate what level of binary compatibility they guarantee, it would be nice to have a list of reliable libraries. Not just for binary compatability but I would be nice to know how much churn you can expect with any given library.
On the other hand, considering the state of the software industry with relation to privacy (including some open source products) running software from arbitrary sources is becoming less and less viable anyway, I'm not sure it's a problem worth fixing.
- Fixed social media share buttons that cover the text on mobile
- It auto-translates to German even though my system language is set to English (seems like they use geolocation for this which is bad practise)
- Center aligned text that is annoying to read
Earlier quoted context omitted.
I'll bite. I ship the Mailspring email app on Linux and I prefer Snaps as an application developer. The big win is that the snap system provides automatic updates for packaged apps. You publish the build on Snapcraft and 24 hours later everyone on all linux distros has it. I cannot understate how incredible that is as a developer. I used to burn a lot of time investigating issues that users reported on Linux only to…
Interesting, very similar to Android app store. The concern though is what if your new release break something and this was a really bad time for the user? Can they temporally revert to a previous version?