Programs From The Ångström Repo


Also see my note above -- I fully expect and hope for the pnd system to grow; it is not the best design ever, but its a decent overall design, that could be extended without breaking anything for the user. (iso+pxml+image is sort of goofy, admittedly; but we had a moving foundation and ever changin kernel and driver issues, so we ended up going with something easy, supportable, solid. We tried a dozen variations, and threw out ones we thought would be hard on users, threw out ones that might be too hard for novice developers, through out ones that didn't perform well under various sitations, etc.) Likewise, the git has been long open, and we've been here day zero to discuss stuff. (It is interesting, and fully expected, how we get all kinds of flack _now_, not a year or more ago :)

So as I've said above -- it is very specifically absent in some parts, such as dependancy management; it was too much for us to bite off (yes, real repos have gone through that madness before), but we wanted to see where peopel were going, how people use things, etc, first.

So yes, pnd should grow; I fully expect the base format to have more types (just as we support iso, squashfs, and other filesystem types; we can also use .zip appended instead of pxml and icon without breaking anything, and all sortds of tricks.) We can add more metadata, or wrap the pnd in a .ipkg if we want.

So I don't see why so much vitriol from a few people (thankfully, only a few people :) -- work with us, don't stamp your feet :)

anyway, I'm replying too quickly here with too much on the go right now, and apologies for that; time is not availanble when I want it to be :)

jeff
 
skeezix said:
Download pnd, drop it here; thats it. No config hacking or anything, pretty darned easy, and reliable.
[/quote

Lies! You forgot:

1. "Insert SD card"
2. "mkdir /media/card1/pandora/games" (or whatever it is, sheesh..)
3. "Download PND manually using a browser/wget/curl/netcat/etc." :D
4. "Put PND in newly created directory"

Nice try!


You didn't respond to my later commentary -- how does your repo deal with SDs ejecting and
inserting all the time?

On SD-mount, scan for .desktop files, if found, add them to the menu. On SD-eject, update the menu to exclude whatever was on the ejected filepath. Simple!

You also ignored the fact that it _is_ a handheld, with limited RAM; integrating a lot of apps
into the fileysystem simplky _cannot happen_ sensibly.

Hogwash, its got more RAM than most of my Linux boxes have ever had, historically. Straw man!

Likewise, your pointtting to hotfix and codec pack is sillyness at its height; the hotfix pack is
a hotfix released say day as the device, by a couple of people making devices; you thinbk they
have time to set up all sorts of systems right now?


Nope, but you'd think in the two years of thinking about this, they'd have come up with something that *doesn't* represent the same technology as a Windows box from the 90's. 'Manually Download a "Hotfix" and apply it yourself to get your system working properly', shudder.. puke!


the hotfix was to repair a kernel issue, in the way simplest for the users. Eeryone knows
how to download a file and copy it to SD;

More lies! iPad-/iPhone-using Grandmas don't! Is this a handheld entertainment device or a hacker-masturbation tool?

you want them, day zero, with a screwy kernel, trying to set up wifi and sucking down a
fix from a repo? *hardly* and never really done anywhere :)

Wifi should work from the get-go, or else the Base OS isn't releasable, and if this didn't work from the beginning I wouldn't have, personally, released the OS .. so yes: I *do* want them setting up wifi and doing an upgrade through the repo manager. Much better than having to use another computer somewhere else to download a file manually, copy it over, etc. Didn't you see the threads where people were already having problems with having to do all this?

Code:
And try to find the number of problems with people using pnds; oh wait.. none!

Out of the 30 or so active users who have their Pandoras already, I've counted 5 - on IRC and on these forums - who didn't apply the hotfix, didn't know there was a hotfix available, and had all sorts of problems with their systems as a result ..

Code:
The only reports I've seen are: 1) a couple pepole who put them in / instead of /pandora
/random-directory; that is _on purpose_ -- and thanks for not asking why, and just assuming its 
stupid ;)

Its 2010, for people to have to mkdir something to make something something work something .. give me a huge fat break, man. Head, Sand, OUT!

[/code]The reason I picked for that was.. the system is defaulting to dirwalking from the
searchpaths, so that people can organize in hierarchies if they want; so having it look at /
implies searching the whole SD, which could also be a 1TB USB disk.[/code]

You're only dirwalking because you have to - you don't have a proper package manager to sort it out for you, LOL!

