Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 23 Oct 2014, 08:38
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
pUPnGO 2012
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 14 of 27 [398 Posts]   Goto page: Previous 1, 2, 3, ..., 12, 13, 14, 15, 16, ..., 25, 26, 27 Next
Author Message
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Wed 16 Jan 2013, 16:31    Post subject:  

greengeek:The h.pcf.gz origins from xwoaf and although a run of "mkfontdir" reveals only "h.pcf.gz -*-helvetica-*-r-*--13-130-*-*-*-*-*-*" the original xwoaf fonts.dir says:
Quote:
h.pcf.gz -adobe-courier-medium-o-normal--12-*-*-*-*-*-*-*
h.pcf.gz -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
h.pcf.gz -*-times-medium-i-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-r-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-bold-r-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-o-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-r-normal-*-12-*-*-*-*-*-*-*
h.pcf.gz -*-helvetica-bold-*-*--12-*-*-*-*-*-*-*
h.pcf.gz -*-helvetica-*-12*

I do not know how it was made so just used it. From time to time I try to get hold of the fonts in pupngo but I never really got a understanding of it...
Try to copy all original P412 fonts in there, remove the h.pcf.gz and see whats happening. You might also need to change the content of /etc/fonts...
The pupngo2012 has the gtkfonsel program but when choosing some of the present fonts it crashes.
Thats more or less what I can come up with...
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Thu 17 Jan 2013, 00:55    Post subject:  

goingnuts wrote:
I have been revisiting the build of busybox as the question arise if the umount of loop devises could auto delete the used /dev/loop. This remains unsorted but another thing popped up that I will report for future reference. I have used the same busybox source for pupngo through all the versions and the last rebuild was in June 2012. Since then I have changed my uclibc toolchain but the new builds of busybox uses the same source and the same .config file...

But now I have a problem with the xterm-wrapper script which wont launch rxvt. The original part that fail is
Code:
exec rxvt "${@}"

This make rxvt error out with rxvt: unknown "" or something like that...
By replacing the line with
Code:
#exec rxvt ${@}

rxvt is happy again...but thats not how the shell should pass variables.
So upgraded/rebuild gcc/uclib/kernel headers but no change.
To make this a bit short the reason was sed (GNU version 4.1.2 - it is too old to build BB-20100217 correctly). Replacing sed with BB-sed from the version I was building solved this misbehavior...


Hmm...don't get why that makes a difference.
Also, using "" for an argument is valid, so I don't see why "$EMPTYVAR" should be different, though I might be misunderstanding the issue.
"$MULTIWORD_VAR" is treated as a single argument, also.

FYI: Busybox 1.20.2 has a much more capable sed.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Fri 18 Jan 2013, 15:14    Post subject:  

Ibidem wrote:
..
Hmm...don't get why that makes a difference.
Also, using "" for an argument is valid, so I don't see why "$EMPTYVAR" should be different, though I might be misunderstanding the issue.
"$MULTIWORD_VAR" is treated as a single argument, also.

FYI: Busybox 1.20.2 has a much more capable sed.

Hmm...tried to reproduce...seems not to be sed...seems to be the parsing of CFLAGS to already configured BB...strange...
I configure BB with
Code:
CONFIG_EXTRA_CFLAGS="-static -Os -mtune=i386"

If I run just "make" the BB-binary seems ok...
If I run
Code:
make CC="$CC_GLOBAL" CFLAGS="$CFLAGS_GLOBAL" LDFLAGS="$LDFLAGS_GLOBAL"
the binary is not ok and gives the errors described above with
Code:
exec rxvt "${@}"

even if CFLAGS=""...I do not get it!

If compiling busybox-1.20.2 the error does not occour...so considering upgrade to busybox-1.20.2 in future pupngo´s but who knows what will break then...initial test shows different behavior of wc...pmfree reports wrong free space etc.
Back to top
View user's profile Send private message Visit poster's website 
greengeek

Joined: 20 Jul 2010
Posts: 2596
Location: New Zealand

PostPosted: Fri 18 Jan 2013, 17:44    Post subject:  

