pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#346 Post by technosaurus »

#scottman CPU temp may need a separate parameter to change color, but the temp itself and kb up/down is pretty easy to do... as far as going over a taskbar, jwm has this weird nuance where horizontal trays only work correctly at the top and bottom and vertical trays only work on the sides (the tray will hide in the wrong place) ...I couldn't find the code that causes it.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#347 Post by goingnuts »

What should become of pupngo? I feel pupngo is close to mature and only small issues to be modified/added. Pupngo can run xwoaf, basiclinux, mulinux, dsl, tinycore, slitaz, INX, puppy 108-431 on top of it. It handles sfs, tgz, pet, dep, rpm etc. for extensions. Most important wizards run CLI/GUI. Load and save options of original puppy is working.

Only a few seems to use it for single application purpose or embedded systems which was the original target.

Plans of separating the kernel-modules from initrd.gz not fulfilled. Easy kernel shift not implemented. But does this serve any purpose?

Guess some "innovative" items popped up during the development of pupngo, I know it has been really fun and educational for myself to make it - but whats next?

With Baby-Linux upcoming, thoughts and ideas in the Saluki thread - what can/should be the room where pupngo add value?

Any comments welcome but I think I´ll take a break and not chase small incremental improvements to the 80:20 finished pupngo.

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#348 Post by starhawk »

I'd like to see a version of pUPnGO that could be used on really old systems (like that K6 heap of mine), where it was already configured for simple office tasks, but at its considerably dinky size, so that systems that old could still be made useful.

--off-topic-- XWOAF is great! But it doesn't boot on my 486 w/o math coprocessor. Is there an easy way to emulate that within XWOAF, or am I asking too much (no worries if I am, just wanted to be able to point and laugh at Linux on a 486 in this day & age...)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#349 Post by technosaurus »

486sx is _really_ obscure ... needs a kernel recompile to emulate the mmu and makes other architectures significantly slower... there was eboxpup, but I can't seem to find the ISO ... the architecture is still produced though (vortex86sx @ up to 800mhz iirc)

I've thought about doing a couple of things:
building all the apps into a single static multicall binary
a uclibc & uclibc++ or musl & stlport build (dietlibc has license issues)
porting all pupngo scripts to bashbox
reworking init using resource levelling for fastest critical path to minimal X... backgrounding the rest, but shift X basics to the initrd (+ 1mb)
compile a static webkit browser for the framebuffer
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#350 Post by starhawk »

I thought Vortex86 was a 5x86...? Could be wrong... been awhile since I looked at that, since the RoBoard 110* is a little much for my wallet (and my skillset).

*RoBoard 110 is a PicoITX motherboard designed for robotics applications. It's pretty fancy stuff, yo.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#351 Post by technosaurus »

you missed the _SX_ suffix ... its a different version ... its the only non-586 variant still in regular production.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#352 Post by starhawk »

Err... according to Wikipedia (or is that Wackypedia in this case?), the SX, DX, *and* MX are all 5x86-based. The SX version doesn't have an FPU and is slower, but those are the primary differences.

http://en.wikipedia.org/wiki/Vortex86
The CPU implements the i586 architecture, but the early versions Vortex86 original and Vortex86SX do not have a floating point unit (FPU).

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#353 Post by technosaurus »

http://www.freebsd.org/cgi/man.cgi?quer ... &sektion=1
while looking for an X equivalent of busybox, I found crunchgen. It can be used to combine several programs into a single binary.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#354 Post by goingnuts »

technosaurus: nice idea - this crunchgen - did you find a source and made it run? Is you plan sort of one bin for jwm, Xvesa, rxvt etc.?

I have been having some slow booting process after fixing the firmware load. So started out to time boot process: init (in initrd.gz) takes about 8 sec. By eliminating a few sleeps got it down to 3 sec.
rc.sysinit takes approx. 28 sec. but prompt does not turn up just after that - thats the main difference from before and after having firmware load work. Using org. modprobe seems to slow boot a bit down but is needed for firmware-script as BB modprobe does not take a conf.file.

Changed references in "pup_event_backend_modprobe" from modprobe to modprobe bin. This means that all normal modprobe uses BB and before mentioned script uses modrobe.bin. But still a delay before prompt gets ready. Have not solved this yet but if I remove pup_event_backend_firmware and pup_event_backend_modprobe from the system prompt comes fast again.

To speed up boot I moved some of the services script and the media-devices-script to run in parallel via rc.services. This reduce time in rc.sysinit to approx. 10 sec.

(all timings relative and from qemu...) Qemu is very good to do timings as every call counts - try one day to upx you busybox and watch a slooow boot.....

