Puppy In-House Development

[greengeek]

40 km from me, I hear and feel every rocket fired and every air strike.

This is another example of mankind using the wrong kind of shell... It's a shame we cannot live in peace. Someone should give us the bash...

Hope it all ends soon, and that you stay safe.

[jamesbond]

40 km from me, I hear and feel every rocket fired and every air strike.

Take care Iguleder. Hope all this unnecessary thing ends soon

Generally, I believe in "live and let live". I don't like the fact GPL is viral, so I license my own code under BSD (if it's useful for commercial projects - I get some reputation) or make it public domain (if it isn't).

The choice of the license is up to its author, and I respect your choice.

And I certainly is happy that someone can make a billion dollar out of a GPL product - that is proof enough that FOSS isn't a deterrent to commercial success.

What I'm not happy with, is, the misleading statement (see below), from the very same guy, who *knows exactly* what the GPL license is (having built a business model around that, and profited from that). If it were some unknown nobody who makes that statement, I couldn't care less ...

<rant>Technically they are right...

Well which part of this is "right"?
- You may not distribute the resulting binary (because you have linked MariaDB with GPLv3 libraries!)
- If you do distribute, you will put yourself into a legal problem with Free Software Foundation (because you have linked MariaDB with GPLv3 libraries!)
I can't find anything in GPLv3 license says that "I cannot distribute binaries" or "I will get legal problems with FSF" because I link to a GPLv3 libraries.
What I do find there is, if I want to distribute these binaries that linked to GPLv3 libraries, I *do* need to meet certain obligations and if I don't, I may get issues with these "libraries" authors (certainly not FSF unless FSF happens to be the author or the copyright owner).

[Ibidem]

Completely off topic: I presume all the trouble we've been hearing about in the news is a fair distance from you?

huh?, didn't see anything on slashdot, whats up?

Hamas.

... I am really starting to like tekui and lua. Lua isn't bad once you get used to it, but I still may port tekui to javascript with duktape since the interface already uses css and it can handle xml and json - if ported from lua to javascript, you've got a nice little web browser in 100+ lines of code.

Re: shells
I think it would be nice to have something basic for common languages
python -> tinypy
tcl -> jim-tcl
js -> duktape/quadwheel/libsee/spidermonkey-1.8.0b1
lua -> stua (part of stb), luajit or even plain lua, its pretty small already
java -> avian
perl -> microperl
c -> tcc

tcl: any version that can build wish is good...

avian looks interesting.
I'd say lua is good in its own right.
spidermonkey is probably not a good idea; there have been several security fixes since then.
I vaaguely remember that libsee seemed to be buggy in my experiments with alternate browsers (hv3 and elinks), with some sites making it hang.
I'm wondering if quadwheel can build with byacc instead of bison.
duktape looks to be the most current (ecmascript e5.1 with some e6 draft features, as opposed to working on revision 3).

I can't find anything in GPLv3 license says that "I cannot distribute binaries" or "I will get legal problems with FSF" because I link to a GPLv3 libraries.

It's if you link GPLv2 or OpenSSL-licensed code to GPLv3 libraries; the GPL versions have enough differences that GPLv3 counts as "additional restrictions" compared to GPLv2, neither permits some of the requirements of the OpenSSL license, the FSF refuses to distribute readline or its other software with an OpenSSL exception, and the FSF considers linked software to be a derivative work. So the FSF position is that GPLv2-only code and GPLv3 libraries cannot be linked, and certainly not GPLv2 code, GPLv3 libraries, and OpenSSL.

[linuxcbon]

hi, do you have a booting iso that we can try and test for feedback and bugs ? thanks

[Ibidem]

hi, do you have a booting iso that we can try and test for feedback and bugs ? thanks

Who?
If you're asking Iguleder, I think it's at http://dslr.dimakrasner.com/ (x86_64 only?).
technosaurus has mentioned some projects, but I'm not sure what the current state of his current project(s) is.

[jamesbond]

So the FSF position is that GPLv2-only code and GPLv3 libraries cannot be linked, and certainly not GPLv2 code, GPLv3 libraries, and OpenSSL.

Thanks for the enlightenment.

[Iguleder]

DSLR is active. It's a testing bed for all projects I work on, including stuff like loksh. Yes, 64 only.

EDIT: by the way, yesterday I fixed Dillo's SSL certificate verification bug, so LibreSSL is fully integrated into DSLR. SSL support in all applications seems to work.

I also improved ROX-Filer's usability, by adding pre-configured handlers and icons. Generally, DSLR seems usable now. It desperately needs graphical wizards for trivial stuff like mounting, though.

[Ibidem]

DSLR is active. It's a testing bed for all projects I work on, including stuff like loksh. Yes, 64 only.

EDIT: by the way, yesterday I fixed Dillo's SSL certificate verification bug, so LibreSSL is fully integrated into DSLR. SSL support in all applications seems to work.

I also improved ROX-Filer's usability, by adding pre-configured handlers and icons. Generally, DSLR seems usable now. It desperately needs graphical wizards for trivial stuff like mounting, though.

I'm afraid I won't be playing with DSLR myself, since I pretty much have to run 32-bit (Atom N270, PIII).
Regarding graphical wizards and so on:
-what are you using for networking?
-any chance of xdialog getting in?
-what do you want as far as mounting goes? I'm guessing not full automount, where every readable FS gets mounted, but do you want it to
(a) popup on device plugin? (If so, starting something like nldev/a hacked-up nlmon/devd/... with a hotplug script that starts the dialog up would seem to be a sensible course. You'd probably need it to be started from X, but get root...perhaps be suid root with no command line just a fixed config file only writeable by root...)
Another choice is using inotify/fanotify on /dev, plus a stat() to check that you have a block device.
Or would it be better if it
(b) can be run manually?
-any other scripts you would like?

[Iguleder]

I want something similar to pmount, a list of block devices and their details. Each device has a button that mounts or opens it.

I want it to use GtkDialog1, for consistency.

Besides this one, I want some system information dialog and a more complete WiFi wizard. Once these are ready, automatic execution of the mounting wizard when a block device appears would be nice.

[linuxcbon]

When booting, it shows services started etc and stops at "searching for the home partition".
I try to boot frugal, with 3 files bzImage, initrd.xz, rootfs.sfs and grub4dos with menu.lst .

[Iguleder]

What do you mean by "frugal"? It doesn't have any boot codes like Puppy.

[linuxcbon]

I mean with files bzImage, initrd.xz, rootfs.sfs in a folder in windows xp for example. Then grub4dos (grldr) boots with menu.lst

Code: Select all

title DSLR FRUGAL
  root (hd0,0)
  kernel /DSLR/bzImage
  initrd /DSLR/initrd.xz

It works until "searching for the home partition".

[technosaurus]

I bet you have an ntfs partition ... and no ntfs3g yet??? does it work on a usb stick (unetbootin can set it up for you with any puppy iso, then just replace the files)?

... Excuse the mess while we are under construction.

[Iguleder]

It does not support sub-directories. Again, this is not Puppy.

[Ibidem]

On a subject not related to the main topic at the moment:
my tinyxlib tree just lost about 3000 lines; this was the work of a handy little tool called unifdef.
I stripped out support for a whole lot of platforms, including Windows in at least 3 variants, 16-bit systems like Win16 and DOS, two OS/2 flavors, SCO UNIX 3.2.5, SVR4, System V, Sequent, AIX, SunOS, IRIX, Lynx, QNX, OS X, HP-UX, Ultrix, pre-ANSI C, and more. I have not yet purged VMS; that is an oversight.
In summary, -DMACRO will treat MACRO as always defined and remove the ifdef wrappers to make the source consistent with that, while -UMACRO will treat MACRO as undefined and remove all code that depends on it. You need to specify -M .bak or -m for processing multiple files; -M .bak makes a backup of original.c named original.c.bak, while -m leaves no backup (which works nicely with git.)

When using unifdef, be warned: the obvious approach is WRONG.

Code: Select all

find -name '*.c' -o -name '*.h' |xargs unifdef -m -UWIN32

is what you might think is the right way.
But it will actually break any symlinks you have.
So the correct approach is:

Code: Select all

find -name '*.c' -type f -o -name '*.h' -type f |xargs unifdef -m -UWIN32 -DSTDC -D__STDC__ -Uultrix -UVMS -UDNETCONN

Further, if you run it with -UWIN32 and then with -U__EMX__, you may be surprised to find that you still have code with

Code: Select all

#if defined(WIN32) || defined(__EMX__)

This is because the first time, it only removes code that can only be reached if WIN32 is defined; the second time, it only removes code that can only be reached if __EMX__ is defined.
So be sure to append macros rather than replacing them.

While looking at this, I noticed that X_LOCALE is currently turned on; but it does not do what you might expect.
X_LOCALE means "Use internal code to duplicate setlocale() and the rest of the POSIX locale api, assuming that locales are not really supported by the OS."
I would suggest turning it off; per my tests, it seems that ABI does not break, but a rebuild against it is probably best.

[Iguleder]

Just built Debian's elvis-tiny against musl.

I've been looking for a basic, standalone vi implementation. The Busybox one is GPL, the traditional vi is incompatible with musl (because of brk()), Elvis is relatively small but hard to cross-compile, nvi requires porting from *BSD, Vile is annoying and Vim is an overkill (even when built with the "tiny" set of features).

Debian's old version of Elvis is tiny, maintained and gets the job done. Under x86_64, it's a 140K binary. I kicked DSLR's huge Vile package (1MB) in favor of this one.

[technosaurus]

On a subject not related to the main topic at the moment:
my tinyxlib tree just lost about 3000 lines; this was the work of a handy little tool called unifdef.

You know how all of the function definitions are "old school" with the #ifdef needfunctionprototypes ...
https://gcc.gnu.org/onlinedocs/gcc-4.1. ... toize.html

On another unrelated note, after discovering musl doesn't _actually_ dlclose(), I went in search of an alternative ... this one may work even with static builds:
http://stackoverflow.com/a/12139145/1162141
It basically allows you to mmap an object file and run a function directly from it by using a funtion pointer to the corresponding address location.

This would be for things like image loaders, compression.... (large functions with few dependencies) In jwm for instance, the images are only loaded at startup IIRC, so the libs could be loaded, used and discarded. It may even be a way to handle static plugins.

Note: when writing functions to use in this manner, only pass/return native types or pass a pointer to the object as a function parameter that will store the "return" value.

For multiple functions it could use and enum-erated array of function pointers like this:
http://murga-linux.com/puppy/viewtopic. ... 794#779794

[Ibidem]

Technosaurus:
I've cut out another 3000 lines, mostly via unifdef; I've also made use of fchown and snprintf unconditional (which means it's easier to build a more secure library).
If you're curious, it's all from cutting platforms other than semi-current Linux/BSD/maybe Minix.

I find no #ifdef needfunctionprototypes, and I haven't figured out how to enable protoize in gcc 4.2.1 (never mind what the proper command line is.)

Iguleder: I had simply grabbed the nvi tarball and tried building it: I don't recall any problems.
Building from git (http://repo.or.cz/w/nvi.git) requires autotools, but seems to work.

[Ibidem]

Played around a little bit.
I have a small rootfs containing only permissively-licensed system tools; I call it "bareroot". Included packages are musl, toybox, bits of terminfo, elvis-tiny (which, I note, is rather buggy) installed as vi, loksh as ksh/sh, lok as awk, netbsd sed, and wpa_supplicant (built with only wext and the internal crypto/tls) including tools; I also wrote a few scripts for this.
I ran sstrip on everything but elvis.
Note that the behavior of the shell may seem odd if you have VISUAL=vi set; it's running in vi line-editing mode.

To use this you will need your own kernel, bootloader, modules, and firmware. You can turn it into an initrd or unpack it on the root of a filesystem. Don't overwrite /, or things _will_ break.

bareroot.cxz is an XZ-compressed cpio archive; uncompress via

Code: Select all

xzcat <bareroot.cxz |cpio -idv

[Iguleder]

I just built the entire DSLR from scratch with GCC 4.8.x, while the compiler is replaced with a wrapper:

Code: Select all

#!/bin/sh

case "$@" in
        *-O[0-9]*)
                echo "`pwd` $@" >> /tmp/args.txt
                ;;
esac

exec /usr/bin/cc "$@"

I found out that several packages do not resepect CFLAGS or add -O2 thanks to auto* crap. I was able to shave a few KB here and there.