Tag Archives: gnu/linux

Simple multiuser chat for POSIX systems

Here’s a little multiuser chat server written for various POSIX-compatible operating systems. Written and tested on Mac OS X 10.6, but it should work on your favorite Linux, too.

Placed in public domain, use it for whatever you want (since it’s so simple). 177 lines of pure C powah, dood.

Code follows after the break.
Continue reading

Is there a growing interest in GLDM?

Google Analytics says I’ve recently been getting some hits from Google with keywords “gldm login”. GLDM is my login manager which I left in a half-finished state last year; it’s free/libre/opensource software and can be picked up at http://sf.net/projects/gldm/. If you’d like to help, talk to me at gldm+blogpost@vucica.net.

What is GLDM?

Idea behind GLDM was to provide a solid backend for authentication with a well-designed API for dropping in custom-developed graphical themes. That is, the idea was that GLDM would be the backend (with some nice themes/theming engines coming with it), but that people would easily be able to develop their own theming engines. It’s supposed to be an alternative to XDM, GDM and KDM — that is, it’s a login screen for Linux.

Its target is a home user; thus, GLDM does not care for and does not suppot stuff like XDMCP. It’s also probably a little bit less secure, until someone security-conscious comes around and fixes that.

Acronym stands for Graphical Liberty Display Manager, to say that one is able to create the GUI with whatever technique that person wants, as long as it’s somewhat pluggable into the C++ code. It’s also a play on OpenGL Display Manager, but since I didn’t code a single theme that uses OpenGL, it would be a bit of a misnomer, especially since it was intended that you really don’t need to have anything to do with OpenGL.

At the same time, you could; one might design a beautiful 3D island, with ocean having reflection, refraction and other cool shader-based effects. Then, on top of that, adding flying letters or user icons during login, which are reflected in the water below.

In essence, GLDM should be a “Compiz for the login screen”!

Almost all “common home users” would love that; it might help convert people to GNU/Linux, or other UNIX based systems. Who knows — perhaps even Canonical would take GLDM as the default login manager. (Oh, human dream…)

So what if you are getting hits? What do we care?

It surprises me that this unfinished piece of software is getting my poor little blog some hits. It surprises me that it’s getting hits straight from Google. It surprises me that this is happening despite absolutely no chatter on the interwebs about this software. It surprises me that I’ve received no inquiries about it.

It confuses me about what I should do next: should I go back to developing GLDM a little bit (a bit troublesome since I’m a Mac user now)? Will interest go up? Is this perhaps just a Google having a glitch, a cough, giving me hope where there is none?

I’m really not sure. Well, I think it GLDM might still be resumed; there still isn’t a “Compiz for the login screen”, and the barrier to entry for potential theme developers might still be significant. GLDM could be the solution by offering simple, simple API for authentication, while allowing the developer to just plug in their existing code into GLDM to get authentication services.

Apache 403 — one cause on Mac (and other Unixes)

Things suddenly broke, without installing web-server-related stuff, without touching apache config?

It’s probably permissions.
No really, you checked out permissions, and it looks ok. Really, “Sites” (or “public_html”) looks ok. However, the entire path needs to be fixed.

Check if each directory in full path to the file you want to serve contains at least executable permission for the web group, or “other” group. That is, on Mac this helped me:

chmod o+x /Users
chmod o+x /Users/ivucica
chmod 755 /Users/ivucica/Sites

What went wrong for me? I suspect Mac OS X 10.6’s disk check, or perhaps one other disk utility I recently used, messed up the executable permission flag of /Users/ivucica. I have no other explanation.

This tip would probably help under GNU/Linux too.

Getting GNU/Linux to reboot properly on unibody Macbook from late 2009 (Macbook 6,1)

To get a GNU/Linux to reboot properly and not hang in the final step, you need to pass another parameter to the kernel. You need to pass reboot=pci to Linux.

Currently, Debian and Debian-derivatives such as Ubuntu tend to use Grub2 as the bootloader, by default. You need to:

  • edit the /etc/default/grub configuration file, as root, and using your favorite editor
  • find line that looks similar to GRUB_CMDLINE_LINUX=””
  • if it contained anything inside quotes, don’t delete those commands!
  • into the quotes, add reboot=pci but do not delete existing text
  • back in command line, run update-grub as root user

It should now work flawlessly!

Image: unplgdd.com

GNOME's disk usage analyzer Baobab in Debian

In case you’re looking for GNOME’s graphical equivalent of “du” command which provides a tree overview of disk usage of each directory, and you are a Debian user, know that program Baobab is located in package gnome-utils.

Checking out webkit without test cases

So you want to check out webkit to do some hacking. If you already tried this, you know that the test cases folder is enormous.

Not enormous solely by its size (which may be somewhat tolerable), but by amount of files in there. That’s absolutely preposterous. I think that the ratio when I last canceled the checkout was something like 15mb of content versus 75mb of disk space usage. I think I used FAT back then. That means 60mb went just to store information about files. (These sizes of course do not ignore the duplicates in the .svn folders.)

It’s completely irresponsible that someone put those in the project root, where nearly all the subfolders are essential except those test cases.

So if we just want to try out stuff and play around without running test cases ourselves, we don’t want to check out this enormous folder and get stuck on this for half an hour, an hour, two or even more. Here comes svn’s –depth parameter. UPDATE: Note! You will want to double-check that when you copy paste the command line from this site, there is actually two dashes before “depth”. I’ve noticed that during copy-paste, they were replaced by a single line.

$ svn co http://svn.webkit.org/repository/webkit/trunk webkit --depth immediates
$ cd webkit
$ for i in `ls -d */ | sed 's/\///g' | grep -v Tests`; do cd "$i" ; svn update --set-depth infinity; cd .. ; done

  1. So, we checkout only immediate children-files for webkit and put them in webkit subdirectory. 
  2. Then we list only directories, (ls -d */) and remove all the appended slashes (sed ‘s/\///g’). We have one directory per line now. Finally we get only lines that do NOT include word Tests (grep -v Tests).
  3. Finally, we enter each directory, and tell svn to update, but now with infinite depth.
That’s it! You should now have a Webkit working copy.
Tested on Mac OS X 10.6 Snow Leopard, with Webkit revision 52487. YMMV, but I think this should work on any Unix including GNU/Linux. You can probably pull this off on Windows using Cygwin or even msys.

Updated on Aug 22 2012, primarily to update formatting.