Older blog entries for mslicker (starting at number 6)

sej: I think you do point to a major problem with free software, more specifically the GNU project.

Most of this software in and around GNU is written in C. The major problem is that C promotes reuse at the libary level, not the source level. This is not a problem by itself, indeed a reasonable set of libraries can devised and maintained. In systems based on GNU however there often many poorly designed libraries, libraries that duplicate each others functionality, overly generalized libraries, libraries that wrap multiple similar libraries. Rarely do these libraries offer a consistent interface.

Over time, you would think that this bloat would reduce to a very compact set of libaries which contain the core set of functionality. But this is not the case, indeed the greatest freedom of free software is ignored, the ability to modify the source. Why people choose to create new software instead modifing existing is software, I think is not just ego. As dan points out, just trying to build someone else's software today can be daunting. Also within each project are different set of coding conventions, sometimes odd use of language (classes in C?), different platform abstractions, and many other intricacies peculiar to a project. And then there is the sheer size of some projects. Try understanding a project like Mozilla, Linux, or X. The result of this is that factoring code into a consistent highly reusable set of libraries very difficult. The problems with applications are similar.

Another major barrier to reuse is the use of different languages. This division, for example, produced two practically equivalent Unix free software desktops, KDE and Gnome. And even then the division is minor since C functions can be called directly by C++ code. Factoring is still difficult if not impossible between these languages. If the languages are even more different than you can forget reuse altogether.

So I've listed some of the problems that exist. What is the solution? Focus. If the project is a Unix make that the scope of the project. If the project is a desktop, design from the hardware to the user interface. The result may be several operating systems, for different uses. The GNU project lacks this focus, it tries to be everything to everyone, this is the source of much of the bloat.

Beyond this I think better languages are in order, and tighter integration of the language to the system. colorForth address many of the problems I have outlined, and many I didn't even mention. And I think it embodies the spirit of free software better than the GNU project. The system is almost purely represented as source code. Not only does this encourage reuse, understanding of others code, and modification, it also promotes a high degree factoring and tailoring of code.

Oddly our software mirrors many aspects of proprietary software, binary distribution, plugins, many isolated libraries and applications. I think the future of free software should be in source code based systems. This is a more natural paradigm for free software.

maelstorm,raph: If your interested in stack languages check out Chuck Moore's site. He's the inventor of Forth which Joy and Postscript are derived.

He recently released colorForth into the public domain. It's both a language and an operating system. It's an amazing piece of software, both for it's simplicity, and compactness. The entire source code based system is less than 64k! With a tiny a kernal of under 2k! The system includes a complete develement environment (editor, compiler, interpretor), various applications and other bits of source code.

His designs (a combination of hardware and software) are definently ahead of their time. His chips are hardware implementations of the forth language. Forth serves as the assembly language and the high-level language, a perfect one-to-one mapping of language to machine. These designs (being asyncrounous) consume a lot less power and are of higher performance that conventional designs. One such design is 5x5 array of forth computers implemented on a single chip.

I can't help but think how different computers would be if these design principles were taken seriously.

Today's operating systems and machines are thoroughly bloated, with no hope of improvement. Hopefully, with the release of colorForth, people will see a system can be both simple and minimal, and be thoroughly enjoyable to use. Meanwhile I have found myself quite happy in the colorForth nitch.

I recommend this article in regard to the recent events.

I've been looking into display postcript (DPS, DGS)a bit. It looks like it could be the free software equivelent of MacOS X's quartz. Although you would need to modify X to get the full effect. It seems you could still implement the X protocol for compatability, but the window system itself would be a superset of X.

If the various desktops could standardize at the level of a postscript based windowing system, that would probably eliminate a lot of redundency in the toolkits. Also it would allow almost unlimited flexability in implementing different types of user interfaces at a more comfortable level than X.

Mulad: I'm probably in the same boat with you. However, let me point out I'm actually very happy with my Debian GNU/Linux system. It's a really great collection of software, and I'm also happy that all my hardware works under GNU/Linux too.

This being said, the Computer Science part of me sees that there are many things to be improved. The system model being one of them.

I think it is fair to say that in a new system model we would probably want to raise the level of abstraction a good amount. Objects seem to be an intuitive way to look at the world, and also in practice we have found breaking things into components makes a system easier understand. So it is clear that a modern operating system would probably be both component based and object-oriented (not necessarily in programing sense). Of course this really doesn't tell someone much at all. There are many details, such as what is the level of granularity of objects? Or in other words what is addresable and what is not? Do the objects interact with each other, and how? How can the user control the interaction between objects? These things are key to a system design of this type. In Unix we can pipeline commands and redirect the input and output from and to files. This has proved very effective for text processing, similar ideas are needed for the graphical environment to maximize ones productivity.

As far as the kernel is concerned, it seems the Hurd kernel would make a good basis for such a system.

Also I'm not in total agreement with your ideas. Networking is obviously paramount to any modern operating system. However, I don't know the degree at which networking should be transparent, it should certainly be as easy as possible, but a user should know clearly the difference at all times between what is local and what is remote. Also I don't like the compositional interfaces, this might just be a personal thing, but they seem rather sloppy, and I'm not sure it really helps the user.

Of course when it comes to the high level aspects of the system, the things the user comes in direct contact with, getting these things right is an art rather than a science, you just have to create something let people try it and improve based on their feedback.

Any way, these are very abstract ideas (and maybe vauge too!) of a new system model. Eventually, these ideas will need to be made concrete, and practical.

This is in response to the couple of articles on GUIs, I'd like to participate directly but Advogato doesn't permit this.

I think the first article which examines the seperation between the CLI and GUI I think is on to some thing. While the other article if followed would seem to dig a deeper hole for ourselfs.

Although language is limited in describing the world and the universe, it is the most powerfull descriptive tool we have. The computer in contrast has 3D visualization, 2D imaging, audio, and language in a limited form, as it's form of communication.

Ideally, if we want to improve communication between us and the computer we should maximize the use of what we are best at respectively. This to me suggests an advanced CLI as our main line of communication with the computer. The computer would still have it's advanced visualization capabilities and would maximize their use in respones to user commands and querys.

I think this direction could be pursued easily within our current framework of software. We would need a keyboard driven window manager, possibly similar to ion, which can be made in X. Also a more expresive shell will ultimately be needed. The big question is how would software for such a system be developed. Integration with the shell is going to be a given, but how could be very interesting.

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!