:: Reviews : Ubuntu Goes Low Spec! (found here) introduced me to the new project called Ubuntu Lite.

What’s Ubuntu Lite? It’s a new Linux distribution. Its goal is to make a usable Linux-based system that works on 128 MB of RAM. How they plan to achieve this goal seems straightforward: around “lightweight” applications.

And it’s is exactly the wrong way to build a low-footprint distribution. Why?

Saving pennies, squandering dollars

First, the applications and building blocks chosen are simpler. In other words, they have less functionality than the two standard behemoths: KDE and GNOME.

Say it out loud: they’re building a cripple from the outset. It will never be as functional as any environment that comes with either KDE or GNOME.

Does that lead to a low memory footprint?

Second, the project is motivated by an underlying assumption: using simpler, heterogenous applications yields less memory usage.

This assumption is wrong. A recent study by Lubos Lunak completely disproved it. Chief findings of the study:

1. the system with heterogeneous applications (Xubuntu, promoted as the ‘lightweight’ variant of Ubuntu) did boot up into less memory usage;
2. but, as soon as any useful applications were opened, Xubuntu lost the war against both KDE and GNOME

There’s a perfectly reasonable explanation to this: both GNOME and (to a larger extent) KDE share much more code than the heterogeneous applications in Xubuntu. More shared code equals a larger footprint without open applications, but an incrementally appreciable benefit when real users are actually using the machines. Especially, if I may remind you, in terminal services settings.

Low-hanging fruit

Sure. I know one type of low-hanging fruit. Compile every application and library using the gcc -Os flag. It makes smaller binaries, which are faster to read from disk, and take (a bit) less memory. The savings should add up to about 10-20 MB of RAM, according to my completely unscientific estimates.

There’s another. Disable functionality (by properly configuring the applications before compilation). I’m not sure this is the route to take.

After that, any gains become exponentially harder.

Into the future

Fortunately, all is not despair. After the study was completed, it underwent wide distribution on the Internet. That study was directly responsible for cementing the belief on shared code.

Today, both KDE and GNOME are more committed than ever on the agenda of sharing code, and optimizing this very shared code can yield significant benefits. There are big gains lurking in all that shared code, and it’s yours for the taking. It’s just a matter of applying freely available tools and the scientific method. Instead of squandering time placing decals on your hot rod, why not try some real software tuning?

As for Ubuntu Lite: I just hope the Ubuntu Lite guys realized, independently, what you just read, and surprise us with newer ideas.

Yes, I’m aware that we could do the same with (at least) GTK+ buttons with a few layout containers packed in. Now, where’s the easy-to-use implementation in a vein similar to the Response abstractions in GTK+?

Most of the conclusions are not Earth-shattering revelations, but things we already know — mainly, that we’ve got all the assets we need to make Linux world domination happen.

But there’s one particular thing you and me know for certain… yet we’re doing practically nothing about it!

Anyone could have guessed that my undergrad thesis work is centered on Open Source; more accurately, we deal with devising strategies for Linux and Open Source adoption and penetration growth in the SMB sector of Guayaquil, Ecuador.

By the way, you can get the info and (of course, Ogg Theora encoded) videos from the site itself. As a matter of fact, the thesis is being done using a fully open source methodology underpinned by MediaWiki. Too bad most of you won’t be able to read it, since it’s in Spanish.

A fairly sizable part of our work was identifying Linux and Open Source weaknesses, and finding out how they fared in practice. Mind you, we fare pretty poorly, guys. We’re all tech, and no heart.

Do you know what my thesis’ first and foremost conclusion is? Linux and Open Source lack marketing. Ergo, we lack brand recognition. Ergo, we lack public trust. Ergo, misconceptions abound.

One of our interviewees said (in connection with Ubuntu) during a focus group: Oh, I see what they’re doing, they’re offering the software for free, so they can later change their policy and start charging us for updates. I’d rather pay a set amount of money upfront than having “them” change the game rules on me later on.. Being that we were conducting a focus group, the methodology forbid me from evangelizing on the true philosophy underlying Ubuntu (or Open Source). But I felt this nearly uncontrollable fit of anger when I heard that comment.

