howto build a grand unified puppy

[amish]

Your word processors are actually text editors. Big difference between the two Smile

just so long as we can agree they aren't graphics editors...

yes, the things under "word processing" in barebones are text editors. they aren't word processors per se, because barebones doesn't have one, but they are under the same category they are in under the puppy 2.11 menu. i haven't seen the xdg version yet. if you look in the core, there is abiword, which i consider a "word processor" because it handles layouts, pictures, and colored text and different fonts. that loads by default. otherwise, there is the optional ooo.sfs.

so- new page, i would rather leave the picture in... on a thread already this size, it shouldn't hurt for people to repeat a couple things:

"i'm not sure if this is technically possible..." the idea is: barebones (don't be fooled, mostly scripts) is 40-50ish mb
barebones+default core is less than 100 mb
barebones+core+all extra .sfs files is less than 400 mb

[blubb_fallo]

Phew, an whole lot of interesting stuff to read.

Thanks for the pointer, arnish. My idea indeed seems to coincede with wide parts of yours and even more with what NathanF apparently has already done in Grafpup (which I haven't tried yet).

Aren't the size figures still a bit high? As an admittedly extreme example, see Micropuppy with 12MiB. Thanks to MU, who reactivated the download yesterday, I could play around with it a bit - it's cute! Of course, all the wizards, installers, MUT, well, almost everything is missing, but still ... amazing. The Fox apps (XFE, adie, shutterbug) turn out to be a very good choice.

On the upper end, there is e. g. JM''s Mean Puppy 2.02 AKA PuppyOpera - mere 50 MiB and perfectly usable. Due to Opera, it provides not just slick and convenient web browsing (even including my beloved (customized) mouse guestures ), but also chat, a sophisticated news and email client, a download manager and even bittorrent. I'm still sticking with it (in the hope for the next PuppyOpera to come), because none of the other Puppy releases I have tried since then was nearly as efficient. Anway - that's just my personal favor, meant to indicate that 50MiB probably are quite a bit more than necessary for a "barebones" pup_xxx.sfs already.

For a fully modular Puppy, I would not bundle anything as unrelated as e. g. didiwiki and seamonkeymail together in one sfs, though. With a "modpup chooser" we could easily have 10 to 20 sfs to choose from at the first menu screen, and there should be a richer choice at deeper levels. Instead of putting the most likely wanted "core" apps into a single sfs, their (separate) modules could be preselected in the modpup menu to allow for easy first time booting.

See also http://www.murga-linux.com/puppy/viewtopic.php?t=15889 for more on this concept.

[amish]

Instead of putting the most likely wanted "core" apps into a single sfs, their (separate) modules could be preselected in the modpup menu to allow for easy first time booting.

here we have a difference in philosophy. i am aiming for a "more puppy-like than puppy" distro, one that shows you various things in core.sfs by default. this is a bit more like puppy has been as long as i've known him, since version 1.07 (not really, too much to explain there.)

making someone choose all that information on the first run would be daunting, i think. better to make it as undaunting as possible. while people try to make setup of puppy easier, others try to complicate it, i'm not sure which is worse but i'm referring to the "default" boot from cd... installing puppy will hopefully become easier, but is still an exception to the rule.

yes, it would be cool to have puppy small again, and that's really the reason why i've tried to come up with a way to make it 50, 70-80, and 400 in size, when 60 is becoming a thing of the past, when 70 is becoming 80 and 90, and 100, and when 400 is (damnit, no!) becoming 600 at which point puppy is just another fullsize cd distro. no! puppy is small.

but it's also simple. your "choose everything before you run" plan isn't fit for a livecd at all, imo. mine lets you get back to 50mb in a Hurry, without knowing much about puppy, but it also lets the person do it the old way: burn an iso and just run the thing and SEE a *working* os In Action. how many do that? well... kinda dsl, kinda, feather, they're okay. puppy was/is, imo better, and i don't want to be more like dsl. i want puppy to be more like puppy. (only moreso.) i think making it more modular can help, and yeah- grafpup 104 is a shining example to us all. i hope grafpup 2 is under 100mb. p.s. didwiki needs a browser, they go together better than you think. i only suggested it because it's already in puppy, and it's a pretty neat little tool.

[SirDuncan]

The only problem I can see with this is that, if I understand correctly, Puppy will only load one .sfs file into RAM. So Puppy would have to mount the CD and run from it, whereas it currently loads into RAM and then you can take out the CD. Am I wrong about this?

I believe there is a way to mount .sfs files without a save file. It would require modifying a boot script, but I'm not knowledgeable enough to say how.

[amish]

absolutely. we are talking about something still hypothetical that requires puppy to have SLIGHTLY MODIFIED capability. there are some that know how- nathan is one.

keep in mind i'm talking about something i sincerely hope will be based on a version of puppy with LGPL startup scripts. barry has been considering that since 2.14, 2.14 may have them for all i know, but if it's 2.16 or 2.18 i'd just assume wait for that. i don't know how or who the building will be / doing the building. it's what's called "pre-alpha" and hopefully not but potentially what's called "vaperware"

[blubb_fallo]

Instead of putting the most likely wanted "core" apps into a single sfs, their (separate) modules could be preselected in the modpup menu to allow for easy first time booting.

here we have a difference in philosophy.

I guess, we do have differences somewhere, but I'm not sure whether this is such a case. Maybe I should have duplicated some details from the linked-to other thread here: the modpup selector needs to have a short timeout, say, 3 or 5 seconds, so it is possible to interact if you want to change the default selection (or what was saved).

A first time user will hardly interrupt, but s/he will recognize that there is more that could be worth exploring later.

This behavior has an advantage over puppy's current implementation of the initial video setup wizard (which is skipped completely once you have made a choice): it is and remains evident when and where you can change the settings again in case that's needed, e. g. due to hardware exchange.
When you pay attention, it is not difficult to enter the dialog at the right moment, but the short delay does not affect the speedy boot experience, either.
You may check out e. g. UBCD to see this method in action.

i am aiming for a "more puppy-like than puppy" distro, one that shows you various things in core.sfs by default.
...
making someone choose all that information on the first run would be daunting, i think. better to make it as undaunting as possible.

I fully agree. I wouldn't want to have a first time user go through a sixteenfold multiple choice of module groups to load. That's no difference between our views. The difference, if any, is more about providing the user with either boulders or bricks.

[Colonel Panic]

For me the "bottom line" for Puppy is its speed; it has to be small enough to load completely into RAM.

I can click on an icon in Puppy and see that app load instantly, which I can't do in any other distro I'm aware of.

Having said that, more and more people now have 128+ MB of RAM, so I don't see any reason why Puppy can't be released in different sized versions for those with more RAM to play with.

[amish]

the modpup selector needs to have a short timeout, say, 3 or 5 seconds, so it is possible to interact if you want to change the default selection (or what was saved).

A first time user will hardly interrupt, but s/he will recognize that there is more that could be worth exploring later.

well that's interesting, and better than it first sounded.

I fully agree. I wouldn't want to have a first time user go through a sixteenfold multiple choice of module groups to load. That's no difference between our views.

mm, we probably still disagree on some minor things, although that's not a big deal. a lot of the time when people disagree strongly, they're disagreeing based on misunderstanding what the other person is really trying to say.

I don't see any reason why Puppy can't be released in different sized versions for those with more RAM to play with.

yes rather than three versions really, one that starts medium (but under 100mb) and can somehwat instantly become about half that, or 4 times that. you can fit almost anything in 400mb- but only with puppy. why? because puppy has always tried very hard to stay small, and it does an excellent job of its original goals, instantly rewarding people seeking that it do so. let's be fair, slax and sourcemage can do it too. (but they're not as simple as puppy.)

[John Doe]

T2!!!!!

[sunburnt]

Sir Duncan & Colonel Panic; If there are many sfs (Squash) files, then as many
can load into memory as there's space for them, manually or automatically.

I don't know why you'd want to not have a Save file... you couldn't install apps.


I just made a MicroMuppyOpera version with a 12MB core Squash file, a 6MB
image.gz file & the kernel is 1MB, that equals a total of 19MB in size.
But the Squash file's only 12MB, so it can load to memory on a PC with +32MB!

As MU said, it's good for specific purposes, really anything except games & movies as it has no Xorg, to add it would probably increase size by over 10MB.

[SirDuncan]

We want these .sfs files to load from a live CD before we have made a save file. The idea is to seperate the program suite from the core OS and still be able to run Puppy like we do now. I often show off Puppy to others by booting from a CD on their PC without a save file. If you can only load additional .sfs files with a save file, then our plan won't work.

[xwiredtva]

If I can I'd like to propose something here, maybe it's what everyones thinking but here it goes. Also been using Pup off and on since 1.02

One Solid Stable Base system, Barry has this covered.
Side devloped based of Base (we have this now)

One Package manager to handle all Pets/Pups with modifiable Repos... I know there is one but it's not built into the base.

One MASTER repository to get what you want, and spelled out better. I had to search left, right up and down to find Pizza and Graf...

I'd like to donate server space and bandwith as well as web design to the master repo for this. Subdomain was already setup at linux.simplistiksoftware.com and I'll setup anonymouse FTP access for the repo of Pups/pets. That is if it's OK with everyone.

I can take care of a Main Page with links to Barry's site, Grafs, Pizza but we should maintain all Master Distro's along with Base on ONE SITE to simplify everything.

Aside from that 2.14 is EXCELLENT! Kudo's to all developers! It's fantastic.

You can reach me on this board or linux (at) simplistiksoftware.com

While Linux is NOT what we do it is a hobby of mine since 1996. However the days with a 16 port KVM filled up in my second bedroom making PP&L rich are over. Really wish I had a picture of this setup, it was a mess.

[sunburnt]

SirDuncan; The Save file has nothing to do with anything except app. installs,
settings, & other stuff that's not saved on drive partitions etc.

The UnionFS stacks the sfs files together, with or without the Save file.
For Puppy-2 the union is made at bootup, Puppy-1 can swap sfs files anytime.
Any partitions, dirs., or image files you want to add, can be part of the union.

[Pizzasgood]

I don't know much about .sfs files, so I don't know if he's correct or not. But I think what SirDuncan is saying is that Puppy doesn't see the .sfs files to load them unless you have a save-file on the harddrive. I think otherwise it might ignore the harddrive.

I do know that Puppy does not see my devx_xxx.sfs file when I boot with pfix=ram. Only when I let it load a save-file. I don't know if it behaves the same way when there isn't a save file.

[Eyes-Only]

No, it doesn't see them Pizza. I can tell you this now so you can know. I just downloaded your Pizzapup 3.0 (by the way---a brilliant piece of work which pleases BOTH you & I!) and what I did before even starting the disk was to move the two "pza" files from the CD disk onto my second partition where I was going to keep my "pza_save.3fs" file after I did all my settings.

In the bootup process it scanned my entire hard drive, all 4 partitions, loaded the two "pza" files from the CD instead of the 2nd partition, loaded my swap partition, and away we went.

I then did all of my settings and saved the "pza_save.3fs" to the 2nd partition and rebooted. It was then upon the reboot that it found the two "pza" files right beside the save file and loaded from there. Total load time: 10 seconds to working desktop. Sweet!

I've likewise noticed this exact same behaviour with all Puppies and puplets Pizza. The save file must be created before it'll see the other two files from the hard drive. But until then it pulls from the CD disk.

I hope this helps?

By the way: I think your version and ToutouLinux are two of the most beautiful puplets out there. You've done excellent work in creating not just a highly functional and extremely useful puplet---but a gorgeous piece of art as well. Congrats!

Amicalement,

Eyes-Only
"L'Peau-Rouge"

[sunburnt]

Eyes-Only; The boot scripts sets this up, there's been alot of complaints about
how limited they are, however we must keep in mind all that Puppy does do.

To modify the boot scrips to fix this wouldn't be hard to do, & a DotPup or other
install package would be needed to apply the new boot script to Puppy-2.

It'd be nice if a Puppy-2 fix for swapping sfs files could be part of this package...
See my post:

http://208.109.22.214/puppy/viewtopic.p ... cd851b3530

[amish]

We want these .sfs files to load from a live CD before we have made a save file. The idea is to seperate the program suite from the core OS and still be able to run Puppy like we do now. I often show off Puppy to others by booting from a CD on their PC without a save file. If you can only load additional .sfs files with a save file, then our plan won't work.

with regards to my diagram, this is true. with regards to your idea sunburnt, obviously this is also true. specially regarding my idea: core.sfs would load without a save file. the larger .sfs files (which could go in another folder to avoid detection on startup) would require a save file to activate them either from the cd or the hard drive.

i suppose then core.sfs (the thing that makes barebones into normalmedium puppy) could be Deactivated via save file, too- thus, barebones!

and again regarding Your idea please come to the irc meeting saturday the 12th (time looks like it may be 12 to 2 GMT+0/england time, let me know your time zone.) and propose your .sfs tool to be included in CE. i'm sure it's lightweight, BEGIN with the acknowledgement that it may take a while to get .sfs working in their puppy 2 again, so they can't shoot it down by saying it doesn't work- we Know that. i'm very interested in restoring puppy 1's .sfs flexibility to puppy 2's list of abilities, but i wouldn't know how to even remaster it if i knew that much about coding it!

[sunburnt]

amish; I assume your post was refering to me... (if I'm wrong say so)

I'm in Arizona, we're backward here, we don't use daylight savings.
So at the moment I think we're the same time as California.

The last line of the quote you posted is wrong.

Puppy boots to X that's in the "boot" sfs, so that sfs file CAN'T BE REMOVED!

Lets set some terminology here & call the first main (X) sfs file, the "boot sfs".
Other sfs files have apps. in them so they're called "extra sfs" files.
So the terms "base" & "core" don't apply anymore... just to avoid confusion.

Save file or none, boot order, etc. are all part of the boot scripts & can be fixed.

The sfsManager could only load sfs files at bootup in Puppy-2 with no "fix".
Puppy-2 already does this to some extent, I think...

The union setup: SAVE.3fs (extra).sfs (extra).sfs (extra).sfs pup_BOOT.sfs
The last one is the "boot sfs" file with X & core apps. in it, the rest can swap.
The Save file's always at the top so it's files "overshadow" the lower files.
When a file's changed in the Save file, it's the file that's seen & accessed.

==================================================
I'm not very good at getting packages working, not like MU & others are.
AUFS should be tried in Puppy-2 to see if it solves the swapping sfs files.
Knoppix dumped UnionFS for AUFS, so this should be a good indicator for us.

We need someone like MU, GuestToo, Dougal, Gn2, or other "guru" to help.
If they build AUFS into Puppy-2 & it works, then it'll be a slam dunk it's good.
At that point the likelyhood it'll be incorperated into Puppy-2 stands a chance.

Hopefully someone will reply to my post asking if anyone has a fix for Puppy-2.

[Nathan F]

What if we used a system of cheatcodes to do it, like in Knoppix or DSL? In DSL you can boot with the command "dsl tohd" and it will copy the disk to the hard drive and run it from there. Similarly you can type "dsl restore" and it will look for a copy on your hard drives.

I've tried very hard to stabilize the addition and removal of squashfiles while already up and running and, well, I don't think we'll be able to do that any time soon. However, if a module was present on the live cd and you set up the boot scripts it could probably be loaded right when the union was created. Basically you type "puppy modules=opera,openoffice" at the boot prompt and it loads opera and openoffice along with the rest of the os. With a bit more work it might be able to work with modules stored on the HD. Anyway it would be a start. What do you guys think of that as an idea? The implementation would probably be a lot easier than inserting the modules on the fly, but still be a lot more flexible than what is offered right now.

Nathan

[sunburnt]

Hi Nathan; It's good to hear from you... So no luck with UnionFS in Puppy-2 ?

I'd like to work with you on this, because I think it's fixable, & IT'S IMPORTANT!

If you have time, let me know... I think the first real step is testing AUFS,
as Knoppix has ditched UnionFS for it, this is a damn good indication to us.

I proposed testing a Puppy 1 version with the loop devices in /usr & then the
unioned file's mount points in /usr, so each is inside the union at a time.
If one of these test setups acts like Puppy 2 does swapping sfs files... Bingo!

My other proposals were:
1) A "false root" so loops and/or mounts can be placed outside the union.
2) Make Puppy-2's dir. structure like Puppy-1's (easy to do & is an instant fix).

But testing AUFS is probably the best idea, rather than messing with UnionFS.

==============================================
See my post of my updated sfsManager & my new SFS file maker:

http://208.109.22.214/puppy/viewtopic.p ... 04cb11451a


Cheat codes or better yet a console menu for boot control & SFS file loading.
Auto. copy to RAM & load, if can't & source is on CD then copy to HD & load.
Menu time-out reads a config. file that loads a list of sfs files & boot control.
This is about all all that can be done at bootup, because both of these items
must be done before starting X in ANY Puppy version.
After booting, sfsManager can swap SFS files for Puppy versions that'll do it.

There's quite the discussion going about a Puppy version with a "base sfs" file
with only core apps. (X, Xorg, Geany, etc., a browser & maybe a IM app.).
The base Puppy would be ~ 40MB to 50MB in size, & swap "extra sfs" files.
The extra sfs files would be groups of "like apps." less than 100MB in size,
most less than 50MB, like XMMS & Mplayer + codec pack = 20MB extra sfs file.
With many smaller extra sfs files, they'll easily load into & out of memory.