If time in init (in initrd.gz) is 3 sec before switch-root and the initial setup in rc.sysinit is fast (and it is) then one can get to a prompt fast skipping most of the steps in rc.sysinit - go directly into X and let jwm or xinit or someone else start the rest of the configuring. I think the main point is to get to a real prompt as fast as possible - Xvesa can start very early in the boot process but no other programs can use a running X at that time.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#355 Post by technosaurus »

essentially... I was thinking of shifting to xvfb instead of xvesa for portability (requires kernel recompile with console framebuffer, but the process could be repeated for other architectures) ... I found a copy of crunch in the dragonfly bsd git repo, but I had already started my own similar project, so I will probably just adapt the concepts (mine uses just shell scripts and a config file instead of C ... easier to modify)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#356 Post by nooby »

sc0ttman wrote:
goingnuts wrote:Would like to include as many drivers as possible in the next build...
You could start with the zdrv from Puplite 4.0 - it is a standard 4.2 zdrv, but I added most, if not all, of the extra drivers I could find for 2.6.25.16 (and I will add the one posted above, too!)

(I think it should work with 4.1, right?)
Guys I am not sure if I should try again. I am not structured in my head enough to be as patient as one need to get this driver things sorted out.

I remember vaguely that one version I tried acted like many Puppy 412 which it shared with many others that the LAN card in Acer D250 seems to not work with all standard puppies.

Jemimah made a good collection of drivers for her Fluppy and Pemasu used hers and others too so Fluppy and Snowpup are the puppies that works best on my machine. Lupu needs for the most time that I add nosmp to the kernel to boot correctly.

Some puppies just shut down the LAN card so I have to take out battery and take out the power plug and let it rest and then restart and the LAN card accept to get used again. Some kind of protection the machine have.

Anyway Goingnuts helped me with getting TCL going but unfortunate for me it was an older version of TCL maybe 2.9 or similar while they are at 3.5.1 or whatever now. So the repository TCZ files did not match so I did put pupngo on the backburner until the driver thing and the tCL thing sorted out.

So that was way back in February 2011 and now we are at April and I have forgotten almost all about what worked or not.


I do remember that pupngo in itself failed to get internet but using the TCL.sfs then I got internet. I could be wrong but that is how I remember now and I have a very bad memory but it is consistent with that TXZpup fail to get internet. Greenpup fails too and both are based on Puppy420 so that makes it unlikely that pupngo can get internet without adding drivers from other puppies?

I should read all 24 pages but feel unsure just now.

No demands or anything just my typical craving body longing for to be able to use TCL in puppy environ but their latest version.
Just my humble opinion. Discard if it is too unrealistic
I use Google Search on Puppy Forum
not an ideal solution though

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#357 Post by goingnuts »

nooby wrote:No demands or anything just my typical craving body longing for to be able to use TCL in puppy environ but their latest version.
Just my humble opinion. Discard if it is too unrealistic
Why not run TC as it is? Its not Puppy but...why not use it on its own premises?

Its fun to watch TC running as a sfs-extension on top of pupngo but making clones with another distro´s newest build seems kind of weird to me...and to make it as functional as the original seems a lot of work just reinventing what already there?

If you want to do it yourself I have attached a recipe for making a tc351-dress for pupngo. Its not fine-tuned but its a starting point. Also included main files you need to add/replace.

Concerning your net card in p4-series I did post a driver that might work here
Attachments
tc351pupngodress.tar.gz
recipe to make a tc351 dress for pupngo + unsquashfs4 + mod tce-load
(105.76 KiB) Downloaded 342 times

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#358 Post by nooby »

Thanks. I will surely test this when I find the inner courage to do such wild things :)

TCL default has no NTFS support until you download such NTFS 3 G something. SvOlli wrote a remix that had NTFS installed. I am trying to learn that one but it is very hard for me.
I use Google Search on Puppy Forum
not an ideal solution though

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#359 Post by goingnuts »

starhawk wrote:I'd like to see a version of pUPnGO that could be used on really old systems (like that K6 heap of mine), where it was already configured for simple office tasks, but at its considerably dinky size, so that systems that old could still be made useful.

--off-topic-- XWOAF is great! But it doesn't boot on my 486 w/o math coprocessor. Is there an easy way to emulate that within XWOAF, or am I asking too much (no worries if I am, just wanted to be able to point and laugh at Linux on a 486 in this day & age...)
I'm fascinated by xwoaf as well...and tried to compile the original kernel to try to enable "emulate the mmu" as indicated by technosaurus. But that is a no go - present compiler and libs wont do it. Think we need compiler and environment from the past to do such thing.

