On Tue, 7 May 2002, Raymond Moyers wrote: Raymond, What Ben said almost exactly echoes what Dennis Ritchie says about Unix. The fact that we keep it working doesn't mean it's not archaic. Doc

On Tuesday 07 May 2002 09:59, you wrote: That is *ONE* of the existing interfaces, its also *based* on text CRT's, and Graphical Interfaces that are Network Transparent. It wasn't always that way, but appledos was text, msdos was text etc, everyone added on a GUI Adding on the GUI wasn't wrong, but those that removed the tty did something utterly stupid, all they did was cripple the box making most of the function it provided impossible. That assumes that Unix lacks your so called "modern I/O" Winblows apps are not network transparent and so are not "modern" You can run X on a sun IPX and other lowly machines. last time i checked .. http://www.ltsp.org here they are using obsolete 486 boxes and such as diskless graphic terminals and hanging up to 200 of them off a single modern PC where all software executes. standard Unix GUI apps are all network transparent, so the ability for 400 programs running on a host PC to be displayed and used on 200 terminals is built in to X11 as one of its basic original design elements, not some kludge added later. Bloated ? win2k needs 64megs to run the install program, thats bloated,,, linux with X will run on a 486 w 16m quite happily just choose a lighter desktop program like blackbox here is a list of desktop programs, called window managers they are for the most part application and Unix flavor agnostic and interchangeable guide to window managers and desktop environments http://www.plig.org/xwinman Two more lists .. http://linux.about.com/cs/windowmanagers/index_2.htm http://linux.tucows.com/system/desktop_managers.html We have the source to X11, where did you hear this garbage ? http://www.ltsp.org is all about using old underpowered scrap boxes as Open Source diskless xterminals. Conceptually how would you pipe a GUI ? and since most anything a Unix guy types more than once becomes an automated script, how would you script with a gui ? And if you managed to figure a concept would it be superior to what you are replacing ? ( this last question is why it hasn't been done, because it a BAD idea, it does not survive scrutiny, the idea wilts and turns putrid in the brain the more it chews on it ) This is still as oxymoronic as the last time, im not getting your meaning here, we have been over fonts, so perhaps you are talking about something like twin Twin is a text-mode window environment. It turns a text terminal into a X11-style display with window manager, terminal windows, and can also serve as display for remote applications. http://linuz.sns.it/~max/twin vmaout:~# uname -a Linux vmaout 1.2.13 #8 Tue Mar 12 02:41:18 CST 2002 i686 vmaout:~# ls -l /bin/bash -rwxr-xr-x 1 root bin 295940 Feb 14 1995 /bin/bash vmaout:~# ldd /bin/bash libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.27 This machine here is running a 1995 flavor of linux kernel 1.2.13, libc4 and a.out format binaries As linux goes, its really "obsolete" but its rock stable and plays totally nice with all the others and will run sweetly in a very small footprint, perfect for that old laptop with that old 386sx cpu. My old 20MHz mips 3k Sony News laptop, both ways, apps or file system, networks perfectly with all the rest of the stuff both modern and not so modern The old sony and its old 1991 OS is very old, and there have been up to 11 years of "upgrades" since what its running was installed. all around on the systems surrounding it depending on age, are various snapshots of history and yet, just like the 1995 linux it is still seemless with the modern stuff, i use it as a coffee table xserver for the other boxes when i want to sit out there instead off in here, I share your Open Hardware preference, if not open then fully documented interfaces so that driver writing involved less reverse engineering would certainly help. The proprietary nature of some hardware and lack of open documention is certainly a cause of greif to many on this list as we all well know. Unix/Linux is certainty small, and it is certainly fast. Do that all the time, only replacing the kernel needs a restart. a gross change in the main clibrary would require a restart unless you had the essentials compiled static. How important is this, and are you willing to accept the undesireable side effects of what you are wanting ? Check out debian apt-get its totally automated. Well, seems we have all the things you say are lacking except for the bits that you need to spend a bit more time chewing on. The left have butchered 200 Million people in persuit of utopia, they are guilty of the worst holocaust the planet has ever seen. All because the left refuse to examine the less desireable but unavoidable side effects of the bloodstained policy they advocate You will find some similar gotchas in your piped scripting gui idea, if it destroys what your attempting to improve perhaps its a sign that it isnt an improvement. Raymond

On Tuesday 07 May 2002 09:31, you wrote: "Full System" to do what tasks, linux has a a lot of tools and any task one could imagine could not involve all of them, i will have to dismiss as nonsensical, especially since what tools are on the system is all up to you, such as the microlinux's like linux on a floppy, linuxrouter project and other speciality oriented package creations illustrate. The second part, upgrades Are you demanding to compile without a compiler ? You can get updates in binary form in just about every linux distro I can name, as its their standard upgrade method others deal only with source, like rocklinux if that what you want instead. If you remove all the devtools and strip all the libraries, you will then have a system that has a drastically smaller footprint so you would compile stuff elsewhere into stripped packages, and then install the packages, and then it would be the same as any binary-only app install everyone is familiar with. Winblows dont come bundled with symbols in the .dlls .h files and devtools, and any of the other things, and i hear you complain not how would your logic above apply equally to winblows ? See like the shared library complaint you are asserting an atvantage as the opposite. and the assertion does not withstand scrutiny. Then get the binary, All non=specialty linuxes i know about come with perl precooked and software authors take note of what a system can be expected to have, and code with that in mind, he would look at your aversion to his use of perl as being unreasonable. Look at : http://linuxassembly.org/resources.html#projects various UNIX projects written in assembly language of course all of them feature extremely small size small and simple has a quality all its own doesnt it, early versions of e3 have a less than 5000 byte foot print and no 64k limit since it isnt built on that old real mode tiny memory model, its now up to 12k because of feature creep such as : command syntax Wordstar, EMACS, Pico, nedit, vi independent of libc ( needs no library) numeric calculator UNDO feature piping through /bin/sed (using stream editor as a sub process) are currently designed for Linux and *BSD only, anyway this opens e3's door to the world of regular expressions. http://sax.sax.de/~adlibit/ Pretty impressive for a standalone 12k exec eh ? If you want to craft a linux that runs on really absurdly tiny hardware, you can do it. IBM demoed a tiny linux on a wrist watch close to same time time they announced it on their mainframe, how is that for range of scale. Like linux on a floppy ? there are several of those crafted for different uses, routers, terminals, net appliance type things, svgaVNC etc. Really now, are you just tossing stuff up hoping something will stick ? Unix has had 30 years of people looking for holes and filling them, in the base you would find it hard to discover any more existing cracks or gaps to fill. its all about new drivers and new ideas on things like the VM to push the performance envelope. neat stuff for a kernel hacker, but even Linus himself said that everything exciting was happening in userspace, Raymond