Does puppy HAVE to have busybox? What would happen to Puppy if it used a full command set?
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sat 19 Jan 2013, 03:59    Post subject:  

greengeek wrote:
Does puppy HAVE to have busybox? What would happen to Puppy if it used a full command set?

Can you spell B-L-O-A-T?

To elaborate, I can build a ~700k static busybox that provides everything needed to boot (I have run this as an OS). This equates to:
coreutils:12 MB
bash: 800k
dhcpcd (127 k) or dhclient 643 k
net-tools: 927k
module-init-tools: 340k
netcat: 192 k
sysklogd: 200 k
iputils-ping: 131 k
netbase: 98 k
sed: 52 k
awk: 322 k
util-linux: 2 MB
e2fs-progs: 2 MB
wget: 2 MB
bzip2: 156 k
...
ie, at least 20 MB.
Also you get slower startup, more RAM used, etc.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 781

PostPosted: Sat 19 Jan 2013, 10:36    Post subject:  

No doubt busybox is needed. We could get through without it using ams-utils or the "multical call binary-technique" (mcb) of original apps...but BB delivers most of what is needed out of the box. Would be nice if they delivered some overview of which version is the most stable and content of apps between versions.
Also a "long term maintenance" version of BB could be nice. Upgrading BB (like upgrading other software) has the potential of breaking your existing scripts - so every script needs to be verified that it does what it is meant to do. On the other hand the new versions might offer apps that eliminate use of org apps and by then potentially reduce complexity and size.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 19 Jan 2013, 15:06    Post subject:  

Ibidem wrote:
greengeek wrote:
Does puppy HAVE to have busybox? What would happen to Puppy if it used a full command set?

Can you spell B-L-O-A-T?

To elaborate, I can build a ~700k static busybox that provides everything needed to boot (I have run this as an OS). This equates to:
coreutils:12 MB
bash: 800k
dhcpcd (127 k) or dhclient 643 k
net-tools: 927k
module-init-tools: 340k
netcat: 192 k
sysklogd: 200 k
iputils-ping: 131 k
netbase: 98 k
sed: 52 k
awk: 322 k
util-linux: 2 MB
e2fs-progs: 2 MB
wget: 2 MB
bzip2: 156 k
...
ie, at least 20 MB.
Also you get slower startup, more RAM used, etc.

I wrote a small c init that will boot into X with jwm that compiles to a few kb. It wouldn't be that much more to add more of the boot process in parallel if anyone is interested. Tinycore has a patch to allow the initrd to be swappable (the initramfs I was using isn't) as well as a couple of other kernel patches that will speed up booting. Basically all you need for the desktop is xvesa/xfbdev, jwm, rxvt and a shell, but I never made them into a threadsafe mcb, so they can just as well be separate static builds.

over 90% of the boot process that happens before x can be in parallel.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Sat 19 Jan 2013, 16:25    Post subject:  

"Does puppy HAVE to have busybox?" Yes, Puppy probably does. No one else should have to suffer a complete system loaded with cut-down versions of everything. Yeah, there's a big size difference, but I like using the same toys that the BIG boys use... LOL
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2596
Location: New Zealand

PostPosted: Sat 19 Jan 2013, 16:33    Post subject:  

technosaurus wrote:
I wrote a small c init that will boot into X with jwm that compiles to a few kb. It wouldn't be that much more to add more of the boot process in parallel if anyone is interested. Tinycore has a patch to allow the initrd to be swappable (the initramfs I was using isn't) as well as a couple of other kernel patches that will speed up booting. Basically all you need for the desktop is xvesa/xfbdev, jwm, rxvt and a shell, but I never made them into a threadsafe mcb, so they can just as well be separate static builds.
This sounds rather interesting. I fear it will take me a long time to get to grips with all the things I don't understand about the boot process and componentry, but the more I look at the simpler stuff, the more I am learning.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sat 19 Jan 2013, 17:26    Post subject:  

to start X all that needs to happen is to mount /dev
to get a terminal emulator working, you also need to mount /dev/pts
and some (non-crucial) apps will need /sys and /proc mounted
this is one line of C each

