Hari's Corner

It's been a pet peeve of mine that a majority of people who use (WYSIWYG) word processors hardly understand the difference between visual formatting and document structure. When a document is created using a word processor, there are a few "don'ts" that I'd like to prescribe for those who want to create reusable and maintainable documents.

Don't create headings by just changing the font and font size

Ugh. There's nothing more ugly than using the "default paragraph" style as a heading by merely changing its font/font size. It prevents MS-Word (or whatever word processor you're using) from detecting the presence of a document structure and you can never create a Table of Contents.

Don't go from paragraph to paragraph, modifying paragraph properties

This is another issue I have with people. Have you ever modified a document by going from one paragraph to another by selecting huge chunks of text to modify its properties? This is a waste of time and makes your document a nightmare to maintain. Instead use the style manager of your word processor to define a particular paragraph style and apply it to all the text in your document. Makes it much easier.

Don't leave a trail of whitespaces to create blank lines/gaps

This kind of thing really isn't required. The best way to create spacing is to adjust page properties or use the "page break" feature to start text from a new page. For horizontal gaps try using tables or columns in your pages rather than manually leaving the space using spaces or tabs.

Again, many people have the habit of leaving a blank line between paragraphs. This is really not required. Gaps between paragraphs should be defined as a part of the paragraph properties and not by using whitespace characters.

Structure before visual formatting

Don't worry about the visual formatting of the document. Just use custom styles to enhance the visual appearance once your structure is in place. A visually appealing document without a structure can be a nightmare to maintain. A structured document can easily be made visually appealing with a minimum of effort later on. Always keep structure in mind while creating large documents.

Learn to use the style manager

This point is related to the earlier point. Using the style manager can be a great help in creating document elements which can easily be incorporated into your document. Do you need to use program listings in your code? Define a style which formats text in a fixed width font, within a boxed paragraph environment. Define this once and apply this style to whichever portions of text you need to format as code in your document. This makes it much easier to define and use a variety of document elements without doing the visua formatting work over and over again.

Finally, select the right tools for the right jobs

Finally I would suggest that people who want to create technical documentation or documentation that requires long-term maintenance either use a structured, feature-rich high-level typesetting system like LaTeX or a meta markup language like XML/SGML which enforces structuring rules rather than maintain these documents as DOC files.

Word processors are best left to PAs and office secretaries who create disposable documents like letters. Technical documentation which requires long-term maintenance and updation should almost never be written using a WYSIWYG editor.

I had written an article some time back about how Linux faces a potential threat in the form of fence-sitting freeloaders who constantly crib and complain about Linux without anything positive to contribute. It's also quite true that veteran Linux users generally tend to cut these critics down to size and generally restore harmony in the world.

There is another side of the issue here which is probably a bigger threat to the Linux community in the long run than the one I mentioned before. It's not Microsoft or Intel, IBM or Sun Microsystems. It's about the internal conflict within the community itself. I'm talking about the eternal ideological conflicts and subconflicts that keep rupturing and fragmenting the community into smaller and smaller pieces. Don't know what I'm talking about? You should probably read about the history of the GNU movement. It all began when Open Source was born and acquired a distinct and separate identity from Free Software. Still confused? It's quite possible, because today people continue using the terms Free Software and Open Source interchangeably, although Open Source is arguably the more popular term. While I don't want to get into the history of this ideological rift, I am sure that most of today's problems in the FOSS world can be traced to those events.

The increasing commercial interest in Linux poses new challenges which the community has to deal with. Corporates are seriously looking at Linux as a business opportunity. Let's have no illusions about that. While this is essentially a good thing, it can also be a bad thing because corporations are more interested in their own growth rather than about the future of Linux. They will continue supporting Linux only as long as it makes business sense to do so. So they really cannot be relied on as a powerful ally of the community at large. Add to this the constant and confusing battles over which is better - the GPL-type license or the BSD-style license? Developers continue to fight over what is the best way to cover their backs while at the same time keeping the freedom envisioned by GNU alive. In some cases, it's also become fashionable to bash the FSF and GNU and instead adopt more restrictive licenses while still using the term "Open Source" leading to more confusion. Add to this the heartburn over software patents, Java, DRM, the GPL v3, Trusted Computing and the increasing worry about how to make FOSS commercially feasible. The last one is probably the most important issue because it is extremely sensitive because fundamental values and systems differ from individual to individual and this has probably the potential for maximum disagreement within the community. There is always talk about how to make money with FOSS, but rarely do we see any concrete examples of this put into action. A majority of the major FOSS projects today survive today purely out of voluntary community support. How long will these developers have the time and energy to maintain these software while getting no monetary reward out of them? Is corporate funding really a solution or will this lead to restrictions of software freedom and more importantly restrictions on creativity of future development? Difficult questions that need answers in the near future.

All these issues separately are minor ones, but they all point to a deeper rift - essentially a value conflict among those who belong to the community in general. This is dangerous because cooperation was what built Linux and conflict can just as easily ruin that work. Especially if that conflict becomes a conflagration.

