Hello Those responsible for all the great Puppy only apps like Pburn etc
In a comment posting on this forum else where by user Big_Bass got me thinking.

It might be in Puppy's benefit to take these Puppy only Apps and make them work with Ubuntu, Slackware etc.

Imagine Pburn sitting on a couple million Linux Desktops pretty cool hey.
Might inspire other non puppy programmers to create small fast apps not bloatware so many here hate.

How hard is it to do? What's your thoughts.

Maybe post a .deb of your app on the Ubuntu forum and see what happens._________________Legacy OS 2.1 LTS Released! Install me on a new! EXT2 Partition with 500Mb of swap and I'll be happy.
Legacy OS 4 Released! Install to newer legacy hardware / early EeePC's

Through this forum and my website/email, even I have had requests to make the following work on other distros: Firedog, Pup-Advert-Blocker, Rom-Loader, VLC-GTK, BIOS-Installer and others...

I never got around to it though..

People on this forum have made stuff way better than any of that - I am sure their work would be greatly appreciated on other distros.

It would also be a great advert for Puppy...
But then part of me (the happy Puppy user) thinks we should keep all the great work done by Puppy devs all to ourselves!! _________________Akita Linux, VLC-GTK, Pup Search, Pup File Search

Anyone who really wants to be taken seriously as a developer and have maximum impact from their work should definitely think long and hard about this.

The main obstruction is the non-conforming paths used in (P)apps. But come on, is it any harder to write '~/path' than /root/path
And learning what the many standard parths are really for is essential. Most apps meant for normal users go in /usr/bin, and most apps meant only for root users go in /usr/sbin. The paths /bin and /sbin are for programs which must be available from the moment that the root '/' partition is mounted -stuff used by init scripts and/or daemons. Many syszems mount a separate partition for /usr, so programs under /usr/bin or /usr/sbin are assumed to be not needed near the top of the init scripts.

I cringe every time I see some puppy-fied app with hard-coded paths like /usr/local/bin, /usr/local/appname/bin, etc. One should realize first that no real distro ever delivers a single file installed under /usr/local. /usr/local is supposed to be for applications which are compiled locally, by the sys admin, in an un-packaged form (using 'make install' or manuall copied scripts). Having some wrapper script at /usr/local/bin/proggie which cd's into /usr/local/proggie to run the real program at /usr/local/share/proggie/bin/proggie or /usr/local/proggie/share/bin/proggie is absolutely nuts!

It's fine that Puppy does some things differently than most distros, but insisting on doing everything in the most ad-hoc, insane form is what keeps puppy out of the mainstream. Knowing about, and reasonably following the sensible standards will only improve Puppy and make it 'palatable' for more users and especially for more talented developers.

Many of the ideas and concepts which come from Puppy devs and users really are good. Having them implemented in a standardized fashion would only increase interest in them from devs and users.

Thanks for this most thread -one of the most reasonable ones I've seen around here...

I'm not exactly _for_ it either.
Bug fixes to meet rare corner cases in distros A-Z will likely just add more bloat than functionality added through their contributions.

but to expound on amigo's points.
Here are ways to make them more portable:

replace /usr/local/<p_app> with /usr/share/<p_app>
replace /root/... with $HOME/... (or ~/...)
realize that the gtkdialog3 binary would just be gtkdialog (no "3") in most distros (if it exists at all)
consider whether su, sudo, etc... _should_ be needed
don't assume that binary x, y or z exists in every distro, just because it is in every puppy - add it to the dependency list (examples are Xdialog, yaf-splash, gtkdialog, etc...)
To allow for community contributions, some version control system would be needed (which requires dev buy-in) Angel Ortega's bky seems to match best with the puppy style

Now maybe this one is just a coding style, but I see no reason why a single script based program needs to be broken up into separate files when functions will do the same thing. (file clutter, speed, duplicated code, compressibility...) I started adding P-apps to bashbox (pprocess, ffconvert, woof apps and a couple others so far) but the more I added the more I realized that they were doing a lot of the same stuff and could greatly benefit from some refactoring. The whole thing is only 1 file containing all functions plus a small wrapper script to run the functions as if they were scripts._________________Web Programming - Pet Packaging 100 & 101

@amigo thanks for posting the paths and tips to allow for more standardized code

no person who really wants to be part of the linux community
would deliberately write code for one version or just one distro
if it was done in ignorance that could and should be corrected