Code:
 That'd be just plain slow to seek through. So we suggest people use a /pandora hierarchy, 
much like many other devices do. But they're free to use / or anywhere else if they're experts and 
do want to fiddle with the confs.

Code:
So yes, we have a basic and very easy to follow rule :)

Please draw a picture for Grandma, who will have a Pandora and not know what the fuck you are talking about. OR .. is Grandma not in your 'target user group', elite-wise?

Code:
As to the only other issue I've seen -- was a developer who had a broken pnd

ANOTHER THING A REPO+PACKAGE MANAGER WOULDN'T HAVE ALLOWED!~!

Code:
So yes, theres been no real problems with pnd files.

So all of the above was just hallucination then, eh?

Code:
Now instead, try to get the repo working when the user may not have wifi at all (and there 
is no ethernet port), and try to get OS fixes how?

"Here Grandma, download this file to your SD card (getwifiworking.pkg) and then just double-click on it on your Pandora..."

Code:
We don't have a NIH here syndrome;

You really, really do, or else you'd be using repo technology to solve all these problems already, LOL!

Code:
seriously, we're much prefer to not code anything we didn't have to. We're erring on the 
side of user convenience. (And that said, maybe I'll all wrong; fine, could be. You can call me an 
idiot if you like, I've been developing for a looong time, it won't hurt my feelings.) I might 
also be influenced from developing for handhelds of every possible OS for 15 years :)

Well then, like you I've also been developing Unix-based software since 1983, and have been also developing for every possible handheld OS for the last 20 years (from Atari Portfolio through PalmOS through Symbian, through WinCE through iPhone through Angstrom) as well, and I think user-downloadable PND-files that must be user-maintained are Just Plain Stupid. Its not the 90's, although if it were, this would've been cool.

Code:
But I think I'm onto something, and people are very enthusiastic about the pnd system.

Go ask Grandma. Until you've done that, I'm going to consider that you're being myopic because you're surrounded by sycophants and other Wise Elite Uber-hackers.

Code:
 You gather experience first.)

.. all the while ignoring the countless man-years of experience that repo technology provides to the scene, right, got it .. or haven't you ever maintained a repo, actually? Come to think of it, *have* you ever maintained a real repo and seen it work for tens of thousands of users? If not, this explains why you're inventing another one, slowly, and about 10 years behind everyone else ..

Code:
So we might have missed the boat, but clearly we're doing something right -- almost every 
user of pnds has had them work out of the box, as adveritised, with no weird device setup that 
would fail if their wifi doesn't work, or if they yank out the SD and stick it in the other 
slot.

Wifi working: from the factory, or else.

SD removal: not a problem that repo's/package managers haven't already solved, sorry! If you don't get it, I'd say its because you didn't look : you thought it better to just re-invent the wheel instead of doing some real experience-gathering study of the existing scene .. hmm ...

Code:
BTW, I've been using BSD and Linux (and solaris, irix, etc) for a very long time, and I also 
know how often people get bitten by repos when they don't want to be :)

I don't doubt your technical skills or your general competence. Its your arrogance and myopia I'm complaining about, but that could just be a result of my own 20 years experience with developing mass-market Unix-based devices and the NIH-syndrome-afflicted developers that the evolution of such systems attract ..

Now look, before you reply, I want you to know that I like you Jeff, I respect you and the *other* things you have done, development-wise, really I do, but I think you're being really pretty dumb here.

PND's belong in a repo, and a package manager belongs in the hands of the user. Its not 1994.

HOTFIX: DO NOT WANT! Single-button update-to-latest-proven-stable packages: WANT.
 
Last edited by a moderator:
skeezix said:
torpor -- again (and with all due respect; we're allowed to discuss and disagree without being heated, right? maybe I'm fully wrong, but try to enlighten me ;)

Oh, absolutely. I'm getting ranty, its true, but its because I think you're not willing to admit that PND's are stupid! :)