Almost all of our interviewees found Ubuntu Linux easy to use (no surprises there). Most of them were truly astonished as to how much punch Ubuntu packs in a single CD. A large portion of the interviewees were actually willing to try it, especially if the BSA threatened to crack their businesses down (that they were using pirated software is, of course, not a surprise as well). Just a single person, who seemed to hate computers, did not find anything to like about Ubuntu (and this person fits the reproductive learning profile — she memorized procedures instead of learning concepts about computer usage).

And it’s our fault. We’ve failed to annihilate public perceptions. We keep preaching to the choir, and continue with our inbreeding, collectively patting our backs as we marvel at our technical prowess, while blindingly ignoring our utter failure to generate double-digit growth and adoption rates. Our biggest competitor from the proprietary camp is having a blast while convincing everyone that Linux is shady and all things free are akin to viruses and other types of malware. They’re deftly playing into Joe Sixpack’s confusion about computers. By now, you should have learnt the lesson: technical or moral superiority doesn’t win the battle — and it never has. Marketing is paramount — good tech plus zero adoption just doesn’t count.

So, what are we doing about it? We can’t pool our resources into a single, giant marketing machine. Sure, great strides have been achieved in that direction… for single, niche OSS projects such as Firefox. I’m probably sure something like it can be set up for Linux — your favorite distro or Linux in general — but so far, we’re going nowhere fast with that approach.

Yes, our marketing sucks. That’s one of the conclusions of our work. The recent trend in large OSS projects that focuses on marketing is relatively new, and hasn’t made any public impact yet. And this kind of model simply cannot work for smaller projects, or unfocused efforts. Decentralization — one of our biggest strengths — simply doesn’t help.

In reality, the single most powerful and leverageable resource we have is time. We should be out there, pushing Linux to people; heck, even adopting friends’ and family members’ computers. I’m currently adopting my best friend’s computer. He double-boots Windows 98 and Ubuntu. He always gives me the crap that Linux suxxx; if I had Windows XP installed, this or that program would work, and I wouldn’t have this or that problem; but, you know what, everytime I visit (two times a week) he’s running Linux, not Windows. He even got hooked on Amarok and hates the fact that he can’t run Amarok on Windows. That means the drug caught on. But someone had to get him hooked on the dope. That was me.

You can clearly see I’m not blabbing about “do as I say, not as I do”. I work exclusively on Linux and Open Source. It’s in my best financial interests to push my platform like a street corner dope dealer. By doing that, I’m trying to secure my financial and computing future. Your inaction is preventing me from galvanizing my (and your own) dreams.

So, do your part, damnit!. How much does it cost you to burn ten copies of Ubuntu or Fedora live CDs, and hand them out to your friends, family and co-workers? It surely beats helping them out with illegal copies of proprietary software. This may end up benefiting yourself — as I said before, we’re going nowhere fast, with slow or zero adoption rates. If you truly care about Linux, Open Source and want to preserve an open future for everyone, you should be spreading Linux like mad.

One million Linux users… five Linux installations for each one of them. Lofty, yet modest, goal. We can put a huge dent in Windows’ numbers. What are you waiting for?

Update: apparently someone else shares some of my points of view.

Sound off using the comments area below, or blog about this article directly on your site. I also encourage you to use the Digg button at the beginning of the article — while recognizing that would be preaching to the choir.

I’ve been looking for blog editors lately, and I stumbled upon Gnome Blog and BloGTK for replacements of the sluggish WordPress post interface.

None of them worked for me.

• Gnome Blog is way too simple. I had to hack the source because it insisted that my weblog was under /wordpress on the Web server. Maybe for quick musings, but that’s it. There’s no way to select categories (no, not even a single category). It handles image uploads, but sadly it doesn’t generate thumbnails automatically (a must for me, because I’m used to FilePress). There’s no way to edit old posts.
• BloGTK+ is way too buggy. The interface is okay, but spartan. It does not seem to handle image uploads, nor do thumbnail generation. It does not support more than one category. None of the blog APIs work as advertised. The only one that delivers the full content of my existing articles (the Blogger API) does not deliver neither categories nor post titles. The other ones eat my text… fortunately I never hit the Save button. Plus, the preview pane insists on parsing my UTF-8-encoded text as ISO-8859-1, thus presenting the tilde A uppercase problem.

