Puppy In-House Development

Under development: PCMCIA, wireless, etc.
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#21 Post by amigo »

Hmm, I don't see anything on the menuet site or in their docs that would indicate that BK ever had anything to do with the project. Perhaps he simply created some examples and docs in English:
I have a webpage dedicated to MenuetOS:

MenuetOS webpage: http://www.goosee.com/menuetos/
perhaps should read:

Code: Select all

I have a webpage dedicated to MenuetOS:

My MenuetOS webpage: http://www.goosee.com/menuetos/

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#22 Post by Ibidem »

Also, I noticed in the README for lazy-utils something about "being a BSD-licensed replacement for toybox and busybox"...
Busybox I can see; it's GPL, has tons of features, but the code is written for size and not clarity.
OTOH, I'm wondering why a replacement for toybox: it's clear C99, kept to a set of programs with a clear rationale, and the license is more permissive than 2-clause BSD ("0-clause BSD", which is barely outside PD).
Now, some thoughts as to minimalism:
-ls -l, and so on, are very important tools.
-cat is by design intended to open multiple files (the name comes from "concatenate", and the original version shown in "The C Language" by K&R handles multiple files).
-A loop is very simple in C, indeed simpler than in shell:

Code: Select all

 for(int i = 1; i <= argc; i++) {
   //loop body: use argv[i]
 }
-A very large part of the functionality you're removing relative to the standards and toybox/busybox is essential to running build scripts.
-You're not using getopt!?
-mount sure is deeply indented: using

Code: Select all

