Appimage instead of pnd?

[levi]

Ah bless. It reminds me of the early days of the public internet for someone to consider 'crappy' to be an attack of any sort

To be fair though, Wally didn't explain why it's a worthwhile system beyond 'it works really well', but I don't see why he should to be honest. Others have already said what the appimage system is lacking versus dbp.

 

[Wally]

What Levi said,

The wiki is there for a reason, would be a good idea to start using it

 

[Maschinenherz]

I did not want to start en argument. I was not aware of the current state of the pnd replacement. I just saw appimage as an answer in another board and it sounded interesting to me. -.-

 

[Hồng Thất Công]

160 now but containing over 500 games.



NOT TURNING BACK. slaeshjag has worked countless hours on the DBP system, it works really well and will continue to use it for the life of it.

You guys can use your crappy packager app, have fun with it.

Give you a warning point for not getting my joke. Of course DBP is the way to go.

 

[Wally]

I did not want to start en argument. I was not aware of the current state of the pnd replacement. I just saw appimage as an answer in another board and it sounded interesting to me. -.-

Yeah its interesting there could be support for multiple types of packages, although not likely. DBP is very fast though, pretty instant open time and not many dependancies.

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

 

[Maschinenherz]

Yeah. Thats also my opinion. I dont think that support for more packes systems is a good idea. It sounded very simple to me. But i didnt know how you could handle dependencies ( i just flew over the artikel on work )

On the other side did i not think over appdata folder. Menu integration. Because of this i left it here for you to discuss. If it had been a good thing, it could have saved time and work. And while being a linux beginner and no programmer, it was a opportunity to contribute something

 

[Yoyobuae]

So its just using C instead bash for the header? Right, totally different.

Both can be directly executed. But AppImage can also be directly mounted. So at least that's one difference.

One other thing AppImage has in it's favor is the tools provided to facilitate the creation of AppImages.

Actually, how much can the DBP format do that AppImage can't ? How much is due to the daemon ?

The features that the daemon provides are exactly why it is a better match.

If you write a daemon for AppImages which provides same/similar features then that could become an alternative. But why do that when all that work was done for DBPs already?

 

[TrashyMG]

One other thing AppImage has in it's favor is the tools provided to facilitate the creation of AppImages.

Well that seems like something really easy to rememdy for DBP, making them currently is pretty trivial on it's own.

 

[Yoyobuae]

Well that seems like something really easy to rememdy for DBP, making them currently is pretty trivial on it's own.

I meant that in the context of the "shell scripts+appended data VS appimage" discussion.

 

[Haraldur]

One nice thing about AppImage, as I understand it, is that there is no need for support: if you want to distribute your Pyra software in an AppImage, you can and it will work. You would need to produce a different appimage from the one you produce for your x86_64 machine, though.

If DBP did not exist, I would support just using AppImage to help that gain traction in the greater GNU/Linux ecosystem. From what I see, what DBP saves the user from is a few mouse clicks (unless the files are on a filesystem without an executable bit -- how does one fix that?).

 

[elw3]

You still need to solve how the icons get into you menu or where to place preview pics. You dont have those with this system.
Also in case of PNDs you can also use them anywhere, just not on double click, you need to extract it first.

 

[TrashyMG]

You still need to solve how the icons get into you menu or where to place preview pics. You dont have those with this system.
Also in case of PNDs you can also use them anywhere, just not on double click, you need to extract it first.

Also Unlike PNDs, the DBP system will allow executables inside the the DBP to be launched from command line, even if the DBP isn't mounted at the time.

 

[Silent-Hunter]

Also Unlike PNDs, the DBP system will allow executables inside the the DBP to be launched from command line, even if the DBP isn't mounted at the time.

Oh thank the lord, that was annoying with the PND system.

 

[Yoyobuae]

You still need to solve how the icons get into you menu or where to place preview pics. You dont have those with this system.
Also in case of PNDs you can also use them anywhere, just not on double click, you need to extract it first.

This is 100% true because there's no daemon running which scans for AppImages and adds them to menu and such. One such daemon could perhaps be made (but why? there's already one for DBP ).

Also in case of PNDs you can also use them anywhere, just not on double click, you need to extract it first.

AppImages don't need to be extracted. You can just download, chmod u+x appimage, ./appimage and the application launches. The ISO image is mounted and application runs from there, just like it happens for PND/DBP.

 

[elw3]

Huh? But that works with pnds too, or am i getting this wrong?
You can place several executables in one pnd without a problem and select one from command line at least.
[doublepost=1464122237,1464122088][/doublepost]

AppImages don't need to be extracted. You can just download, chmod u+x appimage, ./appimage and the application launches. The ISO image is mounted and application runs from there, just like it happens for PND/DBP.

echo "weird mounting command" >> container
cat random.pnd >> container
Oh look now its working on double click.

 

[TrashyMG]

Oh thank the lord, that was annoying with the PND system.

It still requires the developer to choose which executables they want exposed to the outside world in the metadata, but a huge leap forward IMO.

 

[Haraldur]

You still need to solve how the icons get into you menu or where to place preview pics. You dont have those with this system.
Also in case of PNDs you can also use them anywhere, just not on double click, you need to extract it first.

I am uncertain whether this is part of the standard AppImage system, but the AppImages I have tested all, upon first execution, gave a menu asking whether to place a .desktop file in the correct place for an application-menu entry. Subsurface does this. This does not happen automatically, as such, but I think it is good enough and, indeed, arguably better (only displaying in a menu those things that have executed at least once) as well as simpler (not needing any daemons at all).

AppImages can easily be extracted, as well.

Overall, AppImages are very smooth and convenient and I hope they become standard on x86_64 GNU/Linux, at least.

 

[levi]

Also Unlike PNDs, the DBP system will allow executables inside the the DBP to be launched from command line, even if the DBP isn't mounted at the time.

Interesting. Does it create a stub somewhere in the path that mounts the DBP and runs the tool, or does it really never mount the DBP and instead use some other parsing magic to pull the tool out and run it? I guess it doesn't really matter either way as a user, but it's interesting to hear.

 

[TrashyMG]

Interesting. Does it create a stub somewhere in the path that mounts the DBP and runs the tool, or does it really never mount the DBP and instead use some other parsing magic to pull the tool out and run it? I guess it doesn't really matter either way as a user, but it's interesting to hear.

I believe it's the former, but @slaeshjag would know better than I would.

 

[Agricola]

AppImages seems definitly like an interesting product, but not for the Pyra. There we already have the .dbp system which works great for what is actually wanted and needed on this system.

Isn't that how you could summarise this whole thread if you provided a link to the .dbp spec sheet to show what it has that AppImages or .pnd doesn't, but what is needed on a system like the Pyra? Why are we still going on with this thread? Maschinenherz wanted to contribute something which would have been interesting if slaeshjag didn't already plan and program a replacement for the .pnd system; inform everyone who may see this discussion about it and go on. Further questions can be asked on the .dbp thread, otherwise information gets spread througout the boards and isn't easy to look up for newbies.

Can a mod please close this thread?