pUPnGO - 6Mb ISO - Basic Building Block Puplet
dietxlib published...
Works with a standard Puppy-412-devx dietlibc (v0.31?) and enable you to do quite tiny static linked X11 binaries.
Ex. 9menu compiles to 79Kb (make -f Makefile.noimake CC="diet gcc -Wl,--gc-sections,--sort-common,-s").
dietlibc has recently (20130312) released a new version - I haven't tested that but dietxlib-0.06 works with the previous version 0.32.
Works with a standard Puppy-412-devx dietlibc (v0.31?) and enable you to do quite tiny static linked X11 binaries.
Ex. 9menu compiles to 79Kb (make -f Makefile.noimake CC="diet gcc -Wl,--gc-sections,--sort-common,-s").
dietlibc has recently (20130312) released a new version - I haven't tested that but dietxlib-0.06 works with the previous version 0.32.
Exercising tinyxlib-4.8.0 - which is a tinyxlib born from patched full source of XFree86-4.8.0.
In the image below running 3 different bins of xcalc: Left is normal dynamic linked bin - middle is xcalc from tinyxlib-4.8.0 but merged with 9 other xutilities (xconsole xfontsel xload xmessage xvidtune xclipboard xcutsel xgamma xman) in a multicall binary - and right is single static bin from tinyxlib-4.8.0.
The mcb use 230Kb (or +25%) more memory than the standalone bin - but still only 26% of the memory the dynamic linked bin use.
In the image below running 3 different bins of xcalc: Left is normal dynamic linked bin - middle is xcalc from tinyxlib-4.8.0 but merged with 9 other xutilities (xconsole xfontsel xload xmessage xvidtune xclipboard xcutsel xgamma xman) in a multicall binary - and right is single static bin from tinyxlib-4.8.0.
The mcb use 230Kb (or +25%) more memory than the standalone bin - but still only 26% of the memory the dynamic linked bin use.
- Attachments
-
- snap0002.png
- (76.85 KiB) Downloaded 1564 times
Hey -- I don't know how earth-shatteringly nasty this is, but a friend of mine found a bug in ldso that (if I'm reading this correctly) affects uClibc, among other things -- which I seem to recall that someone was proposing to use in pUPnGO at one time.
Maybe this is why it didn't work out that way? (or, it's a big nothing and I can't read... that *is* possible, lol)
http://lists.uclibc.org/pipermail/uclib ... 48221.html
EDIT: also, at his request, here's my friend's website, with some uClibc dev stuff (a pair of chroot build environments) on the front page... nifty, if you know what to do with them
http://c02ware.com/index.php
Maybe this is why it didn't work out that way? (or, it's a big nothing and I can't read... that *is* possible, lol)
http://lists.uclibc.org/pipermail/uclib ... 48221.html
EDIT: also, at his request, here's my friend's website, with some uClibc dev stuff (a pair of chroot build environments) on the front page... nifty, if you know what to do with them
http://c02ware.com/index.php
Here's an update, looks like my guru friend has things fixed, at least in a quick&dirty way...
http://lists.uclibc.org/pipermail/uclib ... 48222.html
I'll let him know you're checking out his toolchain
http://lists.uclibc.org/pipermail/uclib ... 48222.html
I'll let him know you're checking out his toolchain
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
@goingnuts the mcb will use less on newer kernels due to copy on write improvement ...for each extra process
Edit: I recently revisited my alternative to the 'file' program for getting mime types (and the alternative xdg stuff that rox filer uses) and have significantly improved performance and added type deduction by magic values. I was thinking about patching rox to use it, but I also thought it may be good for rox to fallback to using the extension if its mime type is not handled.... for instance if a .dummy file is clicked it first tries to run application_dummy , but should also try running 'dummy' if it is application/unknown or application_dummy is missing. Any thoughts? If it matters, I have been using rox-0.1.39 mostly, due to its lighter weight, but this part should be compatible with later versions (it does add ~30kb to the binary for the sorted extension tables, but it is 99% constants) I am also patching it to use builtin xpm images for the toolbar and parent mime types (such as image, text, inodes, application, audio, video...) so that it can just be dropped and run anywhere without a bunch of extra files
Edit: I recently revisited my alternative to the 'file' program for getting mime types (and the alternative xdg stuff that rox filer uses) and have significantly improved performance and added type deduction by magic values. I was thinking about patching rox to use it, but I also thought it may be good for rox to fallback to using the extension if its mime type is not handled.... for instance if a .dummy file is clicked it first tries to run application_dummy , but should also try running 'dummy' if it is application/unknown or application_dummy is missing. Any thoughts? If it matters, I have been using rox-0.1.39 mostly, due to its lighter weight, but this part should be compatible with later versions (it does add ~30kb to the binary for the sorted extension tables, but it is 99% constants) I am also patching it to use builtin xpm images for the toolbar and parent mime types (such as image, text, inodes, application, audio, video...) so that it can just be dropped and run anywhere without a bunch of extra files
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: Might be that it should run a build-in universal file-viewer if unknown? Any links for the rox-0.1.39 source? I definitely like all your patch goals - much appreciated. Any chance of build-in check if an application needs a terminal to run (sometimes an application causes X to freeze or starts a 100% cpu usage in the background)? Might be worth to maintain the original behavior as well (ex: external images for toolbar).
The mcb is quite convenient for Xaw-hungry apps in terms of keeping size and memory usage down. Found that xman is really handy when offline - xcalendar-3.0 and xalarm-3.06 seems usefull to include in the basis X-environment too. And some of them can be "themed" to look quite nice.
The mcb is quite convenient for Xaw-hungry apps in terms of keeping size and memory usage down. Found that xman is really handy when offline - xcalendar-3.0 and xalarm-3.06 seems usefull to include in the basis X-environment too. And some of them can be "themed" to look quite nice.
I have been working on getting gtk2 running in pupngo - as static linked apps and using uclibc. Some sort of breakthrough using glib-2.16.6+atk-1.22.0+cairo-1.6.4+pango-1.20.5+gtk+-2.12.12...
The libs gets installed and simple apps like editor compiles error free.
Then if run in P412 they segfaults - I accidentally run one of them from within my chrooted toolchain - and after a while it suddenly turned up on the desktop. A strace pointed the segfault to happen when gtk-theme should load (pixman.so call). The app launched from within the chrooted environment used standard theme (Raleigh the only theme installed there) but desktop used Gradient-gray which include image handling. Changing desktop theme to Raleigh made the app launched directly work.
Now - how could an app launched from a chrooted environment find my desktop outside the chroot and show itself?
I am running Xvesa and the standard P412 xwin does not add "-nolisten tcp" to Xvesa parameters. If I introduce "-nolisten tcp" the app launched from chrooted environment does not show up but gives this message:
The static linked binary is quite big - fx. isomaster-1.3.13 is 5807K and theme cannot contain images - but beside that - might make it possible to create some of those apps which is hard to get if gtk2 is not supported.
The libs gets installed and simple apps like editor compiles error free.
Then if run in P412 they segfaults - I accidentally run one of them from within my chrooted toolchain - and after a while it suddenly turned up on the desktop. A strace pointed the segfault to happen when gtk-theme should load (pixman.so call). The app launched from within the chrooted environment used standard theme (Raleigh the only theme installed there) but desktop used Gradient-gray which include image handling. Changing desktop theme to Raleigh made the app launched directly work.
Now - how could an app launched from a chrooted environment find my desktop outside the chroot and show itself?
I am running Xvesa and the standard P412 xwin does not add "-nolisten tcp" to Xvesa parameters. If I introduce "-nolisten tcp" the app launched from chrooted environment does not show up but gives this message:
Code: Select all
(editor:11707): Gtk-WARNING **: cannot open display: :0.0
- Attachments
-
- snap0001.png
- static linked isomaster running in P412 with using the "Default" gtk2 theme
- (31.81 KiB) Downloaded 614 times
Hi goingnuts
I am not sure but a read here may help
https://wiki.archlinux.org/index.php/Change_root
Further down see : "Run graphical applications from chroot"
I am not sure but a read here may help
https://wiki.archlinux.org/index.php/Change_root
Further down see : "Run graphical applications from chroot"
[color=red]Anyone can build a fast processor. The trick is to build a fast system. (Seymour Cray)[/color] :wink:
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
In your chroot you'll need /tmp/.X11-unix/<display>
Note that you can use env -i var=val ... <command> to pass the exact env vars that you want.
You can run a separate Xserver like xnest so that it comes up in a window.
It's good for testing various window managers/desktop settings for lower resolutions.
Note that you can use env -i var=val ... <command> to pass the exact env vars that you want.
You can run a separate Xserver like xnest so that it comes up in a window.
It's good for testing various window managers/desktop settings for lower resolutions.
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].
also available at:
http://pupngo.dk/
and the source available at:
http://pupngo.dk/xwinflpy/xwoaf_rebuild.html
I was thinking it would be cool to put all this into an initial ram disk. Not sure why one would would need this yet but would like to learn.
s243a
there were many other tiny puppies
but
pupngo was/is THE minimal modular puppy
because it was so sophisticated
i could never understand why the other gurus
didn't join in its development
if you play with it
please post your thoughts on this thread
I'm sure many people would be interested
wanderer
there were many other tiny puppies
but
pupngo was/is THE minimal modular puppy
because it was so sophisticated
i could never understand why the other gurus
didn't join in its development
if you play with it
please post your thoughts on this thread
I'm sure many people would be interested
wanderer
I think that the LazyPup & T.O.P.P.L.E.S.S series had somewhat similar of a philosophy in that SFS were used as much as possible. I was thinking of pupngo as an intial ram disk with the option of either booting into a minimal pupngo desktop environment or a more modern T.O.P.P.L.E.S.S style environment. I have a fair bit of learning to do first and limited time so don't expect me to get their over night.wanderer wrote:s243a
there were many other tiny puppies
but
pupngo was/is THE minimal modular puppy
because it was so sophisticated
i could never understand why the other gurus
didn't join in its development
if you play with it
please post your thoughts on this thread
I'm sure many people would be interested
wanderer
s243a
thanks for reminding me of lazypup and topless
im not very familiar with them
but they seemed like great systems
with an enormous amount of effort put into them
maybe the ramdrive control system
and the the sfs files from them can be used
i do believe that a minimal ramdrive
with added sfs files is the way to go
since it makes each part more manageable and independent
i continue to play with tinycore/corepup
since i like the symlink system better than the union file system
but it would be great to see something that uses puppy stuff
i do intend to convert puppy sfs files to tinycore tcz files
and i feel that this is all the same concept
as to feeling pressured
i just do things at my own pace
since i have other responsibilities
and i want to keep this an enjoyable exercise
its just nice to talk to someone about these ideas
good luck
i will be following this thread with great interest
wanderer
thanks for reminding me of lazypup and topless
im not very familiar with them
but they seemed like great systems
with an enormous amount of effort put into them
maybe the ramdrive control system
and the the sfs files from them can be used
i do believe that a minimal ramdrive
with added sfs files is the way to go
since it makes each part more manageable and independent
i continue to play with tinycore/corepup
since i like the symlink system better than the union file system
but it would be great to see something that uses puppy stuff
i do intend to convert puppy sfs files to tinycore tcz files
and i feel that this is all the same concept
as to feeling pressured
i just do things at my own pace
since i have other responsibilities
and i want to keep this an enjoyable exercise
its just nice to talk to someone about these ideas
good luck
i will be following this thread with great interest
wanderer