Then I thought of the bl3-dress for pupngo as it is compatible with slackware4 - which I think shipped with kernel 2.0 or 2.2. And gcc-2.7.2.3. And I have been able to set up a compiling environment on top of the bl3-dress. I haven't compiled any big and complicated things yet but it should be possible.

Maybe a route for your old K6? Maybe not as a pupngo-thing - you might be able to use bl3 as it is.

The bl3 dress also opens for some fun: Install icewm and mod it to look like XP or Vista...? :wink:

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#360 Post by starhawk »

Wow! I'm impressed; I really didn't think you were going to bother with that.

K6 "prove-it" box is on hold until I get some more hardware for it; mostly I need a case and a CD drive.

BTW, I've yet to use a version of pUPnGO that would support USB hotplugging. My "sneakernet" USB drive is a Lexar JD Firefly, and I've never once had it recognized by pUPnGO. My "regular" drive has the same problem IIRC, and it's a SanDisk Cruzer!

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#361 Post by goingnuts »

I have been working on easy kernel change in pupngo with one of the targets being the use of older kernels. Until now I have the newer kernels from P431 and Lupo525 working using the same main sfs-file but the jump to kernel from P108 seems more complicated...

I have xwoaf running on top of a pupngo with kernel 2.6.33.2.. :)

The USB hotplug I haven't tested - will do so. My USB wifi is recognized and firmware now automatic installed but that is not working in the released pupngo´s.
Update 290411: Test in pUPnGO_V412_060211 - USB drive is autodetected but desktop drive-icons will not reflect this as it requires a restart of jwm (and automount enabled)
fdisk -l shows the plugged in USB drives on my hardware...

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

revised otf_fsf_loader

#362 Post by goingnuts »

During my experiments with easy kernel change in pUPnGO a revision of otf_sfs_loader.sh was needed as it only worked with aufs1. So I have revised the script to handle aufs1 & 2, mount point now in /mnt/sfs, automatic (and silent) conversion between squashfs3 & 4 when needed and now keeping its own record of loaded files in /etc/otfsfs without interference with Puppys normal sfs-boot-loading stuff.
Still consider the script as a draft - not much advanced error checking code implemented. Tested in P412, P431 and (not very intensive) Lupo525.

I know others have made much more advanced scripts (ex. shinobars sfs_load on-the-fly) but as far as I know they do not work in CLI witch is needed for pUPnGO.

Static builds of mksquashfs3 & 4 and unsquashfs3 & 4 included in attached archive. Note: patched to only use one processor in order to build the static bins.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#363 Post by goingnuts »

More "issues" with lupo525 kernel 2.6.33.2: pmmon5.sh wont run...
Turns out that it refuse to run code like:

Code: Select all

TMPFL=/tmp/new.xpm
Z1 () { sed 's/Z1/s /g'; }
Z2 () { sed 's/Z2/s /g'; }
Z3 () { sed 's/Z3/s /g'; }
{ cat $TMPFL|Z1|Z2|Z3 > $TMPFL;}
This code runs without problems in P412/P431 - but with Lupo525 kernel $TMPFL is empty.
The code that will run with kernel 2.6.33.2 is:

Code: Select all

{ cat $TMPFL|Z1|Z2|Z3 > $TMPFL.tmp; mv $TMPFL.tmp $TMPFL;}
How can this script execution be depending on the kernel :?:
Attached a modified version of pmmon5.sh
Attachments
pmmon5.sh_020511rev.tar.gz
revised script for pmmon5.sh
(4.98 KiB) Downloaded 364 times

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#364 Post by sc0ttman »

goingnuts wrote:More "issues" with lupo525 kernel 2.6.33.2: pmmon5.sh wont run...
Turns out that it refuse to run code like:

Code: Select all

TMPFL=/tmp/new.xpm
Z1 () { sed 's/Z1/s /g'; }
Z2 () { sed 's/Z2/s /g'; }
Z3 () { sed 's/Z3/s /g'; }
{ cat $TMPFL|Z1|Z2|Z3 > $TMPFL;}
This code runs without problems in P412/P431 - but with Lupo525 kernel $TMPFL is empty.
The code that will run with kernel 2.6.33.2 is:

Code: Select all

{ cat $TMPFL|Z1|Z2|Z3 > $TMPFL.tmp; mv $TMPFL.tmp $TMPFL;}
How can this script execution be depending on the kernel :?:
Attached a modified version of pmmon5.sh
Not entirely sure its related, but I remember that when I made the advert blocker thing, that piping something ($TMPFL) to itself causes problems ... It did not for me, all worked fine, but I was using pup4... But others said my code didnt work, that seemed to fix it.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#365 Post by goingnuts »

sc0ttman: Thanks - just did not know that it could be kernel dependent...Annoying in this case as the number of file read/write increases a lot...

Post Reply