Please go through point by point and avoid cherry picking or ignoring the good bits (and I might be doing the same; I'm in a mega rush, so aplogies if I fail to catch something.)

I'm replying to every one of your points, or if I wasn't how come I'm getting the "too many quotes in your replies" message from the board?


repo install to /media/foo1; then you yank it out and insert into slot2.

Know what GUID-based mounts are? Know what UnionFS is? Its 2010, this problem is *OVER*.


Does the repo handle that?

The repo doesn't know and doesn't care, because the software package manager combined with a properly configured auto-mount configuration does it all.

what if you want to download it again onto another SD?

Put in other SD, install to other SD.

how does it work out dependancies when you've installed to foo2, and foo1, and then stick in foo3 instead of foo2.. dependancies all go to hell etc.

Look up the --dest-dir option of opkg and try to imagine what a UnionFS join would do for you here .. And if you still don't get it, go to the opkg-devel list and ask on there how this issue has been addressed (about 5 years ago..)

Repos do not handle ejectable media.

Funny, I use this scheme on my Touchbook every single day, and haven't run into your problem a single time ..
 
Last edited by a moderator:
You say it's easy; would you like to do it?

Sure do! And as soon as I can maintain parity with DJWillis' Base-OS build environment (and have my development Pandoras in my hands), I will be pushing towards this, as a personal contribution among other things (++PandoraMusicApps.PND, ++PandoraWarsClone.PND, etc).

Thus in my view this thread is not for flames and pedantry; its to improve the scene with real discourse ..

EDIT: One thing I must say is that I believe the system has been developed as best it could, and those who have looked at the repo/PND system have been historically hindered by the lack of working, operational hardware. Now that there are Pandoras to really test on, we can push things forward a lot quicker, and I respect the fact that we are still very much in bootstrap mode. When I get my Pandoras, I really hope to contribute to push things forward, and at the very least I can propose and produce an ALTERNATIVE OS PACKAGE that people can run on their systems, if they like, which will do away with all these hassles .. That is my short-/mid-term goal, anyway. Keep that in mind.
 
Aninhumer said:
@torpor
Modern repos are not designed for systems with potentially highly fractured storage.
A repo for core OS updates is fine, but it's not going to work well if you want to install apps to the SD.

Well, this isn't really true. A great deal of tooling already exists in the Linux space to make installs of software on "Fractured" storage possible and reliable: loopback mounts, chroot, GUID-based mounts, LD_PRELOAD, LD_CONFIG_PATH, UnionFS: all of these things can be bent to solving this problem standardly on a normal Linux box without requiring anyone write a libpnd.so ..

Or, have I just been hallucinating all the NFS-based software that I've run over the last 30 years, LOL .. (Hint: NFS =~= SD card for fracture, yo .. )
 
Last edited by a moderator:
sigh.

okay. We're not going to solve anything here, I think, but I'll reply anyway :)

Sure, they have to create a directory... *once*. Rough ;) I grant you ejecting SD cards could be a drag, but its something everyone knows how to do :)

I asked about the _repo_ dealing with SD ejects/inserts; you've not commented there. Yes, .desktops will work just fine. But what about install/uninstall/reinstall etc; repos are not good with removable media. (go ahead, get your ubuntu and install an app onto SD, then yank it out, and watch the repo squirm :)

By RAM above, I meant NAND; point stands; most repos are good at installing into the filesystem; we don't have the luxury. NAND is constricted. When you say 'straw man!' back, it shows how excited you are; relax a little, we're trying to debate among friends. It seems you're way too angry about this :)

As to grandmas -- our _target audience for now_ are forum people a little more savvy than grandma; they've also had gp2x's etc, they know how to download and copy files. If you want to talk grandma in the future, well, using a standard linux style system is right out; but you want to compare the DRM hell of ipad/iphone, _with no extensible storage at all, due to Apple wanting to avoid this problem entirely_, a model? These guys won't let you download more than 10MB in a single file! :)

As to Wifi .. we know that this is a device with a history of some wifi issues, and known ethernet port; the one thing the user cna depend on day zero, for sure, especially if they have no wifi, is SD. So yep, a short term hotfix pnd is a hell of a great thing for day zero :)

Didn't know the hotfix was available? A device solely advertised on forums and blogs, those people are generalyl pretty well versed in how to find out about things; but if they're not .. you think these people will set up a repo and wifi day zero, to get informed? I'd say equal there, not repo is superior; you seem to think 'the best of one is better than the worst case of another', which is hardly sporting; think in terms of 'average case for both, lets compare'

BTW, no hotfix and no codec pack.. system is pretty usable; we didn't ship a borked system; so no, they didn't have all sorts of problems as a result. BTW, coded pack is pretty normal -- PSP, etc all need one in order to do various things. iphone/ipad.. well, they just don't support any codecs at all, beyond what they have in hw. So we've done one better, not done one worse. your world is warped,sir :)