While X is starting up you can load additional kernel modules, mount file systems, do checks, set settings etc... from kernel boot parameters (boot parameters should be the way most settings are stored so that you don't have to mount a file system to get them, but no-one else does it that way)

Once X and the wm are up, a terminal or gui setup wizard can be used for the rest (and jwm has a convenient startup tag... also restart and shutdown, but that is another topic)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2596
Location: New Zealand

PostPosted: Sun 20 Jan 2013, 01:01    Post subject:  

technosaurus wrote:
to start X all that needs to happen is to mount /dev
to get a terminal emulator working, you also need to mount /dev/pts
and some (non-crucial) apps will need /sys and /proc mounted
... you can load additional kernel modules, mount file systems, do checks, set settings etc... from kernel boot parameters
Once X and the wm are up, a terminal or gui setup wizard can be used for the rest (and jwm has a convenient startup tag...
I used the phrase "simpler stuff" but what I really meant was "more minimalistic stuff". Each time I read your posts I realise that the minimalistic stuff is way harder than the bigger stuff (like booting a fullblown puppy from CD...that I can do!) Smile

Understanding all this grassroots stuff about booting with the minimum required code is like getting to the moon on a bicycle. Enticing yet very difficult for the untrained Smile

Thank God for google!
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sun 20 Jan 2013, 02:57    Post subject:  

The only reason it is complex is because we made it that way over time. For example puppy's init has tons of bloat dealing with finding the correct partitions, sfs and save file when it could just be added as a parameter to the kernel command line (same goes for kb, resolution, drivers to load, language and many others). Perhaps early bootloaders lacked this functionality and this is a holdover that exists because things still work? I don't know, but I literally spent days turning on and off kernel options to boil it down to the salts and then did the same with init. Once I realized how little was actually needed, it just made sense to write it in c since it was basically:

Mount /dev and /dev/pts
Fork and exec X
Set some basic env variables normally found in /etc/profile and DISPLAY
Fork and exec the wm
(Logic to reboot/shutdown/restartx)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sun 20 Jan 2013, 10:42    Post subject:  

If you use Xorg or xfbdev, you'll need to load modules first.
And an autoconfigured X requires udev or hal. But then, most people use udev for /dev and loading modules.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Sun 20 Jan 2013, 14:07    Post subject:  

Ibidem wrote:
If you use Xorg or xfbdev, you'll need to load modules first.
And an autoconfigured X requires udev or hal. But then, most people use udev for /dev and loading modules.
there _is_ a builltin option, IMHO everything needed by init _should_ be built-in unless there is some conflict (but in that case I would just have a separate version for the broken device)

Speaking of loading modules, there is a recent kernel patch to load modules by filename (previously they had to be memmapped) that would make my flat module method much easier in c (by flat I mean all modules in 1 dir). Even with standard tools it was faster this way because it didn't need to recurse into subdirs. I know this doesn't sound like much, but loading a single module previously required several lines of code, much of which was unnecessarily complex.

Speaking of udev, it has grown into a behemoth, and the things it does _can_ be simple. I'll probably try to patch toybox's mdev instead.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
PANZERKOPF

Joined: 16 Dec 2009
Posts: 280
Location: Earth

PostPosted: Wed 23 Jan 2013, 13:41    Post subject:  

technosaurus wrote:

Speaking of udev, it has grown into a behemoth, and the things it does _can_ be simple.

Agree.
technosaurus wrote:
I'll probably try to patch toybox's mdev instead.

Busybox already has mdev, it can be used as simple udev replacement.
I made some scripts and mdev.conf file (Idea was borrowed from Alpine linux).
One problem was discovered there: It does not create device node for parallel port (LPT), althought all needed drivers was successfully loaded (parport, parport_pc).
mdev.tar.gz
Description 
gz

 Download 
Filename  mdev.tar.gz 
Filesize  1.59 KB 
Downloaded  132 Time(s) 

_________________
SUUM CUIQUE.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 14 of 27 [398 Posts]   Goto page: Previous 1, 2, 3, ..., 12, 13, 14, 15, 16, ..., 25, 26, 27 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1104s ][ Queries: 13 (0.0099s) ][ GZIP on ]