what I agree with is small apps with less dependencies
when possible but still usable across the wider community

we got the small apps I like that part. I dont like the part that we have apps that wont work across the wider community
there is a lot of room for improvement needed there
thats why progress is so slow and bug fixing is so labor intensive

I gave the hint about using $HOME or '~' instead of /root, but actually there should be nothing in the /root directory at all when the distro is freshly installed. So, all apps that currently try to install themselves under /root should be given a hard look to figure out where they should go.

The hard part is doing things so that the unionfs mounts work intuitively along with sfs's and whatever else is dynamically mounted. This means having a hard look at the priorities and methods for making dynamically 'loaded' progs/libs available in a clean, cutomizable way. Much of this work is done by the initrd and/or in the init scripts. As it is now, every conceivable possibility is handled by a single initrd and boot scripts -which makes puppy unnecessarily slower during bootup. If it were me, I'd use (install) separate scripts (and initrd if needed) for each type of installation. In other words, if you install puppy to the hard drive, you should get a clean normal boot sequence that doesn't waste time looking for or acting on LiveCD functionality. Same for frugal installs -use a separate initrd which only works for frugal installs. As it is, the initrd scripts and init scripts are an unholy mess, what with all the different options.

If it were me, I'd put only things needed at *early* boot-time in the initrd -mainly the dirs /lib /bin and /sbin. This would include all the kernel modules and all of the glibc stuff -the stuff which should only be upgraded/changed when creating a brand new distro version. The rest of the system, consisting of all the *applications* (including all GUI stuff), would go in a separate image(sfs or better ext3 filesystem image) which could be union-mounted on /usr. Then any extra applications could be installed, mounted or whatever, and finally items from the 'save file'. Obviously(??), the extra applications and 'save file' stuff would take priority over the standard items included in the main 'usr' image, so that upgraded applications would be the ones seen and used.

All the stuff which puppy applications now do under /usr/local could be better done under /opt instead, except that most of them really should just be using /usr -whether they are part of the initial stuff mounted on /usr, or part of some later extra or 'save file' item.

I would do away completely with using squashfs to avoid the need for extra kernel patches. By using ext2 or ext3 images, they could always be resized dynamically when possible or needed.

I built a system using several of these features some years ago -I used *.iso's to contain any extra optional programs. The init scripts had a routine which would mount them on-the-fly when present. Size was kept down by using zisofs (iso with compressed content). zisofs is readily available in the kernel and operates transparently so no extra steps are needed to make use of such iso images.

I gave the hint about using $HOME or '~' instead of /root, but actually there should be nothing in the /root directory at all when the distro is freshly installed. So, all apps that currently try to install themselves under /root should be given a hard look to figure out where they should go.

I was just trying to clarify ... that the only things that should go in $HOME should be limited to configurations files, but they should not install there directly. Convention for initial installation would be to put the default configuration in /etc/.program or /etc/program/<config_file> or even /usr/share/program/<config_file> Typically a program would look first in $HOME then fall back to expected default locations or builtin values.... meaning it is ok to save config files in $HOME when the default settings are changed by the user, but not until then. Does that sound accurate?

the whole /bin /sbin /usr/bin /usr/sbin /opt/bin /opt/sbin /usr/local/bin ... is really more of a leftover of distributed file systems and smaller drive capacities than anything else - many embedded systems just use one of /bin or /usr/bin and symlink the rest "just-in-case" ... same for /lib and friends (it speeds startup time too, because programs find a bin or lib in the first place they look - not having to recurse the paths)_________________Web Programming - Pet Packaging 100 & 101

"Does that sound accurate?" Yes, well put. It's worht mentioning that, on multi-users systems, default config files or other items which would go the users $HOME directory can bve put in /etc/skel -when a new user is created, the files will then be automatically copied to the users' $HOME dir with proper permissions.

I think that the directory structure is not a leftover, at all. Many, many users still use more than one partition when installing to a hard drive -some even use networked mounts, so the 'hierarchy' still has much relevance. I also think it has bearing on LiveCD's as it allows you to divide the libs and programs in a logical and useful manner. As I mentioned, most applications should go under /usr, so treating all that content as separate allows you to create an upgraded /usr with newer or simply different programs -without having to vhange the 'core' content that goes in /lib /bin and /sbin.