So, in summary: Seth and Jay, get your act together or turn the projects over to people devoted to blogging.

I disagree.

This approach is used by KDE, with its kded session daemon. I hate it because once one of the mini-daemons fucks up, kded simply goes AWOL, and things start to go awry in the KDE desktop/session. This is only an example of how consolidating multiple daemons in a single process is bad for software quality.

What should be done is constify and make the entire GNOME library stack shareable as much as possible. Then startup cost will be reduced by a factor of N, where N is the number of daemons that are going to be started up. Plus, investing efforts in this direction will benefit the entire GNOME app stack. After all, Linux and other UNIXes are stars in fork-land. Plus, once one daemon is already started, the others don’t even have to hit the disk for the libraries (and won’t have any startup overhead, assuming maximal startup cost reduction).

Even then, lots of programs dynamically link to unneeded libraries, which can be pared down in the autoconf/build process (why should most GNOME daemons endure the FreeType library startup cost?). The autopackage guys have gone a long way in identifying these issues and providing real solutions to this problem.

And one process per daemon means you gain more software reliability and quality.

Here it is: Ikke’s Blog - Good old messaging

Tips for the writer:

• Catching wall messages is actually easy, all you have to do is open a pty like kwrited does, and that makes it possible.
• Of course, catching write messages would actually require that the writer writes to your opened pty directly.
• And catching talk messages wouldn’t be bad nor difficult, if you could keep a lightweight talkd that relayed talk requests to your running Gossip or Gaim instance and used the popup mechanism to announce talk sessions, much like ktalkd does.

So, where do we stand in relation to our competition?

The two big efforts towards OpenGL on our open source desktops.

Indeed, the title of this article is misleading. I’m implying that 3D will be available on the Linux desktop. Nothing could be further from the truth. 3D acceleration is avaiable today. And 3D on the desktop will be available very soon, but not necessarily thanks to the magic of Linux (which, by the way, already does a lot in terms of providing a solid foundation of robustness and stability, thank you very much.).

3D on Linux will come thanks to the efforts behind the X Window System, namely the X.org variant.

As always, open source and free software produce different results, which end up competing on their unique technical merits and differentiators. 3D on the X Window System is no exception. Today, we have two competing efforts, and already one of them has taken advantage of the other’s efforts (albeit in a minor way).

(Word to the wise: these efforts share common ground in the early work of Keith Packard and the X Window System, which was deemed “interesting but too primitive to consider for actual inclusion on production releases”. So, don’t be surprised if I only deal with the more mature efforts in this article.)

Xgl: the first effort, backed by Novell

Novell has several outstanding hackers working for them. And a select team, working nearly in skunkworks fashion, has finished what appears to be the first mature effort to bring 3D graphics to run-of-the-mill desktop computing everywhere. Xgl is the name of the effort.

Xgl has some outstanding merits. I won’t bore you with the technical details, because:

1. they are already on the Xgl Web page, linked from this article
2. the technical details are far outstripped by the amazing videos available from Novell’s Xgl page

Suffice it to say that Xgl incorporates a “composite manager” called compiz. This composite manager is in charge of actually telling the server how to compose the image, based on the applications’ rendered output. To the X server (which, as far as I know, runs as a client of the master X server), the application windows are textures. The composite manager has the ability to transform those textures through OpenGL commands. Thus, amazing (and nearly limitless in breadth and depth) visual effects are possible:

• Wobbly windows
• A desktop that responds entirely like a physical abstraction, with gravity, natural edge resistance, bumpiness, and more
• Natural and artifact-free shadows
• True (partly and fully) transparent windows
• Windows rendered as textures on a cube, sphere or any other curve-based surface

The two main criticisms against Xgl are, nonetheless, issues which are still to be worked out:

1. Certain (important) community contributors are disgusted (to say the least) at the fact that Novell worked on this practically solo, without the constant back-and-forth code sharing and open communication which is taken for granted on every open source project. Novell “just pushed a product when it was nearly done”.
2. The architecture of Xgl is cumbersome to deploy and manage. Well, that might be a bit of an overstatement on my part. But it certainly adds complexity to the whole desktop.

Undaunted by the criticism, Novell plans to ship this on their next Linux releases.

