Appimage instead of pnd?


Why is it an "interesting discussion" if everything is mentioned in the one by slaeshjag already? The AppImage software has already been dismissed, so what's there to still discuss? Everything you seem to do is to split the slaeshjag thread for no apparent reason.
(Sorry for linking it a third time, but it's a lot more informative than this. Not to disrespect Maschinenherz, it's definitly an interesting question if you don't know about .dbp, but all of the questions that could come up are already answered or could be answered there for reasons of organisation and looking up for newbies.)

You said yourself:
The wiki is there for a reason, would be a good idea to start using it :)

The others might have a lot of dependancies which cost space and need a daemon to run which can cost cpu time as well!

Best to keep it simple :)
So why isn't that the whole discussion? Any other upcoming problems could be directed to slaeshjag or, at best, be provided as improving code to him. The more you go on here, the more it's getting split. And trust me, if you don't have an account and threads aren't getting flagged as "already read" and you have to remember every single title of what you've already read, it's hard to keep up with every new responses to every thread. Splitting a discussion from an already stickied one is a big deal for unregistered lurkers.
 
The thing about AppImage, is we don't need to implement it. It can be used on the Pyra as is. So if people want to use it they're welcome to, but DBP is probably a better fit.
 
You're obviously new around here. ;)
*I thought AppImage was a closed source program from just seeing the binary downloads. Sorry about that, I somehow thought it had to be requested to be used (just seeing a "Try this" button apparently makes me think this way). So, yes, the fact it's an alternative to the DBP system which is also open-source of course makes it a lot more interesting.

I take back pretty much everything I said in this thread - I'd still like to see more of the .dbp discussion on the actual thread, but as this one drifted away from that, there's nothing more to reply for me than:

I'm sorry, I didn't want to interrupt your discussion!

(And no, I'm not new around here, I've been a lurker for more than 5 years, this was just an alcohol-fueled misunderstanding - after all, it's almost 4am here and I don't have to work later today :p)
 
I believe it's the former, but @slaeshjag would know better than I would.
What Trashy said.
[doublepost=1464163078,1464161806][/doublepost]Just because fun, lets point out some shortcomings of AppImage, from what I can tell.

No provided mechanism for handling it in a package manager or including metadata. I'm sure they could add it easily, but they haven't. If there's a new version released, it's up to the user or the program to detect this. This is kinda bad imo, but most probably by design. One of the key goals of AppImage seems to be that you get your releases directly from the author, not from a middleman like a software repository. Indeed, the version and name of the program is only ever saved in the file name of the package...

This whole idea of "just double clicking the binary" means by default you can only have one launch action. I can't tell if it supports more than one desktop launcher, but the prefrered way of using it seems to rule it out.

The creation of a menu entry at launch seems like a rather static thing. What happens if you move the file? Or download a new version (with a different filename!) and rename it? Suddently your mime type assosiations won't work again until you've launched the new version!

I can tell they all had good intentions when designing this system. They wanted something easy that was easy for developers to start using. They wanted something that required very little infrastructure to work on unmodified distros. They hate the idea of a centralized repository. From these design goals, they did a pretty good job implementing it. But their core design decisions feel very last millenia. Manual version handling or hacky built-into-the-application version handling is not part of the future. I could go on about how I would change their system while still kinda sorta fitting their design goals, but I think that's mostly irrelevant.

EDIT: They do have some weird repository system that tracks versions without having any metadata in the package... I'm not sure what I feel about that...
 
Last edited:
I dont feel disrespected ;)
I just saw it on a linux board where somebody asked for a none-wine solution for the apps from portableapps.com. And it reminded me slightly of the pnd system. As i read many moons ago if a replacement, it popped un my mind as possibility to think of. And you pointed out the problems i have missed. (I just saw it on break on work and just posted before i forgot).

For me it is= appimage could be nice, but has its flaws that make it unsuitable for a replacement.

On the other side it makes me very happy to see what work is already done an makes me just waiting to habe a little more money on hand to preorder the pyra :)
 
If DBP did not exist, I would support just using AppImage to help that gain traction in the greater GNU/Linux ecosystem.

Well, I'd never use AppImage on my desktop Linux. It won't gain traction on top of my system.

I'd use FlatPak tough: http://flatpak.org/press/2016-06-21-flatpak-released.html

Take a look. You might like it.