These doomsday scenarios might sound far-fetched, but my observation over the last few years is that the Linux community is just drifting along - which is a dangerous thing - and we need to wake up while we're still ahead of the game. I'm not sure about the ideological drive behind the community any more. If it exists, it has weakened considerably. The new generation of Linux users no longer seem to care about the fundamental values driving FOSS. They want Free Beer and don't care about the Free Speech part of Linux. They know Linux exists and know its benefits, but seem to have the attitude that there's probably more where that came from and somehow, somebody with a majic wand will keep producing Free Software forever.

Sure, you'll probably say that a majority of us aren't programmers and couldn't do much with the source code so why should we care, but that's not the point. It's *understanding* what that freedom stands for that's more important because we'll know why we need to defend those freedoms. Never underestimate the power of ideology.

So if you haven't already do yourself a favour. Read the history of Linux, the GNU movement and Open Source. Wikipedia is a great source to start with. Find out and think about why these differences exist in the community. Take a stance, analyze it and last, but not the least, understand the full picture. Every serious Linux user and fan in today's environment needs to be informed and empowered if we're to make a difference.

Here's my next cartoon character: "Stylebabu" Venkiramanna:

Occupation: Actor, action superhero
Specialities: Colourful clothing, guaranteed superhit movies at will many of them dubbed to other languages.
Age: Never mind... er... most of the heroines of his movies are less than half his age. Officially 45.
Plans to retire: "An artiste has no retirement."

Simple DirectMedia Layer (libSDL) is a cross-platform low-level graphics API that can be used to develop games on Linux. At present I find that it's one of the easiest among all the low-level APIs I've encountered to get a hang of and start programming.

Mind you, my first SDL program is very basic (as can be expected), but I guess many programmers will find that this is actually what is required to get you started on more involved graphics and game programming using SDL. I'm still playing with it a bit, but once I get around to creating a few simple programs with SDL it would be easy to build upon it.

Compared to the monstrosity that is DirectX (and which takes ages for you to understand something just to display a blank screen) SDL is a cakewalk. Python programmers will be interested in pygame.

Here's a very basic C++ program I wrote which just loads a PNG image (requires libsdl_image library as well as libsdl) and displays it in a window until the user presses the button 'Q'. It takes a while to poke around the documentation to understand the first few steps, but once you do that it's really easy. Those who've gone through any DirectX tutorial will realize that a similar program to display a bitmap or image using DirectX would require much more code.

For what it's worth, here it is:

#include <SDL/SDL.h>
#include <SDL/SDL_keyboard.h>
#include <SDL/SDL_keysym.h>
#include <SDL/SDL_image.h>
#include <iostream>

SDL_Surface* screen;

int main ()
{
	if ( SDL_Init (SDL_INIT_VIDEO) != 0) {
		
		std::cerr << "Cannot initialize SDL";
		return -1;
	}
	atexit (SDL_Quit);
	
	screen = SDL_SetVideoMode (640, 480, 16, SDL_HWSURFACE);
	if (screen == NULL) {
		std::cerr << "Unable to set video mode";
		return -1;
	}
	
	SDL_Surface* img = IMG_Load ("sdl_test.png");
	SDL_Surface* img_format = SDL_DisplayFormat (img);
	SDL_FreeSurface (img);
	
	SDL_BlitSurface (img_format, NULL, screen, NULL);
	SDL_Flip (screen);
	
	SDL_FreeSurface(img_format);
		
	SDL_Event event;

	while (1)
	{
		while (SDL_PollEvent (&event))
		{
			switch (event.type)
			{
				case SDL_KEYUP: if (event.key.keysym.sym == 'q')
							exit (0);
						break;
				
				case SDL_QUIT: exit (0);
			}
		}
	}
}

I have often criticized hardware manufacturers in the past for poor Linux driver support. In particular ATI's support for its video cards had been extremely poor in the not-too-recent past. However, all that is a thing of history now. I recently downloaded the latest version of the ATI proprietary driver and felt a bit apprehensive about how it would work, considering that I had the latest version of xorg and that I hadn't tried installing the ATI driver for a long time now.

What really impresses me is the improvements they've made over a period of time. Their latest driver supports all versions of Xorg upto version 7.0. The distro-independent graphical installer (which also has an option to create distro-specific package for the driver) works like a charm and the fact that there's very little manual tweaking now required to get 3d acceleration to work is something that comes as a great relief. And the fact that the installation of this driver no longer removes the older X configuration which assures that you can still use X and remove fglrx if things go bad. This is really something great. The other great thing about the installer is that it can also work in the command line without X as it comes with a ncurses interface too.

I managed to get version 8.26 installed on Debian etch. Obviously a couple of reboots are required for the 3d acceleration to be fully functional. Once for running aticonfig which creates the relevant ATI device section in xorg.conf and another for the fglrx module to load successfully thus enabling 3d acceleration. I don't know a way around the reboot since trying to insert the kernel module manually didn't work for me the first time.

To make sure that 3d acceleration is enabled after installation run fglrxinfo from a terminal. You should get this kind of message:

display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9600 Generic
OpenGL version string: 2.0.5879 (8.26.18)

All in all, this has prompted me to make a blog post about Linux after a long, long time. More coming up! Watch this space. :)

I've just been appointed as a senior staff member at TheAdminZone forums.

Being appointed a moderator of a community of forum administrators is a special feeling. Hope I can do a good job of it now.