I discovered Shahor yesterday. Iguleder is the guy that, in the past, posted a guide about compiling a Puppy kernel. Using his guide I was successful with that. After this I used his script in building kernels.
Shahor is great. It's very fast and runs perfectly on my ultrabook Acer S-391. It recognized my WiFi card and everything works like expected.
I didn't manage to mount any internal or external drive (USB or harddrive).
I will try to compile some applications because I understood that all the developers tools are in their place.
I hope Iguleder didn't abandon this great project.
I didn't try roar-ng ii but i think it has the potential to compete with woof.
For Shahor it needs more customization in order to allow the user to tweak settings, to remaster the distribution. For temporary remastering I have some ideas regard extract main .sfs, include the files and create .sfs again but a proper tool will be welcomed.
Thanks for all your effort and please keep going because this project has a great, great potential.

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64.
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel.

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one ) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing.

Things to consider:
Linux-3.10 is LTS, ... may be a good basis going forward. I especially like the finit_module syscall that appeard in 3.8 (make loading kernel modules much easier in C)
Rob Landley's tmpfs for initrd patch to avoid the double copy on load and allow remounts
https://lkml.org/lkml/2013/6/29/101
Fork my init.c above instead of a shell version (hint print out the contents of argv and envp and compare to parsing /proc/cmdline) It starts here, but I've been working on an ultraminimal C library for it here
goingnuts posted a build of static multicall binary of xfbdev+jwm+rxvt in the pupngo thread iirc, but you will still need some kind of shell for jwm's StartupCommand to work (for mine I made a small sh-c wrapper that does argv+=2 (to get rid of "sh" and "-c" ) and fork()s and execvp(argv[0],argv))

My fastest way to get to a full desktop was to modify the kernel's vga=ask code into vga=max (vga=ask is a PITA) ... instead of keeping a set of functional modes, it just multiplied WxHxbpp and used the MAX ... then use xfbdev in the initramfs.
My code was pretty hacky, so never submitted it to LKML, but booted to desktop full res was under 2s in Qemu, but akash_rawal cleaned it up a bit here:
http://www.murga-linux.com/puppy/viewtopic.php?t=78993

btw, I like what you did with rox-lite and think it could be a good starting point for a project I have been mulling over for quite some time - a full gtk desktop environment in a single process for all GUI applications, tray applets, daemons ... The concept is pretty simple, use inotify (actually its glib wrapper funcs) to monitor directories and have its events trigger: load/unload gtkbuilder files for apps, desktop widgets and tray applets, or plugins and shell scripts for control, $HOME/Desktop (.desktop files, symlinks, directories for desktop similar to other DEs). Basically a replacement for a DE, pwidgets, gtkdialog, my own SIT (multiple icon tray app) and some additional functionality (webkitgtk could be a in a plugin and work something like this) ... glade would be easier than hand crafting gtkdialog xml. I was planning to do the whole thing from scratch so it could be MIT licensed, but I got stuck at the desktop on what would seem a simple task... trying to get a background image onto a gtkiconview._________________Web Programming - Pet Packaging 100 & 101

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64.
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel.

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one ) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing.

EDIT: here's a teaser. As I said, you get a working root shell

This concepts sound great and in my opinion should be include:
- the secure tiny core updated by the distro developer with the latest security patches. The builder for this core must include possibility to customize and change the kernel
- the devx.sfs maintained also by the distro developer and used to compile applications from sources
- an application sfs which can be created, updated and remastered by the user. User must have the choice to create this "apps sfs" from scratch in order to include just the desired application and nothing else more
- a sfs which includes just apps configurations and settings. Having this separated you can have a frugal distro with customized configurations (including specific firewall configurations) that are kept even after updating the apps sfs which not touch this configurations sfs
- the devx.sfs should offer the possibility to compile server applications like asterisk, openvpn, postfix, etc. from source
- the distro should offer possibility to mount external USB drives, connect to wired and wireless networks
The separated sfs offer the possibility to have a very secure and convenient distro. Even having a separate sfs for each application can be convenient sometime. In this way you can update just the desired sfs when an update is needed without affecting other applications.
The distro should have the possibility in setting which sfs's are loaded on the next bootup
Now I will try to have installed your new concept of distro.
Thank you for your work in Linux community, you have great ideeas and you are doing a great job.

I'm currently working on another distro, which should make roar-ng II even cooler.

My new idea is to build a distro from two parts:
- A kernel and a static collection of core binaries (e.g udev). This part should be totally independent from other distros - very hard to maintain, so it's tiny and doesn't change much. Very secure, extremely tiny, very fast. I already have a prototype - boots in about 2 seconds and achieves a shell running as root, with a SSH server on and impressive RAM usage of 11 MB on x86_64.
- A "main SFS" from packages of another distro, as we do in Puppy. We already have enough experience with this part. It should contain that distro's C library, shell, applications, graphics stack, etc'. However, these will run inside a so-called "sandbox".

