Got a new DVD recorder

I've got a BenQ DW1620 (dunno if it's the Pro model or not), that is, a double-layer, dual DVD recorder as a Christmas present. This is the first first-hand recorder I get; I didn't trust the older ones very much, so I'm quite happy ;-)

First of all, I was impressed by its price, very low according to all the features included. WRT the packaging, it is nice (got the retail version in a superstore). As a side note, it has got a successful review in an article published by PC Actual (not that I knew about it while buying the recorder, though); if you search Google you will find some more.

Anyway, after installation, I tried to blank some CD-RWs and record stuff onto them. All fine, and with great recording speeds. But well, it's a DVD recorder, thus I felt the need to write something to a DVD... so I got a DVD-RW I had around, made by Sentinel, and tried to blank it with dvd+rw-format -blank /dev/rcd0d. Result: error. At first I thought that this could be NetBSD's fault. To verify this, I rebooted into Linux, tried a similar command, and got exactly the same error. Hmm... strange. So went to Windows XP and tried again... which resulted in "invalid media". Uh, huh.

The next step has been to update the firmware, hoping that the drive could write to those disks afterward (read has worked fine all the time). But they still don't work. Unfortunately I don't have any other DVD-RW to try (will buy some more soon), just to make sure the recorder works properly. Even though, I think it's just that it doesn't like this strange brand (something outlined in one of the reviews I read), so I don't care much.

At last, I have recorded some videos I had around into two DVD-Rs. Everything went perfectly. So I can start dumping more hard disk contents into DVDs, otherwise I'll get ENOSPC soon ;)

And BTW, although late, merry Christmas!

Giving blood

This week, a medical team from Hospital Clínic has come to our faculty to collect blood from the students (or any other person around) who want to donate. I had never done it before, but due to a suggestion from a friend, I though "Hmm, why not? Let's try it.".

So I showed up there this morning. First of all, I had to fill in a form answering some questions about things that may make my blood inappropriate. Secondly, a nurse pricked my finger to see which blood group I have and also measured my tension. Then, I simply went inside another room, laid on a stretcher and waited while 450g of my blood were extracted. Afterward, I was offered drinks and food to eat... a lot (this was the best part ;).

After all, a nice experience. I think I will repeat it: I loose nothing (well, just an hour of time) and I might be saving a life! So, suggestion: go to give blood if you can.

Setting up a bridge

A bridge is a machine that connects two different physical networks (like a switch). I've just set up my box to act as a bridge between my Mac (connected to the ne0 interface) and my home network (connected to the vr0 interface).

It has been easy as hell due to the excellent quality of the NetBSD manual pages ;-) After reading bridge(4), I saw a reference to brconfig(8), which I read too. And, fortunately, there is a simple but useful example in it.

So, I started by rebuilding my kernel to add pseudo-device bridge and created /etc/ifconfig.bridge0 with the following lines in it:

create
!brconfig $int add vr0 add ne0 up

After a reboot, the bridge was just working :-) The Mac now has transparent access to my home network, something that didn't happen before when I used two different subnets. For example, it now has access to the DHCP server and there is no need to add an extra route anywhere.

OpenPAM hits NetBSD

After a very long time of discussions and waiting, OpenPAM is being merged into NetBSD, as you can see in the src/dist/openpam directory.

OpenPAM is a BSD-licensed PAM (Pluggable Authentication Modules) implementation, which focuses on simplicity, correctness and cleanliness (according to its website). It has the best features of Solaris PAM, XSSO and Linux PAM, plus improvements of its own. This software was originally developed for the FreeBSD operating system, but is portable to other BSDs as well as Linux.

But... which are the discussions I mentioned above? Every time someone proposed the integration of PAM into NetBSD, a flame was started: some people wanted PAM, others wanted BSD Auth (sorry, couldn't find a link) and a few preferred neither of them. These arguments lead nowhere. But, at last, consensus was reached and PAM is the choice!

Note that ATM, the build of OpenPAM is disabled. It has been imported into the tree to let other developers help in its integration and to ease cooperation. This has been done by Christos Zoulas, who will continue its work in this area. I expect it will be fully working in a few weeks :)

