pUPnGO - 6Mb ISO - Basic Building Block Puplet
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
#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].
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.
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.
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...)
--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...)
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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
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].
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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
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).
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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].
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.
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.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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].
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.sc0ttman wrote: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!)goingnuts wrote:Would like to include as many drivers as possible in the next build...
(I think it should work with 4.1, right?)
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
not an ideal solution though
Why not run TC as it is? Its not Puppy but...why not use it on its own premises?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
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
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.
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
not an ideal solution though
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.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...)
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...?
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!
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!
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...
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...
revised otf_fsf_loader
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.
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.
More "issues" with lupo525 kernel 2.6.33.2: pmmon5.sh wont run...
Turns out that it refuse to run code like: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:How can this script execution be depending on the kernel
Attached a modified version of pmmon5.sh
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;}
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;}
Attached a modified version of pmmon5.sh
- Attachments
-
- pmmon5.sh_020511rev.tar.gz
- revised script for pmmon5.sh
- (4.98 KiB) Downloaded 364 times
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.goingnuts wrote:More "issues" with lupo525 kernel 2.6.33.2: pmmon5.sh wont run...
Turns out that it refuse to run code like:This code runs without problems in P412/P431 - but with Lupo525 kernel $TMPFL is empty.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;}
The code that will run with kernel 2.6.33.2 is:How can this script execution be depending on the kernelCode: Select all
{ cat $TMPFL|Z1|Z2|Z3 > $TMPFL.tmp; mv $TMPFL.tmp $TMPFL;}
Attached a modified version of pmmon5.sh
[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]