The great feature this design allows is swapping of the main SFS, with packages of another distro, so you have one "core Puppy", with Slackware/Ubuntu/Debian/etc' packages in the form of interchangeable add-ons. Each time, that sandbox contains packages of another distro.

Also, I think it could be cool to have multiple "main SFSs", each from another distro, so you gain access to all packages of these distros and even can run them in parallel.

Currently, roar-ng II does not allow this design. I'm doing some research (well, weekend is over - I'll continue on the next one ) regarding UEFI support, so I can write a tiny script that generates a UEFI-bootable x86_64 ISO with nothing but the core distro inside, which is x86_64 only at the moment.

Later, I want to take roar-ng II's boot process and merge it with this thing.

EDIT: here's a teaser. As I said, you get a working root shell

This concepts sound great and in my opinion should be include:
- the secure tiny core updated by the distro developer with the latest security patches. The builder for this core must include possibility to customize and change the kernel
- the devx.sfs maintained also by the distro developer and used to compile applications from sources
- an application sfs which can be created, updated and remastered by the user. User must have the choice to create this "apps sfs" from scratch in order to include just the desired application and nothing else more
- a sfs which includes just apps configurations and settings. Having this separated you can have a frugal distro with customized configurations (including specific firewall configurations) that are kept even after updating the apps sfs which not touch this configurations sfs
- the devx.sfs should offer the possibility to compile server applications like asterisk, openvpn, postfix, etc. from source
- the distro should offer possibility to mount external USB drives, connect to wired and wireless networks
The separated sfs offer the possibility to have a very secure and convenient distro. Even having a separate sfs for each application can be convenient sometime. In this way you can update just the desired sfs when an update is needed without affecting other applications.
The distro should have the possibility in setting which sfs's are loaded on the next bootup.
The distro should be multiuser. This is a must when it is used as a dedicated server operating system and server applications must not be runned as root.
Now I will try to examine on github your new concept of distro.
Thank you for your work in Linux community, you have great ideeas and you are doing a great job.

Here is the collection of minimalistic system tools that forms the base. Besides the applets contained in it, the distro contains musl, dash and tcsh - that's it

Currently, it boots but I need to implement:
- A tiny udev replacement (i.e a simple tool that receives uevents and runs modprobe) - I removed kmod and udev, since I want to replace them with my own, tiny implementations (insmod, rmmod and modprobe are ready and work great)
- ifconfig
- route
- A DHCP client, maybe

EDIT: my udev replacement is sort of ready - it was able to automatically detect my USB mouse and load the right driver. Now, I'm writing a kernel build script - once the kernel is done building I'm going to build a new image of the distro, which has only the kernel, musl, lazy-utils and a shell; no eudev, kmod, toybox or BusyBox

Yes, for several reasons:
- The BusyBox code is extremely ugly. It contains lots of legacy code meant for use with Linux 2.4 and C library hacks.
- BusyBox doesn't build against musl.
- The only alternative to BusyBox, toybox, lacks many features. It looks much better, but it's relatively young and unstable.
- I need a udev applet. The BusyBox mdev applet is redundant, since today we have devtmpfs.
- I want to provide my own init, syslogd, klogd and so on. I don't like the BusyBox daemons.

Not to mention the multicall binaries have all the overhead of functions not in use. If you do small standalone utilities it reduces the running footprint, instead of each fork to run utils from within also adding a lot of additional overhead (though copy-on-write reduces it some)... if you want to reduce the startup time of small utils, you can use readahead to reduce the loadtime (if you are running xfbdev/xvesa a good time to use readahead is during its startup) I wrote my tiny libc just for these kinds of small utils to minimize the size enough to fit entirely in cache (if you don't use sstrip, the elf headers are usually bigger than the program, otherwise a program can be ~500b with the right compile options)

RE: udev applet, I started rewriting the old unoptimized hotplug scripts and echoing the handler to /proc/sys/kernel/hotplug -- it becomes pretty simple with devtmpfs and allows you to add random hooks to things like a desktop drive tray (a jwm menu is a quick, robust way ... I wrote a test way back in scottman's akita thread IIRC) Originally it was just a wrapper that refreshed the drives as needed then called the "real" handler, but it turned out to not be that complicated to handle most of the events that actually needed it - no libudev integration though -- I wish the whole udev + dbus thing were replaced with 9fs like in Plan9 ... but that would involve kernel patches to sys, proc,...

RE: daemons - it would be nice to have a lot of the common daemons combined into 1 configurable process. I started that project once but got stuck @ cupsd (what a cluster bomb of code/docs)_________________Web Programming - Pet Packaging 100 & 101

RE: daemons - it would be nice to have a lot of the common daemons combined into 1 configurable process.

I'm against this, because I don't like multi-call binaries and because I don't like systemd. I'm trying to provide a modular alternative, which doesn't force the user to use all the included daemons._________________My homepageMy GitHub profile