AIGLX: the second effort, backed by the Fedora Project

I’m taking a snippet of text from the Fedora Project wiki to explain what AIGLX is about:

AIGLX is a project that aims to enable GL-accelerated effects on a standard desktop. We have a lightly modified X server (that includes a couple of extensions), an updated Mesa package that adds some new protocol support and a version of metacity with a composite manager. The end result is that you can use GL effects on your desktop with very few changes, the ability to turn it on and off at will, and you don’t have to replace your X server in the process.

The Fedora Project people have gone to great lengths to show that they’ve “played nice with the community”. I suspect this is deliberate — in order to pinpoint at the “flaws” of their “competitor”, they’ve chosen to make the second paragraph on their AIGLX front page about this very discussion subject.

So, knowing that both projects aim to get 3D on Linux desktops, the best way to show what AIGLX is would be to compare it against Xgl:

1. An updated Mesa library which allows for indirect rendering (in accelerated fashion). For those of you who don’t know what Mesa is: it’s a library which implements OpenGL non-accelerated rendering for cards that don’t support 3D, and accelerated rendering for cards that do 3D just fine.
2. An updated Metacity (the GNOME window manager) with a composite manager embedded. This composite manager will be enabled and disabled via a configuration key.
3. An updated X server.

Basically, they’ve chosen to go the “revamp the stack” route. This means no modifications in the way components interact with each other, and no extra components. I did read a few hours ago that writing a composite manager into an existing window manager would be much easier than doing it the other way around. Were this true (I have no way of knowing, never having written a single line of window manager code), the Fedora guys would have a huge head start.

My take on the subject

I personally feel that the Fedora way is better. My limited knowledge of the matter still lets me see that extending the current software stack instead of having to rearrange the way components interact, is a far more workable solution over the long term. Sure, I’m well aware that some features may not be possible at all with the Fedora’s AIGLX arrangement. Rendering on spheres and other curve-based surfaces spring to mind (but I’m sure I’ll be corrected by a member of the community if I’m mistaken, that’s the beauty of open source).

The other big issue comes down to hardware support. The Fedora project seem not to have support for the open source nv driver for NVIDIA cards (though they say the next major release of the closed source driver will work just fine later on). That rules out a whole swath of cards that are out there and ready to be used. The Novell team boasts full accelerated functionality with most major graphic cards.

Conclusions

When there’s an effort, there’s usually criticism. I’d like to rescue a key point here, which seems to have been lost among the petty bickering and discussion. These two projects, however “incompatible” they may be (and, to a certain extent, are fully compatible) are great strides, setting the pace for the future (and mythical) Linux desktop. They’ve already shared, and continue to share code. It’s just a matter of “seeing where the pieces fall”, Tetris-style, on the base X.org distribution. I hope politics doesn’t spoil the natural evolution of events. No, let me correct myself: actually, I’m pretty confident that won’t happen. But it’s important to recognize that these new pieces need to be pushed upstream, to X.org.

Remember that both efforts will be rolled out by major Linux distributions sometime later this year. Rest assured that they won’t arrive at your desktop exactly as you see them in their technology showcases. You’ll see much more refined work. You’ll be able to control whether you want the effects active or not. But you’ll definitely see increased desktop rendering performance, thanks to the 3D acceleration hardware present on all modern video cards.

Bottom line, the X Window System was in dire need of evolution. These efforts have shown that it is possible to evolve. And this evolution couldn’t possibly have come at a better time.

So, where do we stand relative to our competitors? I’d say fairly well. These are exciting times to be involved in these efforts. Go Linux! Go open source! Go Free Software!

Anyways, I really, really hope this gets into everybody’s computers.

QDevBlog » Qt and Glib has the story.

I still disagree. I think the library should implement both a database for the user, and also write the tags out to extended attributes whenever possible.

But they told me no, it ain’t gonna happen this way and here are the reasons, together with my rebuttals:

Users couldn’t tag files they don’t have permissions for

Basically, if the user doesn’t have permission to tag files he can’t modify EAs for, the library should fall back to the user’s tag database. After all, your library already implements the tag database.

Tags must not be system-wide

I disagree with this too. At the very least, users should be able to tag their files system-wide, or per-user.