if (0 == strcmp("loop",token)) {
        *is_loop = true;
} else if (0 == strcmp("ro",token)) {
  //continue in like vein
would be a lot nicer to read.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#23 Post by amigo »

Ibidem, you bring up a *big* point or two. First, why always re-invent things -a big part of the success of *nix OS's is owed to their re-use of existing tools. There are always folks (usually youngsters) who come along, see a bit of existing code and say "Oh I can do that much better". They then proceed to gut the functionality, change the accepted/expected syntax, etc, until the resulting program in no way constitutes a replacement for the original tool.

Actually, the whole idea of using *any* lite replacements -like busybox, toybox, cruchbox, etc, quickly becomes a handicap. Puppy handle this in the worst way possible. Instead of simply using the existing tools which provide the expected behaviour/features, bot the FULL and busybox versions are shipped -with an intervening shell-script in place of the real tools, which then decides which of the two versions to use. Why not simply use the right tool to start with -with the normal syntax like everywhere else?

We currently have a couple of small groups which are re-inventing *lots* of wheels at the same time. The trouble with that is that by the time you have enough re-implementations to make any difference (vis-a-vis size, license, etc), the whole cycle must be re-started because so much time has been lost.

Building a distro is a *lot* of work and all efforts should be made to re-write as little as possible. There are a couple of areas where individual distros do traditionally write their own tools -principally regarding the package format and the tools to create and manage those packages, and the boot (init script) process. Building a LiveCD distro encroaches heavily on these areas -but still when properly implemented, the user experience should be nearly identical to that of running a normally installed distro.

Unfortunately, a LiveCD is much like a 'software appliance'. Since there is a defined list of software included, it is impossible that all users will be happy with that selection. So, particular attention should be given to the concepts of modularity and extendibility. If not, then you create a situation like what exists with puppy, where every Tom and Harry is creating a derivative, spinoff, remix, remaster, etc. And these derivatives all deviate from the parent and others in incompatible ways -because the original product is not created as a modular, extendible base. All these extras which are enabled by the derivatives *could* be done in such a way that they would all work together (or provide workable alternatives) -if the concepts of modularity had been addressed and the proper infrastructure was in place.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#24 Post by Iguleder »

I'm unaware of any BSD-licensed busybox-like tool with good code (i. e toybuf in toybox is ugly as hell) and true minimalism. lazy-utils does not adhere to any standard, so it misses some features beyond its scope and it's fine.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#25 Post by amigo »

I knew I'd ruffle some feathers with such comments... I simply find most implementations 'minimalism' too limiting for any sort of general use. If you want to build a really tiny system with a very defined purpose, then it can make sense to re-implement some or all of the functions of exisiting tools for the purpose. But, for any system which proposes to be of general use (by extending it, for example), the practicality of re-writing many things becomes a major burden. And, unless the new implementations implement all of the options and syntax of the normal tools, the end result will still be less than optimal. Working around the removed functionality then becomes an extra burden.

On the other hand, re-implementing things is a great education and licensing issues do provide a reasonable reason for doing so. It's just that a single person is never gonna get very far with the project as there are many hundreds of programs which are expected to be present on any sort of general-purpose system.

I recently became aware of a project called 'defora' -the fellow has done a heroic job of re-writing lots of things -any one of which could be mighty useful -especially if given the needed attention. But how can you perfect a single program while re-writing a dozen others? And how usable is the product for others? The defora fellow wrote a nice, fast browser using libgtkhtml -but most internet sites would make it crash because of the javascript. It does make a nice browser for local use, but it would need at least a couple of people devoted to improving it.

I'm just trying to stimulate some thought, so I hope nobody feels offended...

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#26 Post by Iguleder »

lazy-utils is not intended to provide the perfect user interface or full compatibility, so extra features are nothing but a waste. of space. You get bloat when you seek more and more features.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#27 Post by Ibidem »

Iguleder wrote:I'm unaware of any BSD-licensed busybox-like tool with good code (i. e toybuf in toybox is ugly as hell) and true minimalism. lazy-utils does not adhere to any standard, so it misses some features beyond its scope and it's fine.
So what is the scope? It clearly isn't going to be self-hosting, since the kernel alone needs over half a dozen flags for grep...

I'm not in agreement with you about the use of a global array of chars as a scratch buffer or how often goto should be used (note: goto is acceptable, used judiciously-the question is when); but beauty is in the eye of the beholder.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#28 Post by Iguleder »

The scope is a cross-compiled and small distro, not a self-hosting one.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#29 Post by Ibidem »

goingnuts wrote:Link to present tiny-Xserver-0.03 source
You will probably want this patch (I'm posting it in git format):

Code: Select all

commit 9cb2af3b3e39a1e25a626427a273a6801c0a163d
Author: Isaac Dunham <ibid.ag@gmail.com>
Date:   Wed Oct 16 23:30:40 2013 -0700

    Backport CVE-2013-4396 fix.

diff --git a/dix/dixfonts.c b/dix/dixfonts.c
index 8ec4e0f..4367801 100644
--- a/dix/dixfonts.c
+++ b/dix/dixfonts.c
@@ -1301,6 +1301,7 @@ doPolyText(client, c)
                    int len;
                    GC *pGC;
                    PTclosurePtr new_closure;
+                   PTclosurePtr old_closure;
 
     /*  We're putting the client to sleep.  We need to do a few things
        to ensure successful and atomic-appearing execution of the
@@ -1325,6 +1326,7 @@ doPolyText(client, c)
                        err = BadAlloc;
                        goto bail;
                    }
+                   old_closure = c;
                    *new_closure = *c;
                    c = new_closure;
 
@@ -1333,6 +1335,7 @@ doPolyText(client, c)
                    if (!c->data)
                    {
                        xfree(c);
+                       c = old_closure;
                        err = BadAlloc;
                        goto bail;
                    }
@@ -1347,6 +1350,7 @@ doPolyText(client, c)
                    {
                        xfree(c->data);
                        xfree(c);
+                       c = old_closure;
                        err = BadAlloc;
                        goto bail;
                    }
@@ -1363,6 +1367,7 @@ doPolyText(client, c)
                        FreeScratchGC(pGC);
                        xfree(c->data);
                        xfree(c);
+                       c = old_closure;
                        err = BadAlloc;
                        goto bail;
                    }

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

#30 Post by goingnuts »

@Ibidem: Thanks - I will add them.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#31 Post by Iguleder »

The only thing that builds fine with today's kernel, musl and GCC is tinyxlib, but any variant of X I've tried (XFree86, early X.Org kdrive versions) doesn't.

I've wrote some proof-of-concept display server that draws rectangles on the screen through a framebuffer device - if I get it to work well, I'll try to port a stripped-down GTK 1 to it.

By the way, I added a faster, hash-based cache to the kernel module tools, so they're a lot faster now.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#32 Post by Ibidem »

Iguleder wrote:The only thing that builds fine with today's kernel, musl and GCC is tinyxlib, but any variant of X I've tried (XFree86, early X.Org kdrive versions) doesn't.
I just compiled Xfbdev from tinyXserver source, and it's working nicely.

Note, though, that you will need to edit standard_definitions.mk if you are cross-compiling: the standard setup for tinyxlib installs to /usr, and tinyxserver expects the libc and tinyxlib headers to be in /usr/include.

To build Xvesa may require a little editing; I don't think musl includes <sys/io.h> or <sys/vm86.h>, but only the macros are needed.
goingnut's makefile doesn't handle building just Xfbdev that well; try running "make -i" or commenting out every line that mentions vesa.
I've wrote some proof-of-concept display server that draws rectangles on the screen through a framebuffer device - if I get it to work well, I'll try to port a stripped-down GTK 1 to it.
Hmmm...somehow I'm reminded of NanoX/Microwindows...

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#33 Post by Iguleder »

What distro are you building on?
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#34 Post by Ibidem »

Iguleder wrote:What distro are you building on?
Self-hosted built-from-scratch musl+busybox+gcc. Linux 3.0 kernel, but that's probably not relevant.
(Yes, self-hosted can really make things simpler.)

But you'll need the kernel headers installed in your target's includedir.

Tell me a couple things and I should be able to get a build-system patch:
-prefix for musl on the host
-I assume all the libs and headers get installed in the same directory on the host?
(for example, use /opt/musl as prefix for everything and install as you go)

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

#35 Post by technosaurus »

Iguleder wrote:I've wrote some proof-of-concept display server that draws rectangles on the screen through a framebuffer device - if I get it to work well, I'll try to port a stripped-down GTK 1 to it.

By the way, I added a faster, hash-based cache to the kernel module tools, so they're a lot faster now.
I highly recommend netsurf's nsfb as a starting point because it is small and has xcb (not X11) wayland and linux framebuffer backends (and some others - SDL, ram, and some other framebuffer)

For the kernel modules, finit_module syscall (added in 3.8 ) is quite convenient and was extremely fast with my flat modules experiment (all modules in 1 directory /lib/modules/X.X.X) It worked well with the normal module tree as well, but not as fast as the flat style.
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].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#36 Post by Ibidem »

I see you are using ${SYSROOT} as the target root directory, and headers go in the usual place.

This should get the cross-compiling part working:

Code: Select all

cd tinyxlib
sed -e 's_/usr_${SYSROOT}/usr_g' standard_definitions.mk >newdefs.mk
cp newdefs.mk standard_definitions.mk

cd ../tiny-Xserver-0.03
sed -e 's_\(^CC\)=_#\1_g' -e 's_\(/usr\)_${SYSROOT}\1_g' standard_definitions.mk >newdefs.mk
cp newdefs.mk standard_definitions.mk
That doesn't take care of it building the vesa stuff; but you should find removing that from the makefile pretty easy.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#37 Post by Iguleder »

cd render; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/render'
ar cr librender.a glyph.o miglyph.o miindex.o mipict.o mirect.o picture.o render.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/render'
cd dix; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/dix'
make[1]: `libdix.a' is up to date.
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/dix'
cd os; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/os'
ar cr libos.a WaitFor.o access.o connection.o io.o osinit.o utils.o auth.o mitauth.o secauth.o xdmcp.o decompress.o transport.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/os'
cd mi; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/mi'
ar cr libmi.a cbrt.o miarc.o mibank.o mibitblt.o mibstore.o miclipn.o micmap.o micursor.o midash.o midispcur.o mieq.o miexpose.o mifillarc.o mifillrct.o mifpolycon.o migc.o miglblt.o miinitext.o mioverlay.o mipointer.o mipoly.o mipolycon.o mipolygen.o mipolypnt.o mipolyrect.o mipolyseg.o mipolytext.o mipolyutil.o mipushpxl.o miregion.o miscrinit.o mispans.o misprite.o mivaltree.o miwideline.o miwindow.o mizerarc.o mizerclip.o mizerline.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/mi'
cd Xext; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/Xext'
ar cr libext.a bigreq.o mbuf.o saver.o xf86dga2.o xtest.o cup.o mbufpx.o xf86dga.o xvdisp.o mitmisc.o shm.o xf86misc.o xvmain.o dpmsstubs.o sleepuntil.o xf86vmode.o xvmc.o EVI.o sync.o xprint.o xvmod.o fontcache.o xcmisc.o xtest1dd.o mbufbf.o sampleEVI.o xf86bigfont.o xtest1di.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/Xext'
cd Xext/extmod; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/Xext/extmod'
make[1]: `libextmod.a' is up to date.
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/Xext/extmod'
cd XTrap; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/XTrap'
ar cr libxtrap.a xf86XTrapModule.o xtrapddmi.o xtrapdi.o xtrapdiswp.o xtrapditbl.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/XTrap'
cd hw/kdrive; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/hw/kdrive'
ar cr libkdrive.a kaa.o kasync.o kcmap.o kcolor.o kcurscol.o kdrive.o kinfo.o kinput.o kmap.o kmode.o knoop.o kpict.o kshadow.o ktest.o kxv.o vga.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/hw/kdrive'
cd hw/kdrive/linux; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/hw/kdrive/linux'
ar cr liblinux.a agp.o bus.o keyboard.o linux.o mouse.o ms.o ps2.o
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/hw/kdrive/linux'
cd fb; make
make[1]: Entering directory `/root/Downloads/tinyxserver-master/fb'
/root/Downloads/sysroot/bin/musl-gcc -I../include -I../mi -I../fb -I../hw/kdrive -I../render -I../Xext -pipe -Os -Wall -D_BSD_SOURCE -D_GNU_SOURCE -D__KERNEL_STRICT_NAMES -fno-strength-reduce -nodefaultlibs -fno-strict-aliasing -ffunction-sections -fdata-sections -I/opt/musl/include -I. -DNOERROR -D__i386__ -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DTOSHIBA_SMM -D_SVID_SOURCE -D_GNU_SOURCE -DX_LOCALE -DKDRIVESERVER -DGCCUSESGAS -DDDXOSINIT -DNOFONTSERVERACCESS -DNDEBUG -DNARROWPROTO -DPIXPRIV -DFUNCPROTO=15 -DCOMPILEDDEFAULTFONTPATH=\"/usr/share/fonts/X11/misc/\" -DRGB_DB=\"/usr/share/X11/rgb\" -D_POSIX_C_SOURCE=2 -DMITSHM -DRENDER -DXCMISC -DXV -DUSE_RGB_TXT -D__KERNEL_STRICT_NAMES -c -o fbblt.o fbblt.c
fbblt.c: In function ‘fbBlt’:
fbblt.c:136:7: error: duplicate case value
fbblt.c:136:7: error: previously used here
fbblt.c:136:7: error: duplicate case value
fbblt.c:136:7: error: previously used here
fbblt.c:144:7: error: duplicate case value
fbblt.c:144:7: error: previously used here
fbblt.c:144:7: error: duplicate case value
fbblt.c:144:7: error: previously used here
fbblt.c:260:7: error: duplicate case value
fbblt.c:260:7: error: previously used here
fbblt.c:260:7: error: duplicate case value
fbblt.c:260:7: error: previously used here
fbblt.c:272:7: error: duplicate case value
fbblt.c:272:7: error: previously used here
fbblt.c:272:7: error: duplicate case value
fbblt.c:272:7: error: previously used here
make[1]: *** [fbblt.o] Error 1
make[1]: Leaving directory `/root/Downloads/tinyxserver-master/fb'
make: *** [all] Error 2
tinyxlib builds just fine, but tinyxserver doesn't. Here's what I get, under Debian Wheezy, x86_64.

I've been trying to figure out why this happens for hours - I tried to evaluate all those macros and found no duplicate values so far.

EDIT: this doesn't happen when I pass "-m32" to GCC. It's some 64-bit incompatibility.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

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

#38 Post by technosaurus »

In the future, you can comment out all of the #includes that are of no concern and then preprocess the file with gcc -E ... to evaluate the macros. It would be nice to fix it for 64bit (and xfbdev for arm, mips,..) I am interested in porting xfbdev to the BSD framebuffer and using mfsBSD to bootstrap a totally unencumbered stray pup.

Does anyone happen to know any substantial app that works on both the Linux and BSD framebuffers?
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].

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#39 Post by Iguleder »

Tried that, but it doesn't evaluate more than one level.

I tried some old FreeBSD patches but the problem persists.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

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

#40 Post by technosaurus »

does:

Code: Select all

gcc -m32 -E ... > m32res;gcc -m64 -E ... > m64res; diff -u m32res m64res
provide anything helpful?
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].

Post Reply