• Delta modulation

    In a previous post, I outlined how the Pulse Code Modulation (PCM) works (it was not the aim of the article, but it contains this information). Let's now see another modulation technique used for voice signals, the Delta Modulation (DM).The DM codifies each signal sample using a single bit, which is determined from the previous sample's value and the current one. The bit specifies whether the new sample is higher than the previous one, hence only describing the variation in the information (and not its contents). The resulting set of bits can be drawn as a staircase that approximates to the original signal, being 1 a rise of the stair and a 0 a descent of it.Remember that the number of samples per second is determined by the Nyquist theorem.For example, consider a standard 4KHz voice channel. You need to take 8000 samples per second to preserve the original signal. Given this and using the DM, you can codify the signal with 8000 bps or 8 Kbps. OTOH, if you were using PCM with 256 levels (8 bits each), the same signal could occupy 8000 * 8 bps or 64 Kbps.It is clear that the DM needs to transmit a lot less data than PCM. But, as you can imagine, DM doesn't provide any quality: it does not adapt well to signals with sudden changes (such as a shouting voice), although it might work for monotonous voices. On the opposite side, PCM with 256 levels provides very good quality.IIRC, DM was once used in the Japanese public telephony network but was soon dropped due to the poor results. (Sorry, couldn't find a link to demonstrate this.) [Continue reading]

  • Java: Dynamic class loading

    One of the things I like most about Java is its ability to load classes on demand. Given its interpreted nature, the virtual machine can detect when a class is not yet loaded and bring it to memory transparently; think of this as page faults and the MMU handling them.Even more, you can ask it to load a specific class based on its name, which allows you to design powerful abstract models painlessly. Of course, you can do the same thing with C or C++, but things are trickier — dynamically loadable modules are not easy to deal with. (You could also use link sets.)As an example, let's consider (a simplification of) a set of generic classes for unit testing that I've written as part of a university project: Test: An abstract class to implement unit tests. Each class in the project will have another class dedicated to testing, which will inherit this one. For example, given a Foo class, there will be a TestFoo that does whatever is appropriate to ensure that Foo works. Tester: A generic driver that, based on commands given in the standard input, loads the appropriate test class, runs its unit tests and verifies the results based on prerecorded (correct) output values. The thing is: how do you get a Tester class that is completely independent of, say, TestFoo? Ideally, Tester should only know the Test class and nothing else. Here is where dynamic class loading comes to help.The Tester class receives a class name (Foo in our example) on the program's standard input, among a set of arguments that describe the unit test to be executed. Based on this name, it tries to load its corresponding testing class and, if it succeeds, it executes the appropriate methods. This is only possible because all testing classes have Test as the common ancestor.As a code example, assume a className variable that holds the name read from standard input and a opName variable that has the name of the operation to be tested:String className, opName;/* Read className and opName from stdin. */try { Class c = Class.forName("Test" + className); Test t = (Test)c; t.execute(opName);} catch (Exception e) { /* Catching Exception for simplicity. */}It is up to your imagination how you use this feature, but, as you can see, it is extremely useful. [Continue reading]

  • USB mouse, pbbuttons and lack of udev

    When I have to do intensive "graphical" work on the iBook, I often connect an external USB mouse because I find the touchpad uncomfortable. However, I've been suffering a problem for a long time: the pbbuttons daemon did not recognize it, so it didn't detect activity and shut off the screen every now and then.I was so tired of this annoying behavior that I sat down and looked for the problem. It bothered me a lot because it used to work correctly in a previous installation. I'm running Debian and udev is not enabled; this last thing is the most likely difference between the two installations.Looking at pbbuttons' manual page, I found that it uses the /dev/input/event* devices to detect peripheral activity. I looked at those files and there were four of them (generated by MAKEDEV); strange, I thought; everything looks correct. So I did the obvious thing after reading pbbuttonsd.conf(5): added autorescan=yes in /etc/pbbuttonsd.conf. No luck; it kept working incorrectly.The next thing was to check whether the daemon was using the devices or not. I did: lsof | grep pbbuttons as root and, as expected, it had all the appropriate devices open. Hmm... it reads from the devices but doesn't detect mouse activity? Maybe there is something wrong in the kernel? (No, fortunately ;-)My next test was a cat /dev/input/event? >/tmp/a for each device, move the external mouse while the command was running and see if /tmp/a had a size different than 0 afterwards. As you can expect, for the event[0-3] devices (the standard ones), I saw no output. Aha! That had to be the cause.I created a new device:# cd /dev/input# mknod event4 c 13 68# chmod 660 event4ensured that it received mouse events using the trick above and restarted pbbuttons. Voila; it detected the mouse again. Maybe I should enable udev and this could have worked automatically... [Continue reading]

  • GNU Zebra

    This semester, I'm taking a course (PIAM) about Internet protocols at the university. One of its main subjects are Internet routing protocols, of which we've seen RIP and OSPF as IGPs and BGP as the EGP.In order to see their functionality in action, we set up a set of machines to simulate the Internet and/or isolated LANs, using the protocols mentioned above. You can imagine that we needed many routers to get this working (around 20), as all the class had to practise the same thing at once. But the routers that implement these protocols (specially BPG) are very expensive, so this is not affordable.Instead, we use regular PCs running Linux to act as real routers. There is a wide variety of software to do this, but we used the GNU Zebra application. Zebra is a free routing software that runs on top of Unix systems and implements all the protocols mentioned above.What I found very interesting, though, is that GNU Zebra is controlled through an IOS-like interface. It accepts most of the IOS commands verbatim, despite some of them are a bit different. Also note that this is not restricted to the routing protocols only: you can even set up the network interfaces and routing tables using this interface so it can be used to hide the underlying OS to anyone who already knows IOS. [Continue reading]

  • SoC: Map and results

    Quoting Google Code news:As the remaining awards are being distributed and the t-shirts are being prepped to ship out, we thought we'd give you an idea of the both the global scope and the hard work done by the students and mentors during the Summer of Code. We've put together a map and a list of projects for your examination. Please note that not all of the projects are listed quite yet, but we wanted to share some info with the people who follow this site.It has taken a while, but the projects and results are finally announced. There certainly is a lot of interesting stuff in the list :-) [Continue reading]

  • Remembering Freedows OS

    Yesterday's MINIX post made me remember the Freedows OS project; I talked about it with a friend recently, who didn't know about its existence, so hence this post.Freedows was an operating system that aimed at providing multi-platform emulation. It was born in 1996 and was based on a microkernel architecture. It had to have servers for different popular operating systems, such as Windows, Linux and DOS (IIRC), allowing the user to run applications from each of these seamlessly.It is a pity that it was abandoned in 2002, possibly because its high ambitions and expectations. It seemed to be quite popular at its time, as I recall articles about it in generic computer magazines. What is worse, the web site disappeared together with the code (I guess it is still somewhere else for historical reasons, though). Check out the Wikipedia article for more details.Fortunately, we now have ReactOS, which is coming along nicely and also plans to incorporate non-Windows subsystems.BTW, a quick Google search shows a Linux distribution from Brazil whose name is Freedows. Don't get confused, as it is completely unrelated. [Continue reading]

  • MINIX 3 published

    As seen in the MINIX news site, the 3rd major release of this operating system has been released today. As seen in the new web site:MINIX 3 is a new open-source operating system designed to be highly reliable and secure. It is based somewhat on previous versions of MINIX, but is fundamentally different in many key ways. MINIX 1 and 2 were intended as teaching tools; MINIX 3 adds the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability.The fact that it is based on a microkernel and published under a BSD-like license have raised my interest in this new version — yes, I like the microkernel design more than the monolitical one (and this is one thing I don't like from NetBSD).I've already tested the downloadable live CD and looks promising. It's extremely fast, but obviously less functional than a complete BSD or Linux system (at least for now). I still remember when I tried Minix 2.something on a 386SX 16Mhz laptop; it really made a difference compared to Linux (using a Slackware 3.4).I guess we can expect nice things from this new code-base. [Continue reading]

  • SoC: Payment received

    Being part of Planet SoC, I think it is a good idea to post this: I've just received Google's cheque for my Summer of Code 2005 tmpfs project! I'm happy :-)Unfortunately, due to some tax issues, Google has withhold a 30% of the original payment. I hope to be able to ask for a refund the next year... [Continue reading]

  • Sending mail from the command line with Mutt

    During the migration to Blogger, I used the post-by-mail service to ease the move of all posts. I downloaded all the old ones into my computer and then automatically sent a mail for each of them to the appropriate posting address.However, this was not easy. As all the posts were in HTML format, I needed to tell the mailer to send a multipart message with a text/html part. After many attempts, NetBSD's mail(1) command proved to be insufficient so I had to look for another mailing utility to do the same thing. (Note that I know few things about the mail protocol, so I can be missing something.)My first thought was that Mutt could help. Indeed, if I composed an empty mail and attached an HTML file, it did what I wanted. The problem came when I had to automate this from a script... The first attempt was something like:mutt -s "$(cat mail/$f.subject)" -a mail/$f.html address@example.orgOk, this worked, but having to type [Enter][Enter], then :wq and then y for each message was not automatic. The first thing I solved was the save and edit part from the editor. Instead of using vi(1), I asked Mutt to use touch(1):EDITOR=touch mutt -s "$(cat mail/$f.subject)" -a mail/$f.html address@example.orgThis solved the :wq part but I still had to type [Enter][Enter]y for each post. How to solve it... I searched a bit (I mean, Googleed a bit) and found that giving /dev/null as the standard input to Mutt was enough to silence it. So the command ended being as:EDITOR=touch mutt -s "$(cat mail/$f.subject)" -a mail/$f.html address@example.org </dev/nullStill, it'd be nice if the standard mail(1) utility was able to send complex messages... [Continue reading]

  • Blog migrated to Blogger; welcome!

    As I outlined a week ago, I was considering the migration of my blog (jmmv's weblog) from Livejournal to Blogger... and I finally did it. Therefore, welcome to the new site!Before continuing, update your subscriptions! You can find the link to the new Atom feed in the Basics section on the sidebar (don't know how to do RSS yet). And forget about the older site; it will no longer be updated (though the contents will remain there for a long time).As you can see, the name of the blog has changed to The Julipedia. See this page for more information on its etimology and a bit of history.How did I do the migration? It was not easy; I was able to automate several things, but ended up doing a lot by hand. Of course, I could have spent a lot of time writing and creating a script that did the whole migration, but it was not worth it. Here is a brief outline of what I had to do: I exported all the messages from the old site to XML documents using Livejournal's export utility. This tool works on a month basis, so I had to go month by month (easy). With the XML files at hand, I created a little XSLT stylesheet that extracted the subject and body parts of each post and converted them to a plain text file with extremely simple delimiters. Then I created a Perl script that took this plain text file and wrote a pair of files for each post: one holding the subject and one the body, doing some HTML fixes along the way. With all these little files at hand, I used Blogger's post-by-mail feature to automatically post all my messages (by using a little shell loop and mutt). I will talk about this on another post. Unfortunately, this did not preserve timestamps, so I manually fixed them all. Big ew: 181 posts to fix by hand. At last, I migrated all user comments, also by hand. At first, I thought there were very few of them, so it seemed like a painless task. But in the end, there were a lot (which is a good thing :-).All my posts were migrated using my account. Posts made by other Livejournal users were migrated by using their user name and link to their blog. Posts made by other people were posted as anonymous.I also added a little note on each post with the exact date in which it was originally posted, for archiving reasons. And that is it. It has not been fun, but it is done. I hope you will enjoy the new site as much as I like it! [Continue reading]

  • About The Julipedia

    The Julipedia is Julio M. Merino Vidal's personal blog; this was born on June 22nd, 2004, and was previously known as jmmv's weblog. On October 22nd, 2005, jmmv's weblog was officially migrated from Livejournal to Blogger due to multiple reasons (beeing the ability to control visits the most important one).The transition was an ideal moment to rename the blog to give it an identity of its own, and hence The Julipedia was born. This name was invented by Brainstorm, a friend of mine, who uses to call me by this name. It is composed of two parts, as you can see: Juli, which is the Catalan spelling of my first name, and pedia, which comes after Wikipedia. I believe this is because I often answer his Unix related questions quickly :-)I hope you like the new look and structure of the blog; it should be easier to navigate than before. And, of course, be welcome to the blog if you are new to it!(The aim of this post is to be linked from the Basics column on the sidebar. Its contents can change without further notice.) [Continue reading]

  • How to contact Julio M. Merino Vidal

    If you would like to suggest an idea for a future post, please use the Suggestion box. I will receive a notification when you add a note to that post, so rest assured that I will read it.If you need to contact me personally, you can do it by sending an e-mail to my personal address. If your message is related to NetBSD in some way, you can use my NetBSD address. I will ignore technical questions sent to these (see above).(The aim of this post is to be linked from the Basics column on the sidebar. Its contents can change without further notice.) [Continue reading]

  • Suggestion box

    I am open to suggestions from my readers — that is, you — for future posts. Keep in mind that these are mere suggestions: I reserve the right to talk about those that I find interesting and omit those that don't. Note that this post's comments might be deleted in the future to leave room for newer ones.Here is a non-exclusive list of topics I am inclined to cover: General programming questions — specially if they are focused on C++. General Unix questions — specially if they target BSD systems.General portability questions. pkgsrc internals and questions about the packages I maintain (mostly GNOME). NetBSD internals (to some extent; I will be glad to explain what I have learned so far but I do not know much yet). Questions about my own software projects. Please note that this is not meant to be a technical support forum. If you need help using any of the projects listed above, please refer to their documentation and/or public mailing lists.Yes, I took the idea of a suggestion box from The Old New Thing ;-)(The aim of this post is to be linked from the Basics column on the sidebar. Its contents can change without further notice.) [Continue reading]

  • GNOME 2.12.1 hits pkgsrc

    As usual, the latest stable version of the GNOME Platform and Desktop, 2.12.1, has been integrated into pkgsrc. It has been a tough job due to all the affected packages and comes a bit late, compared to all the previous updates, but I hope you'll enjoy it. [Continue reading]

  • Blogger

    Two years ago or so, I registered a weblog at Blogger, which only lasted a week (don't bother looking for it; it was deleted). At that time, I didn't like that site much, specially because it lacked a very important feature: integrated support for comments. Yes, you could use external utilities/sites to host comments, but that was complex. [Continue reading]

  • Articles: Lightweight web serving with thttpd

    Several months ago I started writing an article about setting up and using the lightweight web server thttpd, focusing on the NetBSD operating system. I finally decided to finish it a month ago and submitted it for publication. You can now read it on-line at ONLamp. [Continue reading]

  • C++: Constructors and global data

    As a general rule of thumb, accessing global data from within class constructors is a dangerous operation and ought to be avoided. The C++ specification does not describe the order in which global variables are initialized, so there are high chances that your constructor accesses uninitialized data, producing unexpected resultsn (e.g., crashes in some circumstances). [Continue reading]

  • Monotone: Using mini-branches to apply patches

    The Monotone VCS provides the concept of mini-branches. A mini-branch is a lightweight branch created inside a formal branch whenever a commit causes "conflicts" with the actual contents of the repository. For example, if your working copy is not up to date and you commit something, you will create a new head within the branch (that is, a mini-branch), that you will later need to (possibly manually) merge with the other head to remove the divergence. [Continue reading]

  • Games: Half-Life 2

    Half-Life 2's Game Of The Year edition was published past Friday. I finally bought it (have been waiting for this since I threw away my illegal copy several months ago); this edition is cheaper than the original game and comes with some goodies. And just a few minutes ago, I completed it :-) (had started with my old saved game, which was almost at the end). All I can say is that the game is really stunning. If you like FPSs, this is The One. [Continue reading]

  • C++: Templates and the ABI

    In the previous post, we saw why inlined code is dangerous in a public API. Unfortunately, I carelessly put templates in the same bag in an attempt to generalize the idea too much, giving an incorrect impression of how they work. A reader (fellow_traveler) spotted the mistake and here is this new post to clarify what's up with templates and an ABI... if one can relate the two concepts at all. [Continue reading]

  • C++: Inlined code and the ABI

    There are many development libraries that provide inline functions (or macros) as part of their public API. This is often done for efficiency reasons, although some times it's done because developers don't know the consequences of doing such things (this last thing is just a guess, but it can perfectly happen). Providing such inlined functions breaks the whole idea of encapsulation and shared libraries. Let's see why. [Continue reading]

  • New utility: verifypc

    After five months or so of not touching the code, I've finally cleaned up my verifypc utility and imported it into pkgsrc. Its purpose is to sanity check the dependencies of a given package based on its calls to the pkg-config program. [Continue reading]