[rdt] 2006.07.03 The purpose of this page is to discuss the advisability, feasability, justificaton, and design of an [OS] that uses/utilizes Tcl/Tk as the '''only''' scripting paradigm. Yes, what I mean is '''only'''. That is not even have a /bin/sh on the system. This does ''not'' preclude the use of binary applications just that all scripting would be done utilizing pure Tck/Tk. Why would one want to do this? 1. Because it can be done, 1. To advocate Tcl/Tk, 1. To simplify the administration learning curve, 1. To explore the performance aspects, 1. For the ''coolness'' factor, 1. What else? 1. Custom industrial interfaces/kiosks If this is a feasible, justifiable project, one could envision Tcl/Tk OS on: Linux, FreeBSD, OpenBSD, and/or NetBSD. I suppose one would begin by booting (on Linux 2.6) an initramfs containing a statically linked tclkit and some tcl scripts. One could have a /lib/system.so that permitted Tcl to access the kernel by such calls as: sys and permit all standard /bin & /sbin commands to become tcl scripts. You probably would want a compatibility layer to make those calls so that all the /sbin & /bin scripts would be cross platform on the above mentioned Free/Open Source systems. Maybe the library (for Linux) should be called tcl2linux.so in order to permit such things as tcl2freebsd.so and such. If this progressed, one could envision the modular Xorg utilizing the [Whim window manager] (or a derivative thereof) as the desktop. ---- [slebetman]: Etlinux ( http://www.etlinux.org ) is a big step in this direction. It doesn't even have a binary '''init'''. They've re-written '''init''' in tcl to reduce memory space. In fact, I believe on a bare install of etlinux, the kernel and tclsh might be the only binary executables on the machine. The end result of using pure Tcl is that they currently boast the smallest memory footprint of any linux distribution out there - 2MB RAM + 2MB HD space. [rdt]: Interesting project, but what I don't understand is that the home page (as given above) says near the bottom: "Sat Jan 15 2000: Etlinux 1.2.1 is out!" and near the top it says: "Tue Mar 16 2005 : Etlinux 1.1.3 is out!" :) [slebetman]: They maintain 2 stable branches of Etlinux, both current (both kernel 2.0.38). The difference is in the glibc library used. Etlinux 1.1 is compiled on libc5 allowing it to run on 2MB of RAM. Etlinux 1.2 is compiled on libc6 which requires a minimum of 4MB RAM. Etlinux 1.2 is the main branch with new developments back-ported to 1.1. I guess they still maintain 1.1 because there are still people out there (like me) with 2MB CPU boards. Plus, without it they can't boast to have a 2MB minimum requirement ;-) [rdt]: I see. Thanks for the explanation. Are you part of the development or just a user? [slebetman]: Just a user. Actually not even a user :-P I have a couple of Advantech & ICOP PC104 386 CPU boards with 4MB RAM each and an 8MB DiskOnModule. Several years ago (around 2002) I was looking at the possibility of installing Linux on them when I stumbled accross the etlinux site. It looked perfect except that it requires a linux host as a development machine and I didn't have one. I did however recommended the distro to an ICOP sales rep who had clients looking to squeeze Linux on ICOP boards and he had some success with etlinux. ---- List pure tcl/tk applications/scripts that can be utilized here: Core Processes / Daemons: * init - as demonstrated by http://www.etlinux.org * [tclhttpd] Console: * [Console Text Editor in Pure Tcl 2] (requires stty as currently written) X Windowing: * [Whim window manager] Sound: * [snack] ---- Is anyone (other than myself: [rdt]) interested in this or does everyone else think it is a stupid idea? [SRIV] I'm interested. For past projects, I've created 1.72mb boot floppies containing a 2.4 kernel (2.6 no longer contains an integrated bootloader) and a static tclsh and my app scripts. That's it! That's about as minimalistic as you can get. My personal workstation is mostly Tcl & Tk apps. I can get by with a handfull of essential binaries. [dzach] I'd be interested if sound (and [snack] for that matter) could work without problems. ---- [LES] and his bucket of cold water on 2006-07-05: I don't think it's a good idea because none of the motives presented are good enough and there are plenty of things that need to be made or improved and are a lot more important than an "OS". Some of them are even required '''before''' such "OS" is viable: * If there is no bash/sh, what would take its place? I use [Tkcon] a lot, but it only works when [X]/xorg is running, and even then it can't quite capture all forms of output like a bourne shell/curses/readline/whatever. To run ftp, ssh or wget, for example, only the traditional shells work well enough. We don't have a pure console Tcl shell that can actually replace sh/ksh/bash. * A Tcl/Tk window manager might be better (and a lot easier) than this OS idea. [Whim] is in the works, but it's still too raw and feature-less to be used and enjoyed as much as a window manager should. So whoever has the time and energy to dedicate to any one of these ideas perhaps should help [Whim] instead. * Tk is very practical, useful, powerful etc., but it's still very ugly in *nix environments. [Tile] helps, but clearly there is still a lot to be done for Tk. Again, I think that all efforts would be better spent on improving Tk. * In fewer words, Tcl/Tk is not quite ready for that kind of enterprise. [rdt] 2006.07.05 - Thanks LES for your opinion. From what I've seen of [Whim], it looks just about right for what I want to use as a window manager. And as for looks of the Tile ''thingies'', I think I prefer the Raw Tcl/Tk look, myself - must be something wrong with me, huh? [SRIV] 2006.07.05 - I dont use tile at the moment either, I like the raw speed. Whim has all the features I want, as I use it all day every day. Whim was designed for embedded insdustrial use, where the system designer would customize the wm on the fly without compiling. I combine it with a statically compiled Xvesa binary to make a minimal Linux gui OS for custom applications. It may not be a "full feature" desktop experience, but it fits the design goals. With a little effort, a more useful Tcl/Tk OS could be developed. All someone needs to do it set the goal and do it. I'm completely satisfied with my results. [George Peter Staplin] 2006.07.05 - I think Tcl/Tk is ready for many things, but pleasing graphics junkies (like myself) isn't one of them yet (until my Tk9 lives). '''What features do you want in Whim?''' When is the patch going to reach my inbox? '''Why do we have to recreate a shell environment and all that baggage to be taken seriously?''' Answer: we don't. I've created a graphical shell written in Tcl/Tk that uses megaimage and I think it's a better idea than creating yet another vt100-based shell. [rdt] 2006.07.06 : And where is this "graphical shell" [George Peter Staplin]? [George Peter Staplin] 2006.07.11 : It's with my TFP package. I'll announce something soon, or at least put something on the wiki. It's kind of a pain to build at the moment, because it relies on binaries from megapkg. [rdt] What goals would you need to see / like for it to be "usable" for you, [SRIV]? [SRIV] Just glancing at my Whim menu, I just need a few more Tk apps, like a web browser based on Tkhtml 3, a photo editor, a CAD app (possibly an enhanced tdcad), a decent PIM ([ajb] has started a nice one, should be done soon). With that, I'd have a at least a pretty descent internet appliance. I have a tk based file manager, calcualtor, chat, editor, etc. But even though I like the concept of a Tcl/Tk OS, I also appreciate the fact that all my apps run well on Windows too. I'm ok having some Linux binaries to fill in the gaps. Hence my current workstation is Slackware Linux, installed without KDE or Gnome, using a tclkit, whim.kit and a bunch of other kits to round out my apps. I love it. [rdt] Sounds good to me, [SRIV]. [SEH] 20060706 -- CAD: tried Ayam? [http://ayam.sourceforge.net/]. What mail client do you use? [SRIV] Currently webmail. [http://server.linuxsys.net/files/tdcad.kit] is a modified version of tdcad to work with tcl/tk >= 8.4. It still needs improving. The dxf importer needs work to properly import arcs. The core app should be recoded to work internally in dxf format. ---- [TP] I once played with a single-floppy Linux system (muLinux) and released [Tcl-To-Go] for it. It actually required three floppies: 1) the muLinux kernel + minimal utilities, 2) a tiny X11 server, 3) the Tcl-To-go disk which had a Tcl 8.0 tclsh and wish interpreters plus 35 Tcl/Tk applications. See the [Tcl-To-Go] page, and follow the link to the README. ---- (You may also be trying to find out [On What Platforms Does Tcl Run]) [MDD]: One system to consider is [Puppy Linux]. It's pretty close to what you're looking for. At least it would not be a bad starting point. The main page for it is http://www.puppyos.com/ ---- ''Sarnold 07/07/2006'' I think that [FileRunner] is a great candidate for a File Manager in such an OS. ---- User's Shell: [rdt] 2006.07.08 - Does tclsh need changes in order to be used as the user's shell? Could one just enhance the '''unknown''' proc such that any non-tcl command would be looked for as an external command in $env(PATH) ? Seems like I've read something about that on this wiki, but can't seem to find it now. Ahh, see [Is tclsh or wish suitable as a login shell] [rdt] I see that use of tclsh interactively, automatically supplies the command to exec if it is not a tcl command. Nice. [rdt] It seems to me as if [Is tclsh or wish suitable as a login shell] is discussing the use of tclsh to get a syntax similar to that of ''sh'' (pipes, globbing, & such) and perhaps the thing is to use a different syntax (csh & tcsh did, afterall) since we are talking about tcl here. ---- Begin proof of concept: [rdt] 2006.07.08 I have created a small 3.9 MB iso file containing little more than a Linux kernel and a dynamically linked tclsh and the libraries needed to run it. This is '''not''' to be construed as distribution of the file. It is located in a non-readable directory so just grab the file directly: [ftp://ftp.rdt1.org/.xyzzy/Tcl_OS.iso] Give it a few seconds to boot. What can you do with it? Not much, but try: parray env This indicates that the parray.tcl is autoloaded. So that much works. :) Comments are welcome. [dzach]: I've tried it on an Intel Pendium IV-2.6 GHz and it boots in 10 seconds. This is good. But, although I see tclsh in ./bin, and I am able to create and save a minimal tcl script in a file to the "disk", I can't find any way to execute this tcl script. Also entering "exit" freezes the PC with a '''kernel panic-not syncing: Atempt to kill init!''' message. If you could provide an iso that could fit in a floppy, I could try it on an old Toshiba TECRA, that cannot boot from the CD. That much so far. If you can provide some basic I/O functionality for it, e.g. serial/parallel/usb/sound etc, it could help start doing things with it. Even better, if it could be made to boot on a '''gumstix''' board [http://gumstix.com/products.html], that could make it an excelent new platform for tcl! [rdt] The Linux kernel on the iso is 2.4 MB so it will never fit on a floppy with a Linux 2.6 kernel. The panic comes from the fact that tclsh (running interactive) is the '''init''' process! If there is an executable tcl script in /bin, then it should run when its name is typed. [rdt] 2006.07.09 What I did (in my copy) was to change the /init from a sym link to /bin/tclsh to the following script: #!/bin/tclsh while 1 { exec tclsh <@ stdin >@ stdout 2>@ stderr puts "" catch {exec ""} } # End [slebetman] Perhaps we should also look at [ettcl], the tclsh distributed with [etlinux] and see if we can either use it or back-port some of their modifications back to the current tcl. What they did was added system commands to tcl: sys_dup, sys_exec, sys_fork, sys_kill, sys_nice, sys_pipe, sys_reboot, sys_sync, sys_wait, sys_chmod, mount, umount etc. Ideally we should make them extensions instead of directly compiled in so that we can do '''package require system'''. [rdt] Actually the ''ch'' family (chown, chgrp, chmod) can be handled by the tcl ''file'' command, but mount & umount are the next things needed. I think a .so is the way to go. [SEH] 20060711 -- Let us not forget the venerable [Tclx], which already contains many of these commands. [rdt] 2006.07.11 - There are a handful of things there that look useful, such as pipe & such, but I don't see any way with it to get mount & umount in pure tcl from it. Still sounds to me like system.so is the next way to go. [SEH] Wouldn't it be far easier to add mount and umount to Tclx than start a whole new package from scratch? [slebetman] I personally don't think it would be that much easier. Actually, with [swig] it should actually be easier to write a new package than modify Tclx. Apart from easier to implement we also get the advantage that we can do '''package require system''' in plain tclsh/wish for those who want it. We only need the minimum primitives to actually do the mounting and unmounting, querying info about mounted filesystems can be done in pure Tcl ''(we're talking about a Linux distro here right?)'' by simply reading '''/proc/mounts'''. [SRIV] Also, similar to [swig] is critcl, which also makes it easy to make c extensions. [slebetman] The moment I said that it is easier to write an extension with [swig] I knew I had to try it out. This took me all of 3 minutes (2 minutes to look up and read "man mount"): file: mount.i %module mount %{ #include %} int mount( const char *source, const char *target, const char *filesystemtype, unsigned long mountflags, const void *data); int umount(const char *target); there, done. This is for Linux of course since I recall SUNs having a different API for mount(). Now simply do: swig -tcl8 mount.i -o mount.c gcc -c -fpic mount.c -I/usr/local/include gcc -shared mount.o -o mount.so and now you can load mount.so in tcl. Of course we really should write a better interface to mount and umount but that should be done as wrapper procs in Tcl. [SEH] Cool. [rdt] Yeah & mount.so loads, but how do I pass the pointer to data into it?