I think you mean: " shared libs. ". If the lib. is rarely used, then why share it? Statically compile it and it`s conflicting with other libs. problem is solved.

I looked at ROXapps and didn`t see that they were any better than an SFS. I don`t know the structure of a AppDir, just the app.`s files all in a dir. I guess.
Obviously having all of an apps. files isolated has advantages. But shared libs. and a good O.S. API go a long way toward the reusable software model.

Q5sys, "curious about your thoughts" -Boy is something going wrong here... I thought I had commented on the /opt thread. I'll maybe waste some time there a little later...

sunburnt, of course I meant shared libs. The static/shared question has several aspects that should be taken inti account. Usually, when a library is very small, devs who want to use it in their application simply add it to their sources and include it statically, unless it is already a commonly-used and commonly-available shared library.

The problem comes with trying to judge how 'rarely' the libs might be used. Sometimes it is hard to tell, but sometimes it is obvious. Linking statically usually takes extra work, so I don't practice it much -I have so much nicer things to be doing with my time If binary compatibility with other OS versions is the prime issue, then, of course, linking statically can be a great help. And, if you like compressing your binaries, then linking statically can help you achieve smaller bins. That sounds backwards, but the thing is that you can't really compress *shared* libs, while executable binaries you can. So, often a statically-linked binary can be compressed to a smaller size than having a dynamically-linked binary of a smaller size and then compressed, plus the size of the un-compressable shared library.

I think that usually trying to achieve really tiny binaries is a waste of time and ruins the general outcome when practised often. You either use limited versions of the program, hack out portions of a working program and remove things that you don't use -thinking that nobody else will want them either -often a wrong assumption. Then, you compress everything as much as possible -even when it is tiny to start with. Running compressed binaries is actually wasteful because it requires extra time to uncompress them and extra RAM in which to do that.

About AppDirs. The concept of software 'bundles' is old. Lots of early UNIX software was meant to be used from within a single directory -usually right fom inside the sources. Any shared data or config files would all be located in the same dir. As used by ROX, AppDirs become special by being executable directories -just click on them and they run. At the same time, you can cd into the dir and './AppRun' and get the same thing. Or, you can link the AppRun anywhere you like. All of this fits exactly with what /opt was designed for.

Interestingly, SFS's as used by Puppy and others, share a couple of aspects with AppDirs. They both contain everything under one dir. Even if you union the squashfs, the original mount of it is under one dir. And, they are both extensions of the idea of 'uninstalled' software which can be added or deleted dynamically.

Most of the 'original' AppDirs actually contain their uncompiled sources. 'Installing' them simply means un-packing the archive -basically anywhere you like or have rights to write and execute. Then, clicking on the AppDir compiles the sources and runs the program. Succeeding runs of course do not re-compile the app. Pretty slick actually, but it can get messy just like with uninstalled sfs files -or any other kind of FS-image. There is a project which lets you use a type of AppDir where the AppRun is actually a binary instead of a script and the other AppDir contents are an *.iso image. Running the app mounts the image. The same thing could be done with sfs's or any other FS image -ext2, iso or whatever.

... I think that usually trying to achieve really tiny binaries is a waste of time and ruins the ...

Well spoken. Hope many are clear on what you accurately share.

Hope this helps_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

On Roxapps and squashfiles: if you just chuck an AppRun (and a .DirIcon or whatever else you want) in the top level of a squashfile it would contain an AppDir. Just mount the squashfile and there you have it. If I wanted to use a bunch of non-unioned squashfiles, I think that's the way I'd go._________________DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!

"static lib / tiny binary enthusiasts" They may be getting callouses on their ears by now...

Actually, you could also just throw an sfs inside an AppDir. Create an AppRun which mounts the thing or links it or whatever method you use to make it available -then just clicking the AppDir would do that. Of course I realize that some SFS's are handle at the system level, but for addons at least two different methods are being used by those who produce these things. Since nothing is done withem at the system level, putting them in an AppDir provides an easy way to something with them with just a click.

Imagine the case where I have two wildly different computers. They require different drivers for the hardware and the screen's can't be set to the same resolution. If I want to be able to quickly move my work back and forth between these, I need to keep my work and all the settings separate.

Have you actually tried using the same USB stick Puppy install on both? I thought that it already handles this, by creating a separate xorg configuration for each.

I have a desktop machine with a whole collection of hardware in it. I also have an EEPC-701 with a really-really different collection of hardware. The same network drivers and settings can't be used between them. Quite a few things don't work if I copy a save file between them.

The /root/.wine/drive_C/temp needs to be a symbolic link to two different places.

The programs that I have written are in my-applications/bin and my-applications/lib. These need to be the same.

The desktop has the samba server installed and configured but the EEPC doesn't.

my-documents needs to be the same.

I guess I can do all this with a mess of symbolic links and a script that detects which machine and configures as needed but I was kind of hoping for something that took less manual work to set up.

Moose On The Loose; Sounds like you`re looking to sync the two PCs.
I made a Puppy setup script for after the inevitable Save file corruption. Makes links of /root/my-documents, etc. to a Linux partition, and other things.

amigo; Yes, like a ROXapp, but I don`t see the point in a Squash file inside a dir.

disciple; Tiny binary... No. Static libs. if small and seldom used... Yes.
Your description is what I have working ( just a few apps. so far... ). I`m not much for compiling so I`ve tried to automate the AppSq build process.
It`s a Squash file with a very small "hook" run file and an icon in the root.
The hook run file`s about 20kB - 50kB in size so it has a small ram footprint. It runs the app., then upon exit runs the loader handler for Squash unmount.
I made a menu GUI listing all the Squash apps. found, click one and the loader mounts and runs it. So Squash apps. are only mounted when running.

