Debian on my desktop
As I said in my last entry, although I've had a Debian on my home LAN for a while, I switched from Windows to Debian for my desktop recently because among other things Debian had better support for my Linksys 802.11b USB wireless adapter. I have learned and realized a lot of things in a short time. This will probably be a long entry.
One general thing I am unhappy with is I just want things to work without much of a hassle like they do on Windows (sometimes, some things, like the Linksys, or not needing the crappy Windows/OEM CD's to "repair" or "reinstall" are more superior on (Debian) GNU/Linux than Windows. But a lot of things just work with Windows easily that don't on Linux, which is a little bit of a hassle.
What I'm thinking of right now is support for my old 3dfx Voodoo 3 graphics card so that I can get more than 1 frames per second in Tux Racer, but that's one I haven't completely tackled yet. I do know it will take me a while to figure out whether the 2.4 kernel supports 3dfx cards decently (or whether I can get the drivers somewhere to do so), and to implement it if I can. In Windows these things just work without so much hassle. Well, that's one I have only started looking at, let me go over things I have looked at.
I am really more of a Solaris person than a Linux person, so I have not done millions of kernel compiles like some Linux people. Thus, every time I have been changed .config, I've been recompiling the entire kernel, although it occurred to me recently I could just do an "M" in stead of "Y" and just add new features as modules. Actually, modules were causing me headaches when I was first trying to get my 802.11b working with Debian (I was attempting to use the horrible atmelwlandriver in stead of the beautiful at76c503a driver), so that kind of turned me off to modules for a little while. It's kind of like chess where some bad experience sets off Pavlovian bells in the head when considering certain moves.
So anyhow, I've been recompiling the kernel for every small change instead of building modules, but that's how it is, I'll probably be doing the module thing more in the future I prefer make xconfig to the other makes, especially the very helpful help button which pops up (menuconfig has this as well, although it doesn't pop up of course). Actually in my opinion, I can use even more user-friendliness than make xconfig, maybe something that looks through my dmesg or something and compiles based on that somewhat automagically? I keep getting SMP in my kernel automatically, which I don't need, yet I had to instruct the config to put a filesystem in for my internal DVD drive, not to mention the USB (and SCSI) stuff I needed to put in (none of my devices being supported within the kernel, I used outside modules for all if them). So the most advanced config that comes with the kernel installs by default an SMP which I don't need, yet is blind to the need of my DVD's player need for the UDF filesystem.
Which brings me to "make xconfig"...ok, I have been using Linux on and off since before 1.0 was released, although anyone reading this obviously is aware I am not a hardcore user. But if these things bug, or worse, confuse me, imagine what it will do for Joe Linux Desktop User or even junior sysadmins (or even senior sysadmins, for some of the kludgier Linux problems). Anyhow, I run "make xconfig" the first time and I forget what the hell the error message that was spit out all those days ago was. Eventually I realize I need Tcl/TK and apt-get install them. OK after doing that, let me show you what it said after I ran "make xconfig" for a second try at it:
Application initialization failed: no display name and no $DISPLAY environment variable
Error in startup script: invalid command name "button"
while executing
"button .ref"
(file "scripts/kconfig.tk" line 51)
make: *** [xconfig] Error 1
intron:/usr/src/linux#
OK, now what is Joe User who is trying to get his DVD player to work thinking right now, after by some miracle he correctly figured out to apt-get install tcl/tk from whatever the hell make xconfig spit out prior to this? OK, so what do I do now? "DISPLAY=0:0 ; export DISPLAY" of course. Let's try it again (I have trimmed the error message for space considerations:
Application initialization failed: couldn't connect to display "0:0"
Huh? This has worked for me in various situations for the past decade or so. At this point I have to go to Google. I learn for some reason I have to do "DISPLAY=:0 ; export DISPLAY" because for some reason the first 0 which I have been putting there for a decade in various UNIX and X environments now won't work. Fine, I go back and make xconfig again. (errors trimmed)
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
So I open up another user and type "xhost +" (come on in, boys), try it again and Calloo! Callay! xconfig pops up.
Now you can have two perspectives on this: 1) I am an idiot because I don't fully understand (or remember) the entire X protocol and why I have to remove that 0 nowadays or 2) Even someone with as much UNIX and sysadmin experience as me still had to go to Google to learn that this wouldn't work without me removing the first zero in "DISPLAY=0:0 ; export DISPLAY", never mind needing to know enough to apt-get install TCL/TK, or that a root X window needs an xhost command (as the normal user) and that sort of thing. Windows Control Panel it is not.
This is not the main thing that bugged me, just of one of the many small things that did. I borrowed an HP printer/scanner recently, and went out and get the drivers (the freedom of which I'm not sure, I may have sinned against my Debian system). Anyhow, I set it up with the HP drivers, get printing working, get SANE (a scanner interface), and get that working. Then I come back in a few days and scanning isn't working. Eventually I realize that I have to run "/etc/init.d/hplip start" manually and then xsane will recognize the scanner and I can scan, I guess I forgot this, or it had started on installation last time or something. Did I mention xsane's penchant for crashing after every third scan with a segmentation fault? And that all the GPL OCR programs suck (I guess this is true on Windows as well though, I wonder if the commercial packages for Linux are decent)?
OK now to my DVD (and CD) player. As I said before, kernel default configuration gives me SMP support I don't need, but misses the fact that my dmesg sees I have a DVD player. Anyhow, I compiled a kernel with UDF. I forget if I had iso9660 in my initial kernel or not, it's turned on now anyhow. I never really thought about audio CD's in my CD/DVD player, the first time I put it in without thinking I tried to mount my audio CD as an ISO9660 mount. I went to Google and saw cdplay would play my CD's. I'm not really sure how this works in Linux - on Windows my Winamp automagically plays CDs and MP3s, right now I have XMMS playing mp3's and am using cdplay to play my audio CDs. I've asked XMMS to "play" /dev files in stead of mp3s but it has not complied. Well, the less convenient XMMS/cdplay split *works* even though Windows was better in this respect, and I have bigger fish to fry (getting more than 1 frame per second for my tux racer) that this goes to the bottom of my list - mp3s can play, audio CDs can play, once I get graphics, my zip drive and so forth working, then I can go back and bother to look to see if xmms can play audio cds or if some other package does.
Oh another thing. Debian was launching into GNOME when GNOME was not working initially. I would boot up, gdm would launch, I'd get the selector, but nothing would work - not even the x-term. Very, very annoying. I don't even remember what I did, I think I went into emergency boot mode on my install CD, and linked my gdm init.d script to /dev/null ot something like that. When I was ready to deal with GNOME and GDM I installed apt-get installed x-term, so I could escape from GDM, and eventually got GNOME working.
I have been getting educated on GNOME recent developments (or non-developments more like it). My first indication of how far behind woody is was when I was trying to install the stuff to get my H-P to work. Debian Woody used Python 2.1.3, which was released almost three years ago. H-P wanted something a little more modern, like 2.2 at least. I had no idea how wacked Debian's releases had become when I installed it. I'm not even sure how much of a problem it is, I'm happy with sarge ("testing"), I just wish Debian would be more forthcoming about what is very obviously a problem on it's web page. It's front page says "Getting Started - The latest stable release of Debian is 3.0. The last update to this release was made on January 1st, 2005." Which is a link. Which links me to how to download woody. The page does say "Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002." which perhaps should have set off alarm bells, but as the front page had had the date 1/1/05 as the last update, I had assumed some kind of Debian stable "base" was from 2002, and that things like post-2.1 python would be in the updates, I didn't know the updates were just security patches and that sort of thing.
Which brings me to the general Debian craziness. Honestly, I am very happy with their position regarding free software, although one can reach a point where one is too zealous - I understand some people want to remove the choice of non-free , which I think is ridiculous. Theodore Tso has talked about splitting Debian, I think what should happen is the 100% purist zealous Debian developers should hopefully continue to contribute to Debian, but also start their own kernel, a completely pure and free kernel "Free Debian" or something like that. Debian needs to navigate between the Scylla of needing to be a "mass movement" and Charybdis of needing to be and promote free software. It needs to be *both* and I hope it can be both, although at certain points it will have to give up users to remain free, and at certain points it will have to make some compromises so it doesn't become an OS no one uses except a handful of die-hards.
I don't want to go too hard on Lunar Knight free software zealots. I'm glad they exist and that *they* do not run a system that tuns unfree software. It gives me great satisfaction knowing Richard Stallman will not run non-free software on his machine. For myself, I want to run free software whenever possible. And I like knowing when the software I'm running, the drivers I'm running and so forth are not free. But I want to have the option, the choice of running them. I run blackdown on my Debian, not Kaffe. When Kaffe is in decent shape, I'll run Kaffe. If I could program better, I would contribute to Kaffe
Gnutizen
Which brings me to my project, Gnutizen. For some reason, although it worked well on my other Debian machine, and my Windows machine, now it is breaking all the time. I also just realized I haven't been doing mutex locking on global variables. I guess those bugs are just popping up now for whatever reason. Blimey! Gnutizen is written in C, it is a peer-to-peer application running on the Gnutella protocol which (used to) compile on Linux and Windows (as well as at times past FreeBSD, OpenBSD and Solaris). I am not a good C programmer, especially considering I have spent the past year mostly fixing bugs in the program (doing the minimal possible to keep up with the evolving Gnutella protocol). I can connect to the Gnutella network (initial bootstrapping is very manual, although now that I have leaf support somewhat, it is better), search and download. Or I could when the program didn't crash as often on my last Linux, before the mutex locking bugs showed up on my new system.
Fixing bugs mostly for a year, doing the minimum to keep up with the evolving protocol and so forth is not fun. And now all this thread locking stuff. I would rewrite it all, but my C skill is so poor I don't know if I should do so.
In chess, when two grandmasters play a game, other grandmasters go over the game and note brilliant moves, mistakes and so forth in the game. Grandmasters will never go over my games like that (maybe if I go to the Village and beg them some would), just as great coders will not be going over my current code and telling me what I'm doing wrong (unless I beg them). But is there anything out there that exists like that on the web? There really should be. Like "OK, we're going to take a look at less 2.90 - what it does right, what it does wrong etc." I suppose what I'm looking for is code that is super-commented and meant for someone who doesn't know C that well (as in - we put extern here because so-and-so, we have this in a header file in stead of the c file because of so-and-so.
I suppose what I have to do is just look at well-coded C packages, not that large, well-used and well-coded, just look at them, take advice from people like Linus like "functions should be short" (something I initially had a problem with) and then just sink or swim. I went to NANOG a number of years ago and was impressed, well a number of people impressed me, and Van Jacobson was certainly one of them. So when I first started coding my big C package, I said, I'll use traceroute.c as a guide of sorts, since it is networking code, and because Van Jacobson is a god, I mean he wrote traceroute for heaven's sake (along with TCP/IP header compression and a lot of other stuff). So when I had settled on using traceroute.c as a guide, here is what Van Jacobson somehow had the foresight to
tell me:
/*
[...]
* Don't use this as a coding example. I was trying to find a
* routing problem and this code sort-of popped out after 48 hours
* without sleep. I was amazed it ever compiled, much less ran.
[...]
*/
I'm sure he meant that in a flip manner, and I'm sure code he pops out after 48 hours without sleep is better than my best code, but it's funny how he put a warning in the code 15 years ago to not use it as a coding example, when that was exactly what I was going to do. Then again, if you listen to the old-timers, they all say that a lot of the code we use and assume it does weird things for a good reason, actually has things implemented in an odd way because it was written on a PDP or something like that.
Anyway, if anyone has any ideas on how I (or anyone) can improve their C skill, let me know. I guess practice is one way - in retrospect I now realize the decision to add threading was a major one (although I just copied gnut, a model for gnutizen, in that decision, although of course, they locked their mutexes for global variables). I don't even know what the hell gtk-gnutella does, someone on #gtk-gnutella says they use "magic()". I would love to contribute to GTK-Gnutella and perhaps learn from better programmers in the process, but I think my ability is not up to their standards.
Anyhow, I definitely am a believer in do it yourself, sink or swim learning for things like learning C and programming an application, but helpful pointers from smarter people once in a while saves me a lot of time and frustration. People on IRC have been really helpful, actually. I try not to be *too* bothersome.
Anyhow, I know enough C to write a program that connects to Gnutella and can download a file (borrowing a lot of the command-line interface from the GPL'd gnut, as well as some other minor things). I also think I made some good design decisions, like trying to be cross-compatible, and trying to allow flexibility for the UI. But my code has been very buggy, which is no fun, so if anyone knows of any good things on the web on how to program C better, or good examples of C programming (of a reasonable size - Linux and emacs are huge), perhaps you can respond here. I bought The Art of Computer Programming, which is very math heavy, dense and concentrates on assembler. It seems very hardcore to me, and I hope to read through all three of the published books at some point, perhaps something not as intense as that. Like Linus's coding style where he talks about how he feels about comments, variables, functions and so forth. Or I've read Bram Cohen's articles here on some of his ideas. Good example programs are appreciated, as well as articles with advice that addresses the whole shebang, not just how a function should work and so forth.