Libpnd And Pnd-File .. The Position. I Can Add Drama Too!


I really hate to be the one bursting the bubble, but as much as I love the general idea, it's not going to go big for linux. It's been tried before (look at klik) and nobody was really interested. For it to be viable it would have to be standalone (ie. no base system preparation) and able to act as a .desktop file right off the bat. Secondly, it would need to use a UnionFS included in all major distros and not AUFS2. In all honesty, AUFS2 is awesome, but I don't even have a package for it in F12.
The other problem is how to resolve dependencies. You can probably all imagine how big of a pain that is...

But it works on Mac OS X, why not linux?
Because it's linux and distros value their ability to slightly patch every other package. Because there's no defacto standard for what's included in a distro. Because it's simply easier to use a package manager. Because linux guys don't like the idea of every app shipping a crap-ton of libraries for compat reasons.

It's perfect for a uniform base system like the pandora installation though.
 
why doesn't vimacs get a pandora from the dev-fund?... let's force him to take one! B) :pandora2ut4:
 
ZHasha .. It doesn't have to be perfect and for every distro day one :) remember the first Linux kernel? It's called growing over time :)

jeff
 
zhasha said:
I really hate to be the one bursting the bubble, but as much as I love the general idea, it's not going to go big for linux. It's been tried before (look at klik) and nobody was really interested. For it to be viable it would have to be standalone (ie. no base system preparation) and able to act as a .desktop file right off the bat. Secondly, it would need to use a UnionFS included in all major distros and not AUFS2. In all honesty, AUFS2 is awesome, but I don't even have a package for it in F12.
The other problem is how to resolve dependencies. You can probably all imagine how big of a pain that is...

But it works on Mac OS X, why not linux?
Because it's linux and distros value their ability to slightly patch every other package. Because there's no defacto standard for what's included in a distro. Because it's simply easier to use a package manager. Because linux guys don't like the idea of every app shipping a crap-ton of libraries for compat reasons.

It's perfect for a uniform base system like the pandora installation though.
Yep, ".app" is not an executable, but a package containing the executable and many dependencies (frequently all of them) and the resources files too.
I think the main reason why other projects like this one never got attention is that linux was a bit of a geeky thing till a few years ago... and geeks LOVE to go to the console and make/install apps from source :lol:
Now that linux is becoming a real alternative for the average computer user, maybe it'll get more attention.
I know many people that are using a computer to go on the web, chat with family, get small free apps.
When I show Linux to them, they say "oh it's easier than I trough" until they see the package manager.
They generally say that linux is cool, but they think it's not as easy to find and install applications.

A least, we will have the pandora use the PND system.
Even if it's the only platform that use it, it's already great, cause it's the main target ;)
 
Last edited by a moderator:
Thanks skeezix (and DaveC) for the positive posts and info here. This is why we are all still here because so many people have done such awesome work and we want to see the end result. (We'll be having a thanks to all... thread again next.)
 
I think what the other systems lacked was a user-base. And pnd will hopefully have one ;)

Hopefully skeezix will split the project in a pandora-related and a generic part.

Pandora's firmware will function as the primary standard-base and I guess most distributions won't have a problem to include the same libraries or functional replacements.
We will see if pnd's generic part will find interest and acceptance in the future. I don't think anyone can predict that, yet.

Personally, I love linux's package-management and wouldn't want to miss it. But a mix of current linux-package-management and pnd's approach could be indeed very comfortable. System-wide installation /critical stuff -> package-manager; little app/game -> pnd.

Btw: skeezix, we recently had a discussion about musicplayerdemon and it not being designed for removable media (it only allows for defining one folder where your complete collection must be linked in and removing/inserting a card will make a complete database-rescan necessary). While I don't think that this is a major problem, any vision how libpnd-magic could help out here?
 
Never looked I to it. I doub you will keep music in a pnd, but you could mount sd music folders into the canonicle music folder as subdirs, no? Or symlink to sd ?
Sounds like that daemon needs some work not to be so naive :)

jeff
 
it would be a great distribution system for 3rd party applications, but here's what needs to be done in order for it to be a catch for the users:
1) PXML needs to die a fiery death and come back in a useful way
2) You have to somehow embed the image into a .desktop file so that all fdo adhering systems automagically work with it
3) Someone needs to figure out what UnionFS is shipped with the kernel and is commonplace
4) The whole thing has to be standalone
By standalone I mean that the base system requires no change in order to use the app. Oh and also, on OSX, a .app isn't an image but actually a folder. The file manager just tricks you into believing otherwise.

I've tried embedding a file in a .desktop with no luck and frankly there are better ways I'd say. Ideally you would patch all major linux apps to understand some new mimetype describing an executable application image. This of course breaks the paradigm of NOT screwing with other software... you know what? screw this. I gotta go to work on making it awesome now.
I hate you for making me like this even more...
 
You aNt us to hack every major distro, and that's a better idea than starting small and making ituseful in one first? Talk about taking on giants :)

you cant embed into the .desktop which is the problem. Actually you can with uuencode but that's uber lunky. You can do two files which is what we did :) you can embed pnd-run.sh stuff in the .desktop to eliminate dependancies, but that's clunky. Theres no standard unionfs either due to kernel versions, lkm versioning, features across unionfs versions, etc

s is you can bring itup on any Linux distro in 2mins. Using a .deb or rpm for the libpnd package, nothing wring with that! All you need is p dru .sh script stuff and only a few lines of it. P d otifyd is for autodiscovrry which is a nice to have but not needed.