Broken pnd .. um, its very easy to break a deb and fubar the whole deb system, for instance (especially .deb, which is one of the messiest and goofy formats of all time :)

Anyway, no, tell me, maybe I'm nmissing it; I watched repos blow up lots of times. If you install app to SD1, and another app to SD2, and then another to SD3, how is the repo going to deal with it, when you want to uninstall and its not there? or reinstall? or install a second copy to another SD, without hurting the previouscopy?

Why do you dodge that essential question :)_

(Granted, maybe you concede that, and we get one chalked up point in your world, and 500 negatives. But let me know if we got one point in your world ;)

I like you to, but we have to agree to 'wait and see'.

I think you're 100% set against, and for _some good reasons_, but I think overall we have a good idea here, to solve a use case _for our users_.

I'm not trying to say 'scrap repos, use pnds', but for _our users specific expected usage_, I think we're onto something. I certainly don't intend to use pnds on my servers; but you know what, pnd files actually do have a use on your average linux desktop, for running apps off an SD card :)

jeff
 
<random note>The PND format would have been awesome to have on the GP2X (or for any other device which needs another device/computer to manage it) and would have made things a lot easier for that. It's also good on the Pandora for people who don't have wifi access (or just can't get it working ;) ), but for people with a working wifi connection on their Pandora, it does seem to be a bit of a hassle when other solutions are (more or less) already available.... hmmmm...</random note>

Edit: Didn't a few people say they were going to make something to manage the PND files on the device? Many months ago..
 
Enlighten me on your touchbook (I'm debating getting one, didn't want to get into _anothe_ preorder pit ;) --

(BTW, they'r elooking at adding pnd support ;)

Use a repo, install an app to 3 SD cards.

For bonus marks, installs things that app depends on to SD2, and install the app to SD1, then yank out SD2 and see how much fan you have.

(Granted, if people are really careful with their ports on non-pandoras, they can avoid that situation bybundling dependancies in with their app; part of pnd is the philosophy behind it. But if we have a pandora-specific repo, the same philosophy could be applied, so yes, this may be moot.)

In my experience, trying to _force_ an existing repo tech to work across ejecdtable media is only failure; I've had no luck using ipkgs and debs and such across removable media.

But maybe we blew it 18mo ago when we came up with this.

So walk us through it -- how can you make it work, and think up lots of obscure use cases like we have :)

I am willing (and said day one, every time) that its not perfect;l buyt I think the objectives we're trying to hit, we did okay on. Simple app management, for peopel who hate gp2x pain :)

jeff
 
torpor said:
You say it's easy; would you like to do it?
Sure do! And as soon as I can maintain parity with DJWillis' Base-OS build environment (and have my development Pandoras in my hands), I will be pushing towards this, as a personal contribution among other things (++PandoraMusicApps.PND, ++PandoraWarsClone.PND, etc).
I am honestly looking forward to this, because I can guarantee that I will find ways to break every repo solution you come up with until you've had to alter the functionality so much it no longer solves the same problem as simply using PNDs would. Only then do I think you'll truly appreciate the solution they've come up with. :)
 
Last edited by a moderator:
Now that there are Pandoras in customer hands, we no longer need to expect all of the software updates and resources to come directly from the OP team. There's plenty of room for all different kinds of software management. Isn't that the point of this device?

If someone decides to build a repository for the base OS, I'm sure that many of us would use it in conjunction with the PND system.
 
skeezix said:

Sigh.

okay. We're not going to solve anything here, I think, but I'll reply anyway :)

Its worth discussing, imho. No harm intended!

Code:
Sure, they have to create a directory... *once*.

That is One Time Too Many for Grandma, yo!

Code:
I asked about the _repo_ dealing with SD ejects/inserts; you've not commented there.

The repo doesn't care where you put it. The package manager communicating to the repo has to care, and this is no problem whatsoever for opkg and company.

Code:
Yes, .desktops will work just fine. But what about install/uninstall/reinstall etc; repos 
are not good with removable media. (go ahead, get your ubuntu and install an app onto SD, then 
yank it out, and watch the repo squirm :)

