It's gonna be a while till the next release of webLinux. It's not that I'm not working on it; I am regularly. There's just alot to do before the next release is near usable. Pretty much everything either needs or is being rewritten to suit the new kernel and library API. It really does perform as a Linux system now though; for instance, here's the boot process of what will be release 0.7 running kernel 0.4:

1. User Clicks on 'Launch Web Linux' and page loads
   
2. New instance of system is created
   
3. system (the webLinux BIOS) checks processing times, connection speed to server, and loads a hardware cache (essentially the partition table, and partitions for the webLinux hard drive)
   
4. system clock is initialised
   
5. system loads grub, and creates a new instance of it on system.bootloader
   
6. grub reads the partition table and fetches menu.lst from (hd0,0)/boot/grub/menu.lst
   
7. grub menu appears on screen, grub uses the system clock to launch a countdown according to menu.lst
   
8. either the countdown runs down or the user selects an option from the menu, grub reads the seleced boot option and loads the kernel
   
9. grub passes the kernel the boot options and a new instance of kernel is initialised on window.linux
   
10. kernel init starts by testing for how to append a new object the screen and creating a root screen to output boot messages to
    
11. kernel and system memory is initialised
    
12. module gfx is loaded and screen resolution is detected and written to kernel memory
    
13. console fonts are set
    
14. keyboard is detected and written to kernel memory and kbd module is loaded
    
15. mouse is detected and written to kernel memory and mse module is loaded
    
16. platform (browser,browser version, javascript version) is detected and written to kernel memory
    
17. browser specific kernel module is loaded
    
18. root file system read from boot parameters, and partition is loaded to kernel memory device map (/dev/hda1)
    
19. filesystem type is detected (jsfs) and filesystem is mounted read only
    
20. jsfs kernel module is loaded
    
21. essential boot libraries are loaded (libc,libmd5,getty,libfs)
    
22. filesystem root node is detected and realigned for checking
    
23. kernel calls execute on /sbin/fsck passing filesystem device as argument
    
24. new process is appended, shared libraries are loaded, and fsck starts
    
25. fsck checks for valid node pointers and orphaned nodes
    
26. fsck exits and process is removed
    
27. kernel remounts filsystem read/write
    
28. unused kernel memory is freed (bootloader and other unused objects are deleted)
    
29. kernel memory is mapped to /proc and kernel messages are mapped to /var/log messages
    
30. kernel calls alsa detect to find suitable sound device (flash or java enabled in browser)
    
31. sound device is written to /proc/sdvc if available, and flash or java object is loaded
    
32. alsa kernel module is loaded to interface with java or flash device
    
33. /sbin/init is called and is passed boot parameters
    
34. new process is appended, shared libraries loaded and init starts
    
35. init reads /etc/inittab and loads runlevel config
    
36. init reads /etc/rc.[runlevel] and prepares to initialise runlevel
    
37. boot scripts are sorted into kill/start and execution order
    
38. init loads each script (filesystem module reads it across the symlink) and execute passing start or stop as parameter
    
39. /etc/init.d/mountall mounts all remaining partitions according to /etc/fstab (there isn't any at present, but the capability is there)
    
40. /etc/init.d/networking starts the network interface (loads kernel module that tracks connection stack - work in progress but getting there)
    
41. /etc/init.d/console reads consoles to be opened from /etc/inittab
    
42. /etc/init.d/console appends new virtual terminals and calls /bin/getty on each
    
43. new process is appended for each instance of getty
    
44. shared libraries are loaded for getty, each terminal calls /bin/login
    
45. init reports 'system is running' and kernel maps boot messages to /proc/dmesg
    
46. new process is appended for each instance of login and shared libraries are loaded
    
47. login draws a login prompt on each virtual terminal
    
48. kernel calls /bin/chvt to switch user to vt 1
    
49. end of boot process
    

It may not be exactly like a regular Linux system, but it does come close to the goal of webLinux of 'creating a working Linux system within a web page'. Additionally, passwords are now stored as an md5 hash, thanks to some handy javascript md5 functions which have been built into a library (libmd5 as mentioned in the boot process). Which brings us to the shell, the current work focus of attention; it currently can read in commands, split them into multiple calls (seperated by && or |), has support for process backgrounding, knows whether a processes output should be output to the console, the next command, or a file, and splits a command into a call and parameters... it's just a case of getting it to process the commands now.
And hence we're back to where this post started, this may take a while.
And then I've gotta rewrite ls,cat,cd,mkdir... and argue with the X server implementation some more.
Fun, fun, fun, did I hear whisper of having to write a javascript implementation of GTK too?

This may take a while.