Moreover, to get per-user tags, you can create an EA namespace for user tags. That would solve this issue.

You couldn’t tag remote resources

Why not? Just fall back to the user’s tag database.

Another problem with using extended attributes for this is that they don’t allow fast queries

That is simply untrue. BeOS’s implementation did a wonderful job disspelling this myth. MacOS X also dispels this myth (although not directly with extended attributes). Fact is, just like you have locate (slocate, mlocate), you can have ealocate as well. Modern kernels now export facilities for live indexing (inotify comes to mind).

If you’re already using a database for queries (and a fall-back for files you don’t have permission to xattr), what’s the point of duplicating the information in xattrs?

The point is, this way, you can integrate tags with standard fileutils and other command-line tools. Can’t anyone see the potential behind this idea?

Would you please make your tagging library store tags as extended attributes on the file system as well? This would enable many applications, from solid backups of tags (pax, gnutar, cpio), to interfacing with command line applications like find, xargs and the entire coreutils suite (which I use all the time, believe me!)

(in response to ChipLog » Blog Archive » Taggable Desktop)

Since merely resorting to an ioctl is not possible, because of permission issues, I’d suggest a standalone command, that runs as root, to do the job. Much like mount.

Think about it: we have a sync command. GNOME could also ship a bflush /dev/some-device-about-to-be-removed command, which doesn’t return until the device has been flushed. Then, gnome-volume-manager could resort to invoking bflush. Plus, bflush itself would take care of checking whether the invoking user has the right to perform a buffer flush on said device. For security, this hypothetical bflush command should not even need to link to GNOME libraries.

That command can be built portably. Later on, at some point, the author could push for its inclusion in one of the standard packages for disk tools. Down the road, it could be standardized as part of LSB or maybe even other POSIX-compliant operating systems.

But the mere suggestion of migrating to Linux, directed at those CIOs, is enough to trigger a bunch of emotional responses on them. “Our users won’t go along”, “We depend too much on Office to make the switch”, “Linux costs more in the end” are common responses.

Today, I’ll be telling the story of our own migration to Linux. As you can probably infer from the title of this story, it’s been a success.

So, where did the story unfold?

These events took place Amauta, a small Ecuadorian start-up focused on Web applications and network service integration for foreign markets. To the day, still own 20% of the company, and I’m proud to say that Amauta has been seeing steady growth, without depending on venture capital to survive. Though I no longer work there, I still keep in touch (four more partners and two full-time employees), because, through the last three years, we’ve endured hard times and we’ve been constantly forced into innovating. These are the kinds of events in a person’s life that bond people together.

And when did Linux enter the story

Right at the beginning. Few people know how we started up.

We actually started up as a college project, for the Applications and Information systems workshops. Two other student groups competed with us in the same course; one even built an application geared straight at competing with ours.

My other four mates (Iván, José, Jaime and Luis Fernando) did know the fact that I had been using Linux almost exclusively since 1997 (though Iván had some personal experiences with Linux himself). So, it was a no-brainer to lobby them for Linux usage right at the beginning of the course. Remember that we, as college students, didn’t exactly have the kinds of resources that an established company has. So we basically set up shop at Jaime’s house, brought our own personal computers in, laid out a few yards of Ethernet wiring, bought a small hub, and connected. Little did I know that my own computer (an old Athlon XP 1500+) would be serving files, documents, and Unreal Tournament games for the rest of the trimester.

The assignment for the course was to build a Web application. Take note: While everyone else in the other two groups was using Macromedia Dreamweaver, Apache and MySQL for Windows (not the best choice, but a good one, discounting the OS foundation they used) to build their applications, we were using my old computer, with Apache and PostgreSQL, to build ours.

Remember — this is a Third-World country. Oracle and Microsoft licenses are out of the question.

So, what’s so innovative about this? Everyone and their dog are using LAMP!

Yes. That’s true. But I took the time to show everyone in my group the power of Linux (which, by the way, was Fedora Core 1 at the time). I made a point of showing them OpenOffice, the K Desktop Environment, GNOME, Valknut (named DCGUI at the time), Konsole and bash. Evidently, no one was particularly excited with bash at the time. That’s, of course, perfectly understandable: with a Windows background, my friends had only known MS-DOS. It’s a perfectly normal human response: you’ve seen one black screen with characters, and you think you’ve seen them all.