But why having PAM in the base system is so important? After all, it has been available for ages in pkgsrc. The reason is that if it is in the base system, all other parts of it can take profit of this security framework; for example, login or passwd. And this is a great improvement in the security area.

Windows and CHS

OMG, what a stressful night. Yesterday evening, I went to a teaching academy to install Linux (Ubuntu was the distribution of choice) on all their 12 boxes. I started by resizing the FAT32 partitions, continuing with the Linux installation. (Stupid me because I did no test in the middle.) After two hours and a half, I had all the machines up and running, and I was surprised to not have had any problem.

But I was completely wrong. I rebooted one of the machines to check the network setup in Windows... and it couldn't boot! No error messages, no disk activity... nothing. Ugggh... I started trying everything I could imagine: fixmbr and fixboot from the recovery console, chkdsk /p, restoring ntldr and ntdetect.com from the installation CD... without no improvements at all.

After an hour and a half of tests, the academy had to close, so I had to go home... extremely worried because they had class this morning and needed the computers. At home I started doing tests on my own box: resizing the partition (which didn't break the system), using a boot disk, installing Windows in "recovery mode" to see if it could be useful to solve the problem...

I had some hope in thinking that a boot disk could help, but this morning it has proved to be useless. But luckily, I found the solution after reading some pages in Internet that talked about similar problems. The BIOS was set up to automatically detect hard disks and, for some strange reason, they were detected as CHS. I manually switched them to LBA and... voila! The systems started working again without no problems.

Now I wonder why the hell they could boot before all the changes in CHS mode, but not after. Anyway, I'm now a bit more calm, but this has really been a very bad experience :-/

Latest releases and news

These days, I'm very busy working with a friend in a game which we have to have "finished" by next Friday (it's university work). Basically, it is a three-dimensional Pacman with multi-player support, licensed under the GPL and written in C++. It will be released on Sourceforge.net in a while, so keep tuned ;) Anyway, the purpose of this message is to publish some recent news, as I had no time during the week to do so:

On Wednesday 8th, The GNOME Project released the 2.8.2 version of its desktop environment (including the developer platform and the bindings). This is the continuation of the stable 2.8 branch, including a large number of bug fixes and minor improvements. Check the list of changes for more information.

ATM, pkgsrc's code-base is freezed in order to prepare the next stable branch, pkgsrc-2004Q4. The freeze will last for at most two weeks, so GNOME 2.8.2 will not be integrated until it finishes (and, anyway, I don't have time to do The Big Update (TM) right now :-/).

And, to finish this post... on Wednesday 9th, we, The NetBSD Project, released NetBSD 2.0! Wohooo! You should get this new release right now! Featuring native kernel-level threads, kqueue, SMP (on amd64, i386, macppc, sparc...), systrace, verified exec, GCC 3.3.3, XFree86 4.4.0, support for new platforms, innumerable bug fixes and many, many more things that you'll have to discover by yourself. Give a try to this free and fantastic operating system! ;-) </hype>

Variable names in Makefiles

I've found many hand-made Makefiles that are very hard to read and modify; the reason: they use strange variable names to handle the compilation and linking of programs.

In case you don't know, there is a de facto standard in Makefile variable names when it comes to calling to the compiler. Here they are:

• CC: Path to the C compiler. Sometimes set to cc or gcc. Never hardcode this to an absolute path, unless the value is being filled by the configure script.
• CXX: Path to the C++ compiler. Sometimes set to c++ or g++. Follow the same rules as in the CC variable.
• CPPFLAGS: Flags to be passed to the C/C++ preprocessor. More specifically, this contains all -D and -I flags.
• CFLAGS: Flags to be passed to the C compiler. For example, -g, -Wall, etc. This does not include any of -D nor -I.
• CXXFLAGS: Flags to be passed to the C++ compiler. Similar to CFLAGS.
• LDFLAGS: Flags to be passed to the linker, except libraries. I.e., it can include -L or rpath flags.
• LIBS: Libraries to link to. Usually in the form of -l flags.

