[DE | EN | FR | JA | ES]

Welcome once again to Georg's Brave GNU World. I'd like to begin with a small but rather useful project.

Sel

This kind of functionality was impossible to get in shell scripts without rather complicated and error-prone dialog scripts. Thanks to Sel there is now a small - the C sourcecode archive containing manpage & help is 20kB - curses library based tool available.

Using the curses library is the only real weakness as Sel is limited by the curses limitations. Sel is released under the GNU General Public License, which makes it Free Software and the author explicitly encourages others to to modify it accordingly to their needs.

But I'd like to seize this opportunity for a personal remark. It did happen quite often in the past that authors of such small projects didn't approach me because they didn't consider them "worthy." I completely disagree. In my eyes especially these small projects make up a very significant part of the movement - even if they sometimes fail to get a lot of recognition in the flood of new developments.

That is why I think the column is a good place to offer these small projects a forum. But I can't be everywhere and see everything - which is why I depend on your help. Should you have written such a small project or stumble upon one on the net, please tell me about it. The email address [1] should be sufficiently far-spread by now, I guess.

LinCVS

His reference was WinCVS although it does ask the user far too often for information that is already present in the CVS administrative files. Additionally many frontends are not capable of administrating more than a single project. Tilo Riemer was a CVS newbie when starting the project so his demand was that LinCVS sould be extremely easy to use and very stable.

The usage of LinCVS is in fact extraordinarily simple and one of its best traits is that the user only has to give information for import or checkout of projects. What will also benefit many users is that LinCVS is capable of searching entire directory structures for CVS managed projects, adding them to the workspace automatically - which has no upper limit for the amount of projects managed. The separation into CVS and non-CVS managed files is very intuitive, as are the context menus that can be brought up with the right mouse button.

Authors of this GPL-licensed project are Tilo Riemer, Wim Delvaux, Helmut Koll and Sven Trogisch. Their biggest problem is currently optimizing the autodetection of changes made outside of LinCVS because that takes up too much processing power. On their todo list are also the full support for ssh, the simplification of the checkout of older versions, easier merging of branches and a WinXX port. Since none of the authors work on LinCVS full-time, they are still looking for developers but mainly for people who'd like to do some documentation.

All things considered I personally like LinCVS a lot. Only the choice of the toolkit is unfortunate as the authors decided to use Qt. This and the missing autoconf/automake configurability were the only drawbacks I could find.

Dia

The functionality of Dia is comparable to that of the proprietary program "Visio." Its job is to create structured diagrams out of standard objects. So it does have modes for flowcharts, network- and UML-diagrams, for instance. But there are also some generic graphical functions to create simple drawings.

The program has a wide number of output formats like EPS, SVG, CGM and PNG and due to the win32 port of the GTK+ toolkit, which it is based on, it is also useable under win32. This makes communication problems unlikely.

Extremely positive is the extensibility. Should a certain type of diagram not be supported yet, new objects can be added via simple XML files which does not require programming skills in most cases. Only creating import filters for alien formats is still a little difficult but they are working on making this easier.

An import filter for "Visio" diagrams is particularly missed by many users, but since it is a proprietary program with proprietary formats, an import filter is not as trivial as it might seem. This is a typical case in which a user's data is locked up in a data format that he has no control over or access to.

The authors do not have free capacities right now to reverse-engineer this format, but on the Free Software Bazaar under the ID 990524A you will find a reward for the person that succeeds in writing a library that can read and write Visio files [9]. As I write this, the reward posted is 3000 USD - so if you happen to have a little spare time and want some spare money you might give it a look.

Other plans are implementing more types of diagrams and completing the Python binding. Dia also needs more documentation - volunteers are very welcome. If you want more information, the Dia mailing list is probably the right place to look [10].

Since the next two projects are closely related, I will do a joint feature. Although this will be more or less an article about upcoming technologies I still think it should be interesting for most people.

libCIM & PaulA

In order to have this feature widely understandable, I should probably give a short introduction to the background. CIM stands for Common Information Model and it is an object oriented concept to model system information. Its origins are the so-called Network Management Systems (NMS) like Tivoli, OpenView and so on. Their job is in the area of exchanging information within big networks and administrating these systems based on the information exchanged.

In order to have some way of communication between the different NMSs, a shared protocol was needed. It was out of this demand that the "Web-Based Enterprise Management" (WBEM) initative was born that defined the CIM standards as well as their encapsulation in XML and the transport via HTTP. The publication of these standards is done by the "Distributed Management Task Force" (DTMF) [12]. So much for the background.

In the case of communication between two NMSs, one of them becomes the clients and the other one the server, the so-called "CIM Object Manager" (CIMOM). Assuming that the client does have access at to the server, it can read and change system information on the server. Since CIM has been designed to allow monitoring of any type or structure of network, it is a little too complicated to be described in detail here. For understanding the principle it is only important to know that the CIM defines certain base and derived classes. It is the objects that have been instantiated out of these classes that are being read and manipulated by the server.

If this was over your technical head just believe me on the following: this principle allows you to administrate networks without knowing the specifics (hardware/operating system).

LibCIM is a Perl library that allows programming in CIM objects. It also has functionality to serialize them in XML and transport them via HTTP. So libCIM can be used for the creation of CIM clients and servers (CIMOM).

PaulA is a server/CIMOM which uses libCIM for implementing the CIM objects. One possible use for PaulA would be to administrate GNU/Linux systems in a standardized way without having to know about the distribution the different systems run on. Definitely something that'll make life easier for administrators.

The current status is "pre-alpha" - so it'll be a while until you can use it on a daily basis. The developers of libCIM & PaulA, Axel Miesen, Volker Moell, Eva Bolten, Friedrich Fox and Marcel Hild, do hope to have a stable production system within a few months, though. This system could then be used to check the interoperability with other CIM systems. But at the moment, a lot of providers (the code that does the actual work) have to be written.

This is definitely a very hot area, licenses for software packages like Tivoli are extremely expensive and experts on these technologies are rare. Developers are interested in participating in this project are very much encouraged to do so.

I'd like to use the remaining lines to answer a question that Hans Fuchs has asked because it does get asked rather regularly.

What to think of Sourceforge?

Personally I am someone to encourage a sound amount of scepticism if it comes to altruism in companies - although companies in the GNU/Linux area rather often do have the motivation to "give something back." But I don't think we have to rely on altruism. Like other companies in this area, VA Linux lives through and with a lively and healthy development of Free Software. So the Sourceforge service helps strengthening their own foundation. Additionally it is rather positive for their public image and it gives them the chance to keep an eye on many interesting projects.

But does this maybe contain an underlying threat to the community that might be thwarted by mirroring the servers elsewhere?

Personally I regard this risk as being rather small. First of all VA Linux has nothing to win by trying to exploit their access to the projects. The resulting image loss would be so severe that it would vastly outweigh the gain.

And all authors keep local copies of their sourcecode, too (not even mentioning the releases spread all over the net) - which could be developed anywhere.

That's why I believe that has its uses and does help the development of Free Software. But it could also not hurt to implement this concept in other places to have a less centralized situation.

...and onto the plane