Older blog entries for mslicker (starting at number 19)

17 Jul 2002 (updated 18 Jul 2002 at 00:56 UTC) »
Linux deobfuscation project

Reguardless of the particular merrits of Linux, a large body of device drivers has been written for it. So much so, that when designers of new operating systems embark on creating a system they often op for building on top Linux, despite the incredible drawbacks that come from this approach. Furthermore, for some devices, Linux may be the only reference for programming a device. This is due partly to the fact that manufacturers' support of "open source" means the development of a Linux driver, not releasing the specifications as they should have done.

Reading source can be quite difficult for all but the most seasoned Linux hackers. This is due to many factors. A certain coding style, ubiquitous comments, and the general clumsyness of the C language.

My idea, is to mechanically convert the Linux sources to a form that at once represents their true structure and more directly represents their semantics. A particular machine configuration will be assumed. Therefore preprocessing can be done in it's entirety. Comments and macros will be left as hypertext annotations. I think file structure should be completely broken down, leaving just a call graph (or forest). Types will will be completely striped and left as an annotation, with a similar graph representation.

Currently this only exists as an idea. If you are interrested in funding this work please contact me. I say this because it is not something easily done. It would require some time to do right, and that is perhaps the only thing preventing me from doing so.

--- Update Grammatical corrections.

tk wrote:
Is there a non-OO system architecture which can facilitate the creation of object-like interfaces for the entire system? This is exactly what I've been trying to figure out.

I can name three: Lisp, Postsript, and Forth. Lisp on Lisp Machines aparently had an object-like interface. There was the Postcript News windowing system, which facilitated object-like interfaces. Postscript is of course a special case of Forth, so such interfaces could easily be developed in Forth. I have even heard of Smalltalk like GUIs being developed from members of the forth community, although I've never seen these in person.

One common thread among Lisp and Forth, besides the simple syntax, is the extensibility of the language. This is the key feature which allows these languages to be applied easily to any problem.

The Postcript News system on the other hand, was far more isolated most of the facilities were built into the window server and were hence unchangable.

nymia, I noticed there is a lot of activity hacking the Xbox. Seems quite close to what you want, commodity hardware, PC like. And people seem to be making progress hacking the hardware.

tk, A bit belated. Just to note, that the user interface may be object-like, and user friendly, without the operating system necessarily being object-oriented.

Applications and processes are probably left over from the old time sharing systems, from which unix is derived. There is no reason to organize the system in this particular way, except prehaps lack of imagination on the part of modern os designers. Also the notion of an application has strong favor with proprietary software companies. Kind of a little fortress seperated from the rest of the computer, which they can control, and resell to you and indefinite number of times.

Can't say an OO operating system is worth it. There doesn't seem to be any concrete reason to organize the system in this way except for the designers preference. New systems certainly have a lot of potential if only the hardware barier can be broken through.

vsync

If anyone is familer with programming the vertical sync interrupt of video cards, please contact me. I'm having a bit of trouble. This is a more modern card, the Matrox G400.

raph, I have to ask, what problem are you trying to solve?

If you care about performance, you should know that the fastest display engines know specifically what can change, how it can change, what needs to be redrawn, the best way to redraw, ect.

Also this generic tree structure will of course add much bloat to any application willing to use it. An optimized representation will always beat it, sometimes by orders of magnitude. Creating such library is a sure way to encourage bloatware, and mediocrity.

I believe this line of thinking, and similar thinking, is perhaps the true source of bloat and complexity in todays software. If people would only address the problem at hand...

tk, Are we really doomed to Windows and Unix forever? Or is there a way out? I feel that latter is true. If didn't I'd probably give up programming. You must too, or else why would you work on Delitalk? colorForth, Chuck Moore, and others I believe offer the intellectual strenth to break through the bloatware stranglehold. Not to mention the C stranglehold, The language that has held so much back.

tk, At that resolution, if you intend to program in colorForth, you might want to create your own font. The font that comes with colorForth is quite large, even for 1024x768. One block of source code (1024 bytes) completely filled, fills up roughly the entire screen with the default resolution and font. So you want to scale the font down at least a third in each direction.

Chuck Moore has created a nice manual.

If you want to write a simple app to get a feel for it, first open the editor (type 'e' 'space') find and empty block. Then type some thing like:

ok show black screen green 120 75 at 200 125 box keyboard ;

Where 'ok' is red, the rest are green. Load the block ('xx load '), type 'ok', and you should have a green box on the screen. colorForth comes with other examples, but these might not fit on your screen.

tk, Actually I have converted thte colorForth sources to GNU assembler. You can find the sources and some other things at my colorForth directory (I should probably make web page for this). Some people have created colorForth's with a resolution of 800x600 and some other modifications to get it working on their system (colorForth index).

Here are some screen shots of the editor (full size). In lower left corner you will see a visual display of the stack, in the right corner the function keys (these change depending on the application). 'full' is the last comand typed, which took the screen shot. Of course, the rest is the source code. The funny red shape in the source code is the cursor.

