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
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.
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.
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:
It should now work flawlessly!
Image: unplgdd.com
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.
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
Updated on Aug 22 2012, primarily to update formatting.