At work, a major provider of embedded systems software for a safety-critical industry where people will die if things are not done right, we install a majority of our software through a package manager to NFS-based mounts, and we all know how much they compare to SD cards for general accessibility/reliability. They are *WORSE*, but you know what: IT WORKS!!! Has done so for 10 years!

Code:
By RAM above, I meant NAND; point stands;

Okay, but for the BaseOS, there is ample NAND available, and for everything else: SD cards.

Code:
most repos are good at installing into the filesystem; we don't have the luxury. NAND is 
constricted. When you say 'straw man!' back, it shows how excited you are; relax a little, we're 
trying to debate among friends. It seems you're way too angry about this :)

It *is* a straw man though, because I am not advocating putting user apps on the NAND: just the Base OS. And I fail to see how we're reaching any limit there, already?!

Code:
As to grandmas -- our _target audience for now_ are forum people a little more savvy than 
grandma;

Go on, admit it: you've invented a system that other hackers can use, but which simply doesn't stand a chance against dumb users. :)

Code:
they've also had gp2x's etc, they know how to download and copy files.

And this is what I mean about your myopic intent here: you haven't designed a system for users, you've designed a system for your fans. :)

Code:
If you want to talk grandma in the future, well, using a standard linux style system is right out;

Works for Apple!

Code:
 but you want to compare the DRM hell of ipad/iphone, _with no extensible storage at all, 
due to Apple wanting to avoid this problem entirely_, a model? These guys won't let you download 
more than 10MB in a single file! :)

Yo, you keep making straw men, I'm gonna keep opening the gas can. Repo != DRM! DRM is well and truly *NOT* a part of the picture I am painting, and you know it too! However, SHOULD we want to have a DRM system in the future (shudder!), a repo would be the only sensible place to put it.

Code:
As to Wifi .. we know that this is a device with a history of some wifi issues, and known 
ethernet port; the one thing the user cna depend on day zero, for sure, especially if they have no 
wifi, is SD. So yep, a short term hotfix pnd is a hell of a great thing for day zero :)

~Dreamily off we go into a virtual world, thus:~

Code:
$ cd ~/Desktop/MyFirstOffLineHofix/
$ wget http://yodogitsahotfix.com/yupitsahotfix.opk
$ ls ~/Desktop/MyFirstOffLineHotfix/
yupitsahotfix.opk
$ opkg -i install ~/Desktop/MyFirstOffLineHotfix/yupitsahotfix.opk

(Or, if you like, use a GUI to do all of the above, Grandma..)

No re-invented software required!

Code:
BTW, no hotfix and no codec pack.. system is pretty usable; we didn't ship a borked system; 
so no, they didn't have all sorts of problems as a result.

I'd like to note for the record that there are a lot of successful wifi-using Pandora users out there already ..

Code:
BTW, coded pack is pretty normal -- PSP, etc all need one in order to do various things. 
iphone/ipad.. well, they just don't support any codecs at all, beyond what they have in hw. So 
we've done one better, not done one worse. your world is warped,sir :)

I don't mind having to have a user-installed coded pack, sure. I do mind having to figure out what the URL for the bloody thing is, every single time I re-install the OS, or give a Pandora to someone else as a present, and so on .. a repo would wipe this ass, so to speak.

Code:
Broken pnd .. um, its very easy to break a deb and fubar the whole deb system, for instance 
(especially .deb, which is one of the messiest and goofy formats of all time :)

No package manager since 1993 has a missing "md5-sum check of files" stage before the install, sorry ..

Code:
Anyway, no, tell me, maybe I'm nmissing it; I watched repos blow up lots of times. If you 
install app to SD1, and another app to SD2, and then another to SD3, how is the repo going to deal 
with it, when you want to uninstall and its not there? or reinstall? or install a second copy to 
another SD, without hurting the previouscopy?

The repo doesn't deal with it: local package manager application does, and yes there are definitely already ways to solve this problem: mount with GUID, loopback file on the SD, $(GUID_ROOT)/var/pkg/*.pkg for package manager, scan-PKGDIR-on-insert, etc. And if you don't like these features well then you could've added code to opkg to deal with it properly. Its open source, after all ..

Code:
Why do you dodge that essential question :) _

I haven't dodged it, I've answered it at least 3 times so far! You seem unwilling to admit you invented something that you could've implemented with a little smart thinking about the Base OS!!


Code:
(Granted, maybe you concede that, and we get one chalked up point in your world, and 500 
negatives. But let me know if we got one point in your world ;)

Nope! All I see is someone who hasn't thought about how to use env vars, chroot, and the 'opkg -d' argument and instead just decided to re-invent another software maintenace system that only their elite hacker audience can use! :)

Code:
I'm not trying to say 'scrap repos, use pnds', but for _our users specific expected usage_, 
I think we're onto something.

I'm going to release PND's, don't get me wrong. Not because I want to, or because I think its clever or solves any particular problem: but because its already become a standard.

I certainly don't intend to use pnds on my servers; but you know what, pnd files actually
do have a use on your average linux desktop, for running apps off an SD card :)

Well then:

Code:
$ mount -o loop,rw /media/card1/SOMEBIGFAT.ISO /media/LEFTSIDE_SD_CARD
$ LD_[CONFIG,RUN]_PATH=/media/LEFTSIDE_SD_CARD/var/lib/ /media/LEFTSIDE_SD_CARD/MyFancyApp.sh
[/quote]

 :)
 
Last edited by a moderator:
To be fair, he has some points (and I do as well ;) -- and a lot of folks who've been leveraging criticism the last few days haven't gone end to end like we have. (Not saying our solution is anywhere near perfect; Iv'e said all along its got a lot of repairs needed, and that its designed ot have whole parts tossed out and replaced, without changing the API; this is the software lifecycle .. build easy and solid and readable, then replace and optimize later :)

A lot of folks have been forgetting some odd but important considerations -- ensuring that their replacement system can run multiuser and multitasking; theres been some 10 'new pnd file formats' proposed in the last week (some very well considered), but they ofgten fall on that one -- if you run 5 MAMEs at once, it better work; likewise, can two different active accounts run it at once?

Theres a lot of cases, many of which we've caught (not all, I'll leave that as an exercise for the reader/hax0r ;)

jeff
 
Hey Torpor, if you dislike the current system so much,

THEN DO SOMETHING ABOUT IT!

Stop accusing people who are actually doing something for this project and stop putting down their work. If you fell so strongly about this "problem" you see with the system, then quit your bitching and get your ass in gear.


I apologize to anyone else who had to read this post, but I just couldn't handle him constantly putting down the work that people like Skeezix and Notaz have been doing for us without even making an effort to do something himself.

-God Ginrai
 
skeezix said:
Enlighten me on your touchbook (I'm debating getting one, didn't want to get into _anothe_ preorder pit ;) --

Don't bother, the Pandora is better. The scene is better, the hackers devoted to doing things with it is better. Touchbook .. well .. I'm sorry, but I don't see it surviving through the year unless they address the hardware problems (power management blows) and quality of manufacturing issues ..

(BTW, they'r elooking at adding pnd support ;)

I know, I suggested it! :) (Because of all the great apps that are going to be PND bound ..)


Use a repo, install an app to 3 SD cards.

Okay if I use network mounts instead, and then go for a walk into the apple orchard and see how things progress? BTW, IT WORKS! :)

In my experience, trying to _force_ an existing repo tech to work across ejecdtable media is only failure; I've had no luck using ipkgs and debs and such across removable media.

By my count, the code effort that went into libpndfile could've solved this problem within opkg/Angstrom ten different ways by now ..

So walk us through it -- how can you make it work, and think up lots of obscure use cases like we have :)

I promise you that I will:

a) Use PND's, because everyone else is
B) Come up with an alternative method that works *BETTER* than PND's

.. when I get my Pandoras to work with, and have caught up with DJWillis' build-environment efforts.

I am willing (and said day one, every time) that its not perfect;l buyt I think the objectives we're trying to hit, we did okay on. Simple app management, for peopel who hate gp2x pain :)

LOL, *I* hate GP2X pain, but I thought it was all going to go away once we had WLAN capabilities!
 
Last edited by a moderator:
@God Ginrai
Leave it to the persons involved, imo. They are both grown-ups, I think :)
 
torpor said:
Well, this isn't really true. A great deal of tooling already exists in the Linux space to make installs of software on "Fractured" storage possible and reliable: loopback mounts, chroot, GUID-based mounts, LD_PRELOAD, LD_CONFIG_PATH, UnionFS: all of these things can be bent to solving this problem standardly on a normal Linux box without requiring anyone write a libpnd.so ..

