Puppy In-House Development

[goingnuts]

Link to present tiny-Xserver-0.03 source

[smokey01]

If small is the goal, have you seen this:
http://www.menuetos.net/

A full X operating system with lots of apps that will fit on a floppy. It's pretty cool and seems to be actively developed, 32 & 64-bit.

Download:
http://www.menuetos.org/M32.htm
http://www.menuetos.be/download.php?CurrentMenuetOS

CatDude made a bootable ISO at a huge 1492k.

[01micko]

Smokey.. did you know BK was a part of that project?

http://www.goosee.com/explorer/index.html

[Ibidem]

jamesbond - trying to build a small X

You're right. I thought Xfbdev is small because it is one of (remaining few) the kdrive servers, but when counting the depedency it is not that small either. It is *still smaller* than the full Xorg, though.

On another note, amigo, technosaurus, goingnuts and ibidem have combining forces to create a working tiny X server - they have it going for x86 but I didn't follow enough to know whether they have have the generic framebuffer version which works cross-platform.

I didn't do a large amount of work--mainly got it working with musl and backported some security fixes (speaking of which, there's another one to patch...).
But yes, Xfbdev does build and run.

When compiled against tinyxlib, I will say that colors don't work quite right--hex #RGB colors are not recognized, though I know goingnuts was doing something about that.

[smokey01]

Sure did. I stumbled across it many years ago but didn't realise it was still being developed.

Smokey.. did you know BK was a part of that project?

http://www.goosee.com/explorer/index.html

[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]

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]

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.

[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.

[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...

[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.

[Ibidem]

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.

[Iguleder]

The scope is a cross-compiled and small distro, not a self-hosting one.

[Ibidem]

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]

@Ibidem: Thanks - I will add them.

[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.

[Ibidem]

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...

[Iguleder]

What distro are you building on?

[Ibidem]

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)

[technosaurus]

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.