Once you have all these variables set, there are some very simple rules to use them. Whenever you have to compile a C source file into an object, use the following form: $(CC) $(CPPFLAGS) $(CFLAGS) -o name.o -c name.c, and similary for C++ sources.

And when you have to link multiple objects into a single executable, use a call like: $(CC) $(LDFLAGS) -o name name1.o name2.o $(LIBS). Here you can see why libraries are not included in LDFLAGS.

Lastly, if you don't mind relying on the += operator, always use it to extend the value of all *FLAGS variables, so that the user can easily provide his own values in the environment.

Edit (December 11th): Corrected a variable name: CCFLAGS ought to be CFLAGS.

Cederrón

Did you know that cederrón is a correct word in Spanish, i.e., accepted by the RAE? Oh God, I couldn't believe it the first time I noticed this.

Why? Just consider that cederrón comes from an incorrect pronunciation of the CD-ROM acronym. I might like it if it was written with an "m", but not with an "n". Do you imagine ceedeerron being an English word? How ugly.

I'm also worried about the word encriptar, which does not exist in Spanish, but is used to refer to the English encrypt term. If encriptar was a real word, it could mean "to put something inside a crypt", more or less. But... as lots of people use it in speaking (and even writing!), one can expect that it will become an accepted word. However, be aware that we already have cifrar to refer to encrypt... so why not use it?

Buildtool status

Hmm, Buildtool... one of my pet projects, probably the one on which I've spent the most time working... and it was even starting to get some (few) popularity lately

But I must admit it. The code is, in its actual form, dead :-( It's unmanageable (shell scripting doesn't scale, you know) and breaks in many, many places. Just consider the following facts:

• Detection of C++ features from bt_config fails in many cases.
• bt_logic's behavior is less than acceptable, and adding functionality to it is a PITA.
• Several modules haven't been modified across versions, so they don't work properly. For example, bt_lint is almost useless.
• Shared library handling is broken in many systems, and fixing it could be very difficult.
• The code exposes internals too much, specially in environmental variables and C/C++ defines. But cleaning that up is also complex due to the nature of shell scripts.
• I was suggested recently to make bt_dist only include in tarballs what was really needed, and not everything (just like GNU Automake's make dist does. I like the suggestion, but implementing correctly is impossible due to the current code.

... plus a large etcetera. All in all, too many problems that can't be solved without doing very gross hacks or restarting the project from scratch. This is why I haven't touched the code since the beginning of the summer.

But... you know what? For some reason, I'm willing to rewrite it from scratch. Of course, using a real programming language. The choices I have in mind are ("obviously" ;-):

• C++: I really like C++, together with the STL. Yes, believe me! It simplifies programming a lot, and OOP is wonderful. But I'm a bit afraid of portability. If I use this, it must follow the ANSI standard (not doing so could be silly), which means that users will need a compiler that follows the standard, such as GNU GCC. This is not a big problem, since GCC compiles almost anywhere, but may add problems to end users. However, by the time the program is usable, the situation may have improved a lot, hehe.
• C: Very portable, assuming you know where the portability problems arise (not a big problem for me). But what really bothers me is that it slows down development a lot: I'd have to create my own classes to handle containers (hash tables, linked lists, etc.) and handle dynamic memory even for trivial tasks. I'd also loose polymorphism, inheritance, exceptions... Ok, ok, GNOME emulates OOP in C, but I'm not too keen on that.

If I can't find any strong reason not to use C++, I'll stick to it. In fact, I've already written a bit of code (program detection) and it has been easy :-)

Oh, I listen, "How could build scripts be?". Well, I have XML in mind - something similar to Apache Ant. Otherwise I'll have to invent and write a parser for a custom language (ew, not funny). But that's something yet to decide.