Updated 2013-09-15 11:13:44 by pooryorick ▲

See Also  edit

Roy Keene
has worked on a Linux distribution that uses Tcl as the primary glue

Description  edit

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 Tcl/Tk.

Why would one want to do this?

  1. Because it can be done,
  2. To advocate Tcl/Tk,
  3. To simplify the administration learning curve,
  4. To explore the performance aspects,
  5. For the coolness factor,
  6. What else?
  7. Custom industrial interfaces/kiosks
  8. To provide the synchronicity of having a commonly available scripting language - despite the negative aspects of Visual Basic, one surely recognizes the functionality brought to the table by having a common interpreted language available in the major applications on the platform. Some MacOS releases also had similar capabilities with HyperTalk (see hypertools)

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 <call_number> <arguments>

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/ rdt: for me on 2007.07.04, this is currently a dead link. Anyone find different? LV If you do a web search for etlinux, you will see that there was a shift in emphasis for the original developers of etlinux. There is currently an effort to kickstart a new project for the software. ) 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:

Console:

X Windowing:

Sound:

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? [1]. What mail client do you use? SRIV Currently webmail. [2] 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: [3] 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 [4], 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 <sys/mount.h>
  %}

  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? Got it! I added:
 %include  typemaps.i

That was surprisingly easy. I actually mounted the proc filesystem with:
 package require mount
 mount proc /proc proc 0 ""

And unmounted it with:
 umount proc

LES: I suppose it would be interesting to see a Tcl/Tk OS for mobile devices, i.e. phones and PDAs. I bet it would do an infinitely better job than Java seems to be doing (as usual).

escargo 30 Jan 2007 - I remember from ancient times an operating system based on SNOBOL. Most of what it needed to do could be made to fit into the string manipulation that SNOBOL was good at. (It's from 25 years ago or so, I think. I probably read about it in an Association For Computing Machinery journal named Transactions on Programming Languages and Systems (ACM TOPLAS).

rdt 2007.07.04 Well after a year of doing no more than thinking about this, I still think it would be a fun project. Now I just need to get one of those "round toit" thingy's. :)

tb 2009-08-19 - Is here any development? - @rdt: How did you create your bootable ISO image? I know about syslinux/isolinux and 'Grub, but your approach is different.

Category Discussion