As it is now with Puppy, things are just put *anywhere* since roo has all privileges. For making apps which will work with some, or most, other distros, the purpose of each of the locations needs to be respected. Following the recognized standards will certainly not puppy or its' apps and would make it much easier to integrate things from other distros into puppy and vice-versa. It would also teach puppy users and devs to be more conformant and make life easier for them when doing anything with another distro.

There have been many attempts to create distros with a supposedly better file-system structure -but every one of them has bombed. Gobo linux is the only one that has lasted anytime at all, but it is really the worst case because it actually increases the links-spaghetti mess. Not using the logic of the hierarchy standard closes man doors for puppy, and doesn't open any new ones. Doing things the 'right' way would make puppy more viable as a server and as a multi-user system, among other things. It's still a snap to implement the perceived benefits of running as root and having autologin, without that being the only way to run puppy. Most importantly, following a more normal system design would make it *much* easier to implement puppy for use as an embedded system or as an installed system on specific devices like netbooks or tablets. I'll elaborate a little on that:

If all applications were bundled into a group under /usr, then you'd be able to use the same bundle on most any sort of system -the 'tricks' needed to boot as a LiveCD or frugal installation are all done by the initrd or during early boot time. So, you'd only need a special 'early system' (mainly /etc /lib, /bin, sbin) tailored for each use case. In fact, most LiveCD's try to use mostly-normal init scripts -letting the initrd do all the tricks before root is ever mounted -and this makes lots of sense.

It's worth thinking about just what it is that makes puppy stand out from other distros and just what it is that makes people prefer it to other distros. Note that these questions of hierarchy have nothing to do with this! Here's what I think makes puppy different:

Item (1) is a plus or a minus depending on how you use puppy (or not). As stated above, these two behaviours can be implemented without them being the only way (or even the default way) to use puppy.

Item (2) refers to the ability to run from CD, USB, Hard Drive, CD/DVD RW, etc. Puppy is not unique in this respect and actually suffers as a result of the wide variety of methods available. Better separation of functionality within the directory structure would make all this easier to manage and could make for a faster system -any sort of installation could disregard all the other options(by taking the code out of init process)

Item (3) is really what makes most 'puppians' love Puppy. And since we are talking here about making puppy applications more 'portable', its' worth noting that this is the area where the most improvements could be made.

I mentioned puppy for netbooks, tablets and other small devices. Using a LiveCD distro as a base for such systems is really not ideal. These devices should have all their RAM available for programs to use and have no need of 'save files', union-mounts, etc. And since each is a real installation, all the LiveCD initrd and init tricks are nowhere near what is ideal for them. Having the components of puppy better separated would make it much easier to implement such systems and require less duplication of work.

How much time and effort would it take someone like yourself to produce a hacked initrd.gz which is only for live CDs?
...and another one only for frugal installs? (and maybe another one for full HD installs?)

And what would be the next step?
Configure a boot manager (such as grub) to boot using the relevant initrd.gz?

I am also assuming once booted, having used a hacked init script won't matter at all...

On another note, I think the wrong directories being chosen by puppy devs for rc files etc, may be down to lack of consistency in puppy itself.. But I'm glad to have learned a few things on this thread._________________Akita Linux, VLC-GTK, Pup Search, Pup File Search

It's worth thinking about just what it is that makes puppy stand out from other distros and just what it is that makes people prefer it to other distros. Note that these questions of hierarchy have nothing to do with this! Here's what I think makes puppy different:

You've almost got the nail on the head - but for me point 2) is the most important. And you miss something - which is the ability to install the OS by copying 3 files, and ability of "instant recovery" by using pfix=ram, on a frugal installation. Should this still fail, then point 2) is useful - boot from CD, USB, etc to recover (again, by copying 3 files).

Quote:

I mentioned puppy for netbooks, tablets and other small devices. Using a LiveCD distro as a base for such systems is really not ideal. These devices should have all their RAM available for programs to use and have no need of 'save files', union-mounts, etc. And since each is a real installation, all the LiveCD initrd and init tricks are nowhere near what is ideal for them. Having the components of puppy better separated would make it much easier to implement such systems and require less duplication of work.

That's what pfix=nocopy (formerly called pfix=noram) is for. It doesn't work for all versions of puppy (I remember there were versions where this feature was dropped due to bugs in aufs/unionfs) - but when it work, it work great. Especially in netbook, the 2) versatile booting method allows me to do 3-file install in 3 minutes with instant recovery capabilites. Something which isn't true of of other distros.