However, pxml is not yet ready for prime time.. It needs refactoring but we want to ship, so we lock in. That's the software way :) ship working prototype, gather usage info, do cyclical iterations to repair.

So we are exactly on schedule ;)

but for sure put some time in to help design 2.0 -- we have lots of ideas, you can be on the committee ;)

first up - redesign pxml.XML, and figure out if itshould be purely done in .desktop

jeff
 
I've always said that the PND system is horrible, but in a good way. I.e. it is very cleverly designed, does what it is meant to do perfectly and just gets the job done without having to hack around to see what is wrong, but it's kinda hackish in places, since it e.g. uses launch scripts here and there, its own kind of config files, ISO for packages, and it doesn't use .desktop files (yeah, I'm partly to blame for that I guess) etc etc

Compare this to e.g. Haiku's "packagefs" which is a kinda novel approach to package management (But I've had some discussions about it @haiku-development but whatever). It's basically a new rootfs that behaves like unionfs, in that every package is an overlay over the actual root file system. It does, however, also provide version information and stuff like that so it's very versatile. The only drawback is that it's tightly bound to Haiku and not portable in the slightest, so it's kinda the opposite of what PND is: very extendable and community- and developer friendly, but not portable.

FWIW, I'm hosting a "mirror" (kinda) of pandora-libraries that uses an actual build system and standardized C code throughout the whole thing (Because my SCM doesn't like to have 14 different formatting styles in the same code base ;) ). I've also fixed some warnings that GCC 4.4.1 gave me. I also might consider switching to cmake if the need is great enough. Also, I need to find a way to pull in the latest pandora-libraries changes more efficiently. Anyways, enough talk, I'll show you the code: http://github.com/dflemstr/pandora-libraries

Anyways, I think that we should, slowly but surely, return to the original topic.
 
Gruso said:
Gary13579 said:
LGPL is still evil. BSD please?
That's your only response to such a well considered and heartfelt post from Skeezix?

What's your order number?
Haha. I have a feeling we will see that line a lot more in these forums
 
Last edited by a moderator:
dflemstr said:
FWIW, I'm hosting a "mirror" (kinda) of pandora-libraries that uses an actual build system and standardized C code throughout the whole thing (Because my SCM doesn't like to have 14 different formatting styles in the same code base ;) ). I've also fixed some warnings that GCC 4.4.1 gave me. I also might consider switching to cmake if the need is great enough. Also, I need to find a way to pull in the latest pandora-libraries changes more efficiently. Anyways, enough talk, I'll show you the code: http://github.com/dflemstr/pandora-libraries
Well if you had made separate commits for coding style changes and fixes, we could merge your fixes to our GIT. Now it's impossible to do without wasting lots of time.
 
Last edited by a moderator:
notaz said:
dflemstr said:
FWIW, I'm hosting a "mirror" (kinda) of pandora-libraries that uses an actual build system and standardized C code throughout the whole thing (Because my SCM doesn't like to have 14 different formatting styles in the same code base ;) ). I've also fixed some warnings that GCC 4.4.1 gave me. I also might consider switching to cmake if the need is great enough. Also, I need to find a way to pull in the latest pandora-libraries changes more efficiently. Anyways, enough talk, I'll show you the code: http://github.com/dflemstr/pandora-libraries
Well if you had made separate commits for coding style changes and fixes, we could merge your fixes to our GIT. Now it's impossible to do without wasting lots of time.
Yes of course, I'm not saying that it's merge-able (FYI: I'm just using it to cross-compile panorama). But, since I think I have the formatting script around somewhere, I could redo it on pandora-libraries/master...
 
Last edited by a moderator:
Checkins to adjut indent is the worst excuse for a check in :) aside from the fact that libpnd is 99% my style which is pretty consistent and readable (though I use emacs default spacing instead of tabbing.) only a couPle files were touched by others, so really thy shouldve adopted my styling for consistency :)

jeffPhone
 
skeezix said:
(though I use emacs default spacing instead of tabbing.)
I condemn you to the fourth level of the particular hell devoted to people that don't understand the power of the tab character!
Because I totally have that power, or something. :unsure:
 
Last edited by a moderator:
WizardStan said:
skeezix said:
(though I use emacs default spacing instead of tabbing.)
I condemn you to the fourth level of the particular hell devoted to people that don't understand the power of the tab character!
Because I totally have that power, or something. :unsure:

I implement all my programs simultaneously in the language I'm using and Whitespace.
 
Last edited by a moderator:
Always loved Whitespace.. And they'll never figure out my printouts! The sicko who actually coded in Whitespace in emails is sick :)
 
zhasha said:
I really hate to be the one bursting the bubble, but as much as I love the general idea, it's not going to go big for linux. It's been tried before (look at klik) and nobody was really interested.
[snip]
It's perfect for a uniform base system like the pandora installation though.
That's really been the point. I don't really recall people suggesting that the .pnds should be useful on other platforms. All the development's been for Pandora. OTOH if somebody wanted to port it, I'm sure it would be possible, whether or not it's worth the work is another matter.
 
Last edited by a moderator:
IT works fine in other Linux distros, its just not well suited to them at this point. (ie: It is certainly Pandora-centric, but it does work fine.)

jeff
 
skeezix said:
Always loved Whitespace.. And they'll never figure out my printouts! The sicko who actually coded in Whitespace in emails is sick :)
Who wouldn't love an esoteric programming language developed by Edwin Brady and CHUCK NORRIS!
 
Last edited by a moderator:
Back
Top