During the course of the first two weeks, our entire operation begun to change to open source and free software. We started using MyDMS (a lightweight document management system, which we improved for a customer) as our document management solution. When the other groups were passing documents around by using e-mail, thumb drives and a deficient course management software package (regrettably provided by our own college), we were tracking our progress with MyDMS seamlessly.

We shared our files with SAMBA. The other three computers in our small NOC were still using Windows, so it only made sense. But we worked with a central file share (we’ve since migrated to Subversion for all serious work) and set up Vixie cron to perform nightly snapshots of data and code, and publish our work into production periodically with weex. We also used phpBugTracker to keep tracks of any critters that crept in our work.

Three weeks into the course, my friends were using my computer regularly for work. They’d been using PHPEdit on Windows. While PHPEdit is a fine piece of software, it could never match the power and simplicity of KWrite (included with KDE). For KWrite alone, my friends argued for the use of my computer. Personally, I think KWrite’s killer features are the very usable syntax highlighting, its usability (automatic tabs are a bliss, and the insert cursor seems to be “smart” yet predictable) and its speed.

And did they use the rest of the applications! Once they discovered the power of bash (especially the famous Ctrl+R shortcut) they started saying things like “command line interfaces aren’t so bad” and “Boy it would be good to have bash on Windows”. So I installed Cygnus for Windows on their computers.

They also got to know VMWare Workstation. The marvel of seeing a window onscreen, counting RAM and booting Windows (mainly for KaZaA) was quickly replaced with a few suggestions on how to make productive use of it.

Granted, when I pitched Linux, I met with very little resistance. My friends are all tech-savvy individuals. But I strongly suspect anyone can get used to KDE, or GNOME, or any other typical Linux interface. Of course, changing deeply ingrained habits is hard. But my friends didn’t seem to have a problem with it.

Stability?

During the entire course, my computer went down only once. That was the day when we got together with other friends from college to celebrate a birthday, and we took my computer out to perform for us with XMMS and its crossfading output plugin. XMMS didn’t make it to the stage: the power supply died when we plugged the computer into the living room’s wall socket.

So, either Linux has a power supply-killing ghost in it, or my friend has wiring faults in his house. Since I don’t believe in ghosts, I went to a computer shop and bought myself a new case and an APC Back-UPS ES. After that, everything was back to normal.

OK, that was fine for a college project. What’s that got to do with serious work?

Once we finished our college project, we poured our savings (really, not a lot of money) into the company, and set up shop in a small office behind Luis Fernando’s house.

Around the time, we begun looking for new computers to buy and install in our office. Since I had known and successfully installed LTSP before, I suggested we went along that route, testing network boot and regular with our own computers first. That was a success. They were already used to the gorgeous GDM login screen, and by the time, everyone had settled on their favorite desktop (Amauta is mostly a KDE shop nowadays, though two of us, who are Ubuntu fans, use GNOME). Again, being able to power off a terminal, and having the login screen up in less than 20 seconds from power-on were great selling points. Plus, the simple fact that everyone else’s information was centralized made us be more nimble. No longer were we depending on a particular computer because it had X or Y application or Z files. Log on to any computer, everything’s there for you — exactly how you left it when you logged off.

We started to use Subversion for our projects. Software engineering is extremely dependent on technologies which automate repetitive tasks: when you’re building something, there’s literally no time to think of the small details — those have to be handled by software, or else you lose your concentration. Subversion was a boon: we started working on individual “jail” development environments, partially thanks to the configurability of Apache, so quality went up. Through Subversion, we also started tracking every modification of our assets. To this day, Subversion continues to be the most valuable tool in our toolset. Mind you, everyone uses the svn command-line tool, because everyone agrees it’s much faster than dealing with a GUI. Of course, when you need some visual help, there’s always eSVN.

We also begun a full migration to OpenOffice. Since we own two ThinkPads, and one of them has Windows (for those times when you’re visiting a customer and you really need Windows so he/she won’t freak out), we downloaded and installed OpenOffice for Windows on that computer. Big download, sluggish package. But it’s still better than the non-free alternative.