I'm not sure if you need any built-in skills to do colorForth well. Mainly you have to be willing to do things in very different way than you may have done before. Usually we try to break problems into tiny pieces. The smaller the piece, the easier to optimize. Optimization in colorForth is not as complex as register-based machine code optimization. It's kind of like untangling rope. You try to find the most direct computation, with the least number of stack manipulations. Simple RPN arithmetic expressions are examples of optimized colorForth.

I found my own skill has grown quite a bit, from being a colorForth newbie to gaining a certain level of competence. I'm not yet close to the mastery of Chuck Moore.

17 May 2002 (updated 17 May 2002 at 22:11 UTC) »
tk, To me, Smalltalk is clearly one of the more elegant object-oriented languages I've seen.

However, I dislike object-oriented programming in general.

  • Rarely are objects and the relationships bewteen them meaningful to the problem being solved.
  • The problem can always be solved in a more efficient way using the von Neumann model. The dominant archiecture of computers today.
  • I don't like being limited to a single mode of programming.

As a system, Smalltalk is not very promising. The prominant Squeak system is quite large and not that responsive compared to existing systems. Improvement from the users perspective requires consuming less resources, and a faster response, among other things. It could be that the squeak developers went a little feature crazy. Squeak doesn't seem to have a purpose, other than to show how various things might be coded in Smalltalk. Maybe it is possible to have a much smaller smalltalk with adequate performance, and usable applications.

Impovement though, is very much possible. Just look at the slop that passes as functioning C code these days. Impovements to existing systems can be made in speed, resource consumpion, code size, simplicity, and the user interface. All of these can be improved by orders of magnitude, without coding everything in assembly. However it is required that you start from scratch, in an extremly capable language.

In this reguard, the most promising system to me is the colorForth system. The philosophy of this system is to cast off as much bagage as possible and start fresh. The system is %100 original code by Chuck Moore. Performance is excelent. Although the code is not purely optimized for speed like compiled C. colorForth chooses a much simpler compiler instead. In fact the compiler and the entire core software is under 2k. Extensibility is at the heart of the lanugage, so the large range in semantics required by a modern system can be expresed elegantly in the language.

The reason why colorForth can achieve such improvement, is that it relies purely on human ingenuity. The only limit in how good the code is, is in the programmer writing the code. The reason why the compiler does so little, is that the code is already human optimized.

For software to improve, I believe we must rely primarily on our own creative abilility. Automation of creative tasks makes us the slave to the machine.

5 May 2002 (updated 5 May 2002 at 15:20 UTC) »
davidw, I was at the event too. I think it went pretty well.

I get the feeling though, that Chuck Moore is more a novelty among the Forth community than a respected influential figure.

This is unfortunate since what he is doing is really the main stream of Forth. I don't see anyone pursuring the principles of Forth as vigorously as he has been doing. It hard for me to imagine of all people, Forth enthusiasts being the closed minded ones...

I found the discussion of Forth ML interesting. Actually, I have plans for a colorForth web broswer too. Perhaps there will be some collaboration in the future. Chuck has said on the colorForth mailing list that he will release his networking code at his next website update, this should be interesting. I've been working on a jpeg decoder, so this will hopefully complete another part of the puzzle.

13 Apr 2002 (updated 13 Apr 2002 at 20:21 UTC) »
raph, C is generally a clumsy language. Take a simple function in C, say the power function:
int power (int x, int p) {
    int r = 1;
    while (p--) r *= x;
    return r;
}
In colorForth we would do this (without color):
power 1 swap for over * next nip ;

This example does not tell the whole story however. Where in Forth we can extend the semantics of the language. C is stuck with the same syntax and semantics, which become increasingly clumsy as programs become complex. My example in C is very generous in this reguard. Look some object oriented C to see my point more fully.

Anyway, I'm not trying to bash C, only providing a counter example to the argument that programming in imperative language is necessarily ugly, or unelegant when compared with functional languages.

I do program in functional languages, but only ocationally, when I intend to run the program once or infrequently.

When writing system code or application code, it is really worth the effort to take the time and craft the code.

--- Update

Forgot the case when the power is zero. Modified the code. Note the colorForth code would need a more semantically complex "for next", since "for next" only handles a positive number of iterations.

Forth
zhaoway, bigFORTH is a native code forth. I have not used it.

As yet another lanuage to run on Unix, I agree forth is not very interesting. However if you explore it's ideas a bit more you will see that it is a complete computing philosophy. From machine to human interface. The abstractions in the forth language are not arbritrary, but yeild very practical results, unlike the majority of existing languages. Please visit these sites[www.colorforth.com, www.ultratechnology.com ] for more on the philosophy and ideas of forth.

I've been programming almost exclusively in colorForth, which is both a language and operating system. The code for the system is simply a work of art. I chalange anyone to find a more beautiful system written for the PC. This has caused me to revaluate my own work, and I see that in a less complacent time some of my previous work would be contemptible. I'd like to develop a web browser for the colorForth system, so it can be more readily compared with GNU/Linux. I'm working on bits and pieces when I have time.

TWM
davidl, What is wrong with twm? This is what I use in Debian. I find it the most usable window manager, when properly configured.

10 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!