And I'm not sure FlatPak would work on Pyra. FlatPak requires Wayland and it's built on top of a more secure design. I think these designs might contradict some of the DragonBox Pyra values/manifesto (I don't know). I'm just pinging here because I found FlatPak interesting.
 
Well, I'd never use AppImage on my desktop Linux. It won't gain traction on top of my system.

I'd use FlatPak tough: http://flatpak.org/press/2016-06-21-flatpak-released.html

Take a look. You might like it.

And I'm not sure FlatPak would work on Pyra. FlatPak requires Wayland and it's built on top of a more secure design. I think these designs might contradict some of the DragonBox Pyra values/manifesto (I don't know). I'm just pinging here because I found FlatPak interesting.

I have been aware of FlatPak (from before its name change) and my attitude now is the same as it always has been: "nice, but it is not ready yet". The sandboxing aspect is unfinished. In the meantime, AppImage, which does not require new software installed (not even Wayland), is better for now (and may have sandboxing in the future, according to its author -- though probably only when using Wayland). Its lack of dependencies means that it does not need traction on any one system, only wide use in the community for recent releases of non-system software without dependency-hunting.

Once FlatPak is finished with respect to sandboxing -- and so, necessarily, once Wayland is the de facto standard -- and once its helper software is about as standard as ld-linux.so (in every desktop distribution), then, and only then, would it be a straightforward improvement over AppImage.
 
Once FlatPak is finished with respect to sandboxing -- and so, necessarily, once Wayland is the de facto standard -- and once its helper software is about as standard as ld-linux.so (in every desktop distribution), then, and only then, would it be a straightforward improvement over AppImage.

It depends on what you call an improvement. Like I said, for me, AppImage is a big no.

I don't see why to have a package manager if I don't use a package manager. So this is it, I exclusively use the package manager from my distro to manage software. I won't change that unless there is a compelling reason and portable binaries that aren't updated automatically and will accumulate know bugs/security-holes over time is not an improvement from my eyes.

FlatPak has a clear improvement for me: security. This is what I want. For Pyra I mostly don't care. For my main system, AppImage is a big no. And the usage of ISO9660 seems hackish... like whatever thing that works (no matter if it's slow or whatever).
 
The Pandora's PNDs used iso9660 images at first too (now it supports those as well as squashfs images). I don't know yet what the DBP system uses - I should really get round to cloning that repo and having a play.

But the DBP system will also exhibit old software hanging around in the repo as the Pandora's PNDs do, and it may be more significant as I'd expect Debian to evolve further during this CPU board's lifetime (or a compatible future one) than Angstrom did. Not sure how long the support window is for the Debian release we'll be using is, but I at least tend to use my machines for longer than that and need to do a dist-upgrade at some point, which will risk breaking old code (though that risk does tend to be overstated for games that just depend on SDL and an input library).

But the DBPs isolations are necessary when you have them on removable media. I understand they do support some sort of dependency implementation as well, but I don't know if that tried to interact with the apt system (it'd probably be better if it didn't for portability's sake anyway)
 
The Pandora's PNDs used iso9660 images at first too (now it supports those as well as squashfs images). I don't know yet what the DBP system uses - I should really get round to cloning that repo and having a play.
squashfs
 
i thought i'd link an opinion piece about AppImage vs. FlatPak vs. Snaps:
http://distrowatch.com/weekly.php?issue=20160704#opinion

we'll have to notify them that there's a fourth alternative, the DBP :)
The DBP system is so custom tailored to the use-case of a handheld with lots of removable storage, that I don't think it'll fit much else. If I were to do a system for distributing binaries to desktops, I'd change a whole number of things in the design.
 
i thought i'd link an opinion piece about AppImage vs. FlatPak vs. Snaps:
http://distrowatch.com/weekly.php?issue=20160704#opinion

we'll have to notify them that there's a fourth alternative, the DBP :)

Thanks for that. I was expecting better of FlatPak, but it is still early.

The article also led me to to discover Firejail, which can be used (with or without AppImage) as a sandbox. I cannot comment on its efficacy, but its user interface is pretty nice, claiming no dependencies but a relatively recent (post 3.0) Linux kernel. I intend to play with it, later. It may be useful for the Pyra too, perhaps with programs that use the phone modem.
 
That doesn't make them bad, just not as secure as advertised.
Besides, isn't Pyra planned to run Wayland anyway?
 
Back
Top