But the big productivity increase came from an unexpected open source gift. VNC. Virtual Network Computing turned out to be the best thing since sliced bread. Before VNC, everyone came in, logged in, worked, then logged off and went home. As you probably know, when you log off GNOME or KDE, most applications save their state, but a few don’t. So, it’s sort of painful to return to your office, endure a few seconds of login time, then prepare your desktop for work. VNC changed all that.

Now, everyone has their own private session and VNC port, open all the time in the background, and when they arrive to the office, a login to GDM with the “VNC client” session selected (which is a small shell script) is enough to start working again. Plus, we can do everything remotely. For routine work, there’s no need to be physically at the office: Evolution, Subversion and aKregator are a few keystrokes away, whether you’re at home via dial-up, or at a customer site with an always-on Internet connection. Even our CEO, which uses the Windows computer, also uses VNC — wait, that’s an understatement! Most of the time, he does use Windows, for only one thing: starting up the RealVNC client, fullscreen mode enabled, and working directly with his session at the server.

This is a screenshot of my VNC session, two weeks after it was up and running

We tend to manage our servers remotely with OpenSSH. Webmin has its uses, but for most work, SSH is plenty powerful. Being able to tunnel GUI applications through SSH has also come in handy. Being able to remotely invoke commands in a scripted fashion is also great: directly piping the contents of a local database or a tarball into a Web hosting server is probably the most fabulous use of this. Plus, the added security of SSH and SCP lets us tell our customers that their information will remain secure at all times.

But, at some point, you have to upgrade

Well, I’m getting sidetracked here. We couldn’t continue working with our personal computers anymore (being a software engineer and not having a computer at home is kind of ironic). So we went to an used computer store, bought six used computers, six new IBM 17″ monitors, threw away their hard disks, and flashed their BIOS so they’d boot with Etherboot. Total bill: under $1000, keyboards and optical mice included. Yes, you read it right: we got six Pentium II class terminals, which we use for serious engineering work as terminals, for under a thousand dollars.

We also had an ASUS K8V motherboard shipped in, and an Athlon 64 3200+, which we used to build a server more suited to our needs. The server ended up costing more than the six terminals together. After overcoming a few hardware issues, the server has been working straight for more than one year now (except for power failures). The UPS is still on the shopping list. But we aren’t too worried for our data: an rsync script, started nightly by Vixie cron, moves everything that’s new into an external USB enclosure, with an 80 GB drive (which also houses our music collection).

But what about your personal computer?

You’d think it retired after years of labor. No, it didn’t. It still works, at home. It’s been upgraded, of course: there’s 768 MB of RAM in it now. And a $20 TV card, which, combined with MythTV, has freed me from TV commercials. Plus, amaroK and Joystick control let me enjoy music, without even turning the monitor on.

There are lessons to be learned here

No one can tell you that a business cannot be based on open source, and open source alone. Free and open source software is our bread and butter. I, for the love of God, will never understand why another company would knowingly give up the cost savings and productivity advantages of open source, to stay with Windows and assorted closed source software. I may understand that from someone who hasn’t “seen the light”. But, after seeing the possibilities that open source creates, turning away from that is short of irresponsible.

I know for a fact that “learning Linux” has been good for all of us. We are more knowledgeable know. Everyone in our company has boosted their troubleshooting skills and practical knowledge, to the point that our CEO himself is capable of diagnosing anything from a malfunctioning network gateway to securing a server using Linux iptables. Our marketing and sales head is knowledgeable with Linux and uses it at home, where he sporadically sustains conversations with his wife, a stauch Microsoft supporter and Microsoft-using programmer. Oh, I nearly forgot: right now, he’s actually near the Microsoft campus right now, taking a well-deserved vacation. Just yesterday, he was joking about him unfortunately not being as huge as the penguin from the Penguin Computing advert (remember it? Hello, Mr. Gates… I’ll be your server today). Two of our partners even used an open source topic as the foundation for their thesis work.

I know for a fact that it’s possible to run a business entirely out of free software. I know for a fact, that it has enabled us to exist and make good money. I know for a fact that it has enabled us to compete against companies ten times our size, and win.

And after having worked like that for more than two years, I will never go back.

Please don’t remove them.