Everything else is valid - and like you say, can be implemented in other ways. Actually zisofs looks interesting, and it seems to have been part of mainline kernel for years. I think the reason squashfs was chosen was because in the past you can use lzma which compress better than gzip compression used by zisofs - but this isn't true today, squashfs seems to use gzip only these days.

Back to the topic - people have dream about "write once run many" and there have been many efforts to achieve that in the past. Not many are successful. I think similar situation applies to Puppy apps. Sure, writing in compliance with LHS will help - and goes a long way. But like technosaurus wrote, if we really aim for many-distro compatibility, all it does it bloat. I'd rather we keep targetting Puppy (while at the same time applying all the good ideas you have mentioned) - and if the apps are good enough, I'm sure someone else from that other distro will come, take it off, and modify it to run on their favorite distro._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

I don't think that writing apps with compatibility in mind necessarily makes for bloat. In fact, Puppy is based on hundreds of real binary programs which were mostly written to be as portable as possible.

Of course, there are usually a few (or many) things in any distro which require heavy 'tailoring' in order to make them serve the purposes of the distro at hand and sometimes these changes are not compatible with other distros. Still, they are usually modifications of already-existing 'generic' applications as opposed to apps unique to the distro. Learning and using the principles of LFSH can only make things simpler for new and old devs and make the product more palatable for everyone.

I'm not a dev -- coding limited to a little bash-- so keep that in mind. But following varies threads, I boot several Puppies which I frugally install on the same partition. Consequently, I have a preference for Sfses, and applications like DaveS's Foxyfun and Opera_mnt_home, which install to mnt/home and, thus can be run from several puppies. I also boot Linux Mint & pclinuxos. Thanks to Stu90's mention of them in the threads, I also use a couple of portablelinuxapps in Lupu & sPup, which can also run under Mint.
So my suggestion regarding building Puppy Apps that could be run from other distributions, rather than trying to emulate the Linux "norm" of file structure --which, in fact, may differ from one distribution to another-- is that apps be build to install to their own directory in mnt/home. Probably an app will need a symlink of its executable to /bin or usr/bin, and an icon in /usr/share/pixmaps called from a desktop file. Otherwise, the file structure of the "adopted" distro would be left alone, so as note to overwrite native libs and other files.

+1_________________adobe flash is rubbish!
My Quote:"Humans are stupid, though some are clever but stupid." http://www.dependent.de/media/audio/mp3/System_Syn_Heres_to_You.zip http://www.systemsyn.com/

mikeslr, the LFSH already has a place dedicated to apps which 'do their own thing'. That place is /opt and is especially reserved for apps which do not follow the normal placement of files. It used to be used by both gnome and KDE, but they now conform. /opt is also well-suited for many old or simple UNIX apps which expect to find their data or conf files in the same directory as the binary. The only 'rules' for using /opt are that all files should be under one main dir. Inside that dir they can do anything they ant. It provides a good place for installing more than one version of a program, for example.

Obviously, one would have to supply links or wrappers somewhere in the normal PATH to the programs for them to be readily available. You mention using /mnt -/mnt is really meant to be used by the adminstrator for temporary mounts. Hence the usage nowadays of /media for more-or-less fixed mount points and for mounting removable media which may be mounted by or for users.

Thus there is already a place available for all those weird apps which are going all over the place in Puppy -a link 'app' in /usr/bin which points to a wrapper /usr/local/share/appname/bin/app, which then cd's into /usr/local/appname/bin and runs the program 'app' which then looks in /usr/local/appname/share for a dir name appname, which is actually a link to the folder /usr/local/share/appname to find its' conf file which is located in /mnt/home/appname/local/bin/share/appname/bin/share/conf/app.conf -but that's really a link to /root/.etc/share/home/local/appname/bin/share/conf/bin/bin/share/share/share/conf/appname/app.conf !! And then the conf file is empty....

Course if you like GoboLinux, you'll find that all those dirs named /usr, /bin, /etc, /sbin, /home are actually links to hidden dirs named /.Applications/Programs ./Users/Programs, ./System/Administrator/EditableTextConfigurationFiles, ./System/Adminstrator/Programs/Administration/System and ./Users !! Got it? Do you see just how much sense it makes to have place for everything and everything in its' place -just like that now-not-so-confusing-looking LFSH

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