Or, have I just been hallucinating all the NFS-based software that I've run over the last 30 years, LOL .. (Hint: NFS =~= SD card for fracture, yo .. )
I'm not just talking about storage on more than one device, I'm talking about storage that might not even be there at all.
For example:
  1. Install App A
  2. It depends on Library B, so installs that too.
  3. You swap the SD card.
  4. Try to install App C.
  5. It also depends on Library B, but hey it's already installed right?
  6. Try to run App C, it fails.

Obviously a solution there would be to install the library to the NAND, but that only works while you have room left.
I don't believe there is a package manager that completely solves this problem.

How well does that NFS based software work when a vital server goes down?
 
Last edited by a moderator:
God Ginrai said:
Hey Torpor, if you dislike the current system so much,
THEN DO SOMETHING ABOUT IT!

Thats what this discussion is all about, yo.

Stop accusing people who are actually doing something for this project and stop putting down their work. If you fell so strongly about this "problem" you see with the system, then quit your bitching and get your ass in gear.

Waiting .. patiently waiting .. for my Pandoras to arrive, so I CAN DO SOMETHING ABOUT IT AND KNOW THAT IT WORKS ON REAL HARDWARE.

I apologize to anyone else who had to read this post, but I just couldn't handle him constantly putting down the work that people like Skeezix and Notaz have been doing for us without even making an effort to do something himself.

Blow me, sycophant. If I had a dev system 18 months ago, I would've done something about it.

What I'm doing now is getting the ball rolling on an alternative: by discussing it with the very person who is the *most* competent person to address this issue so far. If you don't like the thread or my manners towards Skeezix (who I have already said I respect a great deal, or I wouldn't be challenging him already), then go read something else.
 
Last edited by a moderator:
Aninhumer said:
I'm not just talking about storage on more than one device, I'm talking about storage that might not even be there at all.
For example:
  1. Install App A
  2. It depends on Library B, so installs that too.
  3. You swap the SD card.
  4. Try to install App C.
  5. It also depends on Library B, but hey it's already installed right?
  6. Try to run App C, it fails.

Obviously a solution there would be to install the library to the NAND, but that only works while you have room left.
I don't believe there is a package manager that completely solves this problem.

How well does that NFS based software work when a vital server goes down?

If I understand Torpor correctly, when you eject the SD Card a script would trigger the Package manager to rebuild the Installed Applications catalog and know that Library B is no longer available at that point.
 
Last edited by a moderator:
omg, we're getting too lengthy here :)

NFS != SD in _usage pattern_

NFS is generally mounted once and lives awhile (until it died, or sw blows up from flock issues, etc :)

An NFS volume is not generally where you have 5 of them coming and going every 2 mins, with users installing apps across any of them. An app tends to live on one NFS volume, not 5 of them.

So yeah, get deb or ubuntu, and tell it to install emacs on /mnt/foo on NFS; but what if you then install that same package to /mnt/foo2, and /mnt/foo3; mostr package managers just donm't like this, at all.

--

To wit .. you know your mount loopback above? Thats what pnds are, you realize, right?

We should perhaps try to constrain our discussion, I think we're flying too far all over (at least I am, I'm not sure what we're fithing about anymore, specifically :); so theres repo, theres package management, theres what he executable is.

pnd is the executable, to keep things all together, and does the union magic for appdata, etc; we also imply guidelines for where to put files for auto-discovery etc, for ease of use.

Sounds like you're really arguing about package manegement / dependancies; PNDs are not meant to go there. We expect to either extend or use a layer on top .. ie: As I've often said, we could use a package manager on top of pnds if we wanted, but I didn't think the existing ones worked for our needs.

Can you define the exact problem statement, give me the Invariant :)

I bet in the end, we are in agreement.

One pnd depends on another? You'll find every time I was asked, that I said we need to use some package system or extend pnd, but that we had not researched enough, nor had resources, nor user experience, to make a decision... and that we weren't going there yet.

Locating pnds, and pnd updates? You'll also find we talked about automating it using dependancy info etc; use the app store with an API, or whatever; dflemstr is working on it, as are other people. (Frankly, we've attracted a lot of really clever people, many much more clever than I in this arena. Pretty amazing, our community.) PND / PXML does not address this yet.

What pnd does address is being an executable that includes documentation links, and can provide multiple applications from a single file, with user changes/data being directed to one standard location. A little more than a executable, but no more.

jeff
 
Back
Top