I've been having problems lately with squash apps....libs not being read even though they're listed as installed in a loop. Rebooting, ldconfig...sometimes nothing works other than reinstalling the package as a pet. That works. In one instance, I combined several packages and installed it. The files looked like they were installed when I ran tree on the loop, and yet I couldn't actually find them anywhere even in the loop. There weren't any whiteouts, either.

jpeps; Almost sounds like what amigo`s been saying about Puppy and libs.

I assume that these were standard unioned SFS files you`re talking about, I`ve had an equal amount of trouble with .pet packages, I rarely use them.
In either case if the libs. were static it wouldn`t be a problem. Lib. conflicts...

Non-unioned Sqaush files ( or dirs.) isolate the files in them from the whole. Puppy`s union might cause the problem, but as you said it doesn`t seem so.
Shared libs. will always have this sort of problem, so secure and limit them!

Moose On The Loose; Sounds like you`re looking to sync the two PCs.
I made a Puppy setup script for after the inevitable Save file corruption. Makes links of /root/my-documents, etc. to a Linux partition, and other things.

amigo; Yes, like a ROXapp, but I don`t see the point in a Squash file inside a dir.

disciple; Tiny binary... No. Static libs. if small and seldom used... Yes.
Your description is what I have working ( just a few apps. so far... ). I`m not much for compiling so I`ve tried to automate the AppSq build process.
It`s a Squash file with a very small "hook" run file and an icon in the root.
The hook run file`s about 20kB - 50kB in size so it has a small ram footprint. It runs the app., then upon exit runs the loader handler for Squash unmount.
I made a menu GUI listing all the Squash apps. found, click one and the loader mounts and runs it. So Squash apps. are only mounted when running.

I only sort of need to sync. I can carry the same USB hard drive between the machines in question. It is just that I want to have an easy way to have them both work. I think that for now, two save files and lots of symbolic links is the way to go. I can have the USB drive have two partitions. One can be FAT32 and the other EXT4. The EXT4 will allow me to have symbolic links and the like that don't work within a fat32 system.

I see that there is slightly more votes for a non backwards compatible package system...

What if one could simply adapt another standard that exists?

My MAJOR thought is that using "foreign" repo, from more complex distro's, also makes more complex implementation into Puppy, makes less sense than using a repo from a less complex distro...

That points to to places... Slitaz and Tiny Core...

Given I am right, its more likely that a package system, lets say for Puppy 6, built around their standard and repo, would actually make it fun to use it.

If I stick to my own favorite here, the Slitaz repo with a friendly community and more than 3000 packages in their repo, I think it could be a win win situation.

Assuming that one does that, there is already more than 3000 packages ready to use and if one like to make a package, it might benefit both Distro's.

Also... Slitaz you can deal with. There is no way I think that Ubuntu or Slackware would do ANY changes in their repo, to make it more Puppy friendly.

I think if those two brilliant gangs from Slitaz community and the kennel gang her, was to do something, it smells like a big win win to me...

I hope, even if I can not make a simple "symlink" that the logic's behind having a repo from a LESS complex distro, would be like less is more and that is more easy to foresee that ALL packages will work and not some here and there, that is the case with the Puppy's built on larger distro repo.

Speaking for my self, I have virtually given up to use the Ubuntu repo for Lupu and the Slackware repo for Slacko.. Why? To much that does not work and I feel that what does not work, is messing up my Puppy.

I only stick to .pet and .sfs and if I remaster, I might even remove the package manager, and rather create a copy of the repo, and pointing the webbrowser to it. I feel shy to suggest Puppy XXXX and they want a package from a Ubuntu or Slackware repo, and its complex to install and does not work. ITs not fun and its not the future.

That said, both Playdayz and 01Micko have done and are doing a GREAT job. Also all the other contributors.

So the basic idea is to use packages from a foreign repo, whereas the distro is LESS complex than Puppy and not MORE, as seems to be today*s idea...

I see that there is slightly more votes for a non backwards compatible package system...

I see it the other way around. The majority seems to want either to stay with the current system or to be compatible with that system. A significant minority wants to go with something else even if it is not compatible.

I think that not going to some more complex system in one leap may be the best answer. Migrating to a new system but keeping the compatibility until such time as there are not longer any programs that can only be had in the *.pet format, seems the least likely to leave people behind.

I mean... If I am not wrong, making a .pet, does not mean its for Puppy Linux... Its means its for this and that Puppy Linux...

So by entering a new era, ones need to unite at one standard...

And if that standard was to be something that takes Puppy away from this dependency issue, and built on ONE foreign repo, Its my guess that a smaller distro like Slitaz or Tiny Core is better than Debian, Ubuntu or Slackware, that are BIG distro with all kind off stuff under the hood already... Slitaz and TinyCore are small ones...

Tiny Core`s package setup is quite unique and rather non-compatible.
It uses Squash files of individual app. and lib. packages of files.
It has a nice set of dependency tree files that make it work well.

Only way to use them would be to mount the Squash files and copy them.
This would take up space in the Save file like a .pet package does ( Ugh...).
And I think Tiny Core and Puppy are just too different for it to work anyway.Last edited by sunburnt on Sun 11 Mar 2012, 15:48; edited 1 time in total

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum