I have been a software developer for about 30 years. I have written a lot of code and maintained a lot of code written by others.

I have found that when I understand a problem I can reduce the complexity of the code I write; one measure being number of lines.

I have read other people's code and been amazed by the simplicity possible when solving a complex problem.

I have also gotten headaches from reading code that is very complex that doesn't need to be. Often such code came from self-educated software developers.

Based on these experiences I came up with a maxim: The complexity of a solution is inversely proportional to the understanding of the person who created it. In other words, the better a person understands the problem to be solved the simpler the solution will be. That doesn't mean that a solution is simple, but it does mean that it is understandable. I have yet to encounter a situation, whether it be software, or organizational issues, or pretty much anything that people can do, to which this maxim does not apply.

Another measure is can the developer explain the code? I have had developers tell me that I will never be able to understand the code they have written and then made no attempt to explain the code. All that communicates to me is that they do not understand what they wrote.

I get to test software on the Internet. In the grand scheme of things there are few servers out there talking IPv6 at the moment. There are relatively few Web servers talking IPv6, and there are relatively few DNS servers talking IPv6. If I configure a caching DNS server to be IPv6 only I can only talk to a few things today. Even if the DNS server is configured to talk IPv4 but I query for names on IPv6 (AAAA records) there are few to find. Many DNS servers don't even handle AAAA requests properly. A lot of infrastructure is yet to be deployed to make IPv6-only a viable way to access the Internet.

Those millions of mobile devices talking IPv6 today can only do that going through NAT64 gateways (read that as NAT 6 - 4, as in allowing IPv6 to access IPv4). Yes, having the devices that can talk IPv6 is part of the solution. Now the servers need to be there.

I suppose you could call the large number of IPv6 devices the "chicken". Now the chicken needs to lay the egg.

One thing I heard and feel is a pretty truthful thing is: "A lousy job with a good manager/employer beats a great job with a lousy manager/employer". If you like who you're working for then you are happier than if you have your dream job but dislike who you're working for. If you don't like who you're working for, for everyone's sake look for a different job.

On the flip side I believe it is your job to make your employer successful. That means doing things within reason to make things work. This is where the above comes in: if you like your work environment you will be willing to make more of an effort. You and your organization will benefit from you putting in more effort. If you don't benefit from doing more than is in your job description then your employer doesn't care about you and that should be a sign to find a better employer.

Your mileage may vary, but you will get out of your job what you put into it. Limit what you put in and you limit what you'll get out. Put more in and you (should) get more out. If the employer values you (and not all employers do) then you will get opportunities to grow personally and professionally and be rewarded when you do.

DNS does seem simple doesn't it? Ask a question and get an answer.

Unfortunately for a recursive resolver to get an answer it must talk to multiple servers. Sometimes, a lot of times, the servers have incorrect or out of date data. So one server says it has an answer but it directs the resolver to the wrong place. Sometimes servers return bad data (it is corrupt or plain junk). Sometimes the server is a really old version of Bind and can't handle the newer features of DNS (DNSSEC, EDNS, new record types, etc.). And sometimes the server is a home made thing that seemed like a good idea at the time but doesn't really work all that well. The number of permutations of bad data and bad behavior is huge.

A recursive resolver needs to handle all of the above and keep working, and try to have good performance. Gracefully handling subtly bad data seems simple until you have to write the code to do it. Yes, the gross problems are simple to solve. The others, well they are what can keep you up at night.

Unbound, also from NL Netlabs, is a recursive resolver. NSD is an authoritative server.

The problem is with Bind as a recursive resolver, not as an authoritative server.

I've installed BSD systems a number of times. They've always required more effort than a Linux box to get configured for what I want.

Sure BSD is a cool thing. To some people MS-DOS 6.11 was a great thing, too. You'd be surprised how many systems in the world are still running MS-DOS (a lot of point of sale systems). Just because something is cool or can be made to work doesn't mean it's the best for any particular use.

You could use a Porsche 911 as a dump truck, but why? You could make a pickup truck into a limousine, but why? Wise use of tools is a sign of maturity.

I own a 16C and wish I had another one to take to work.

I also own an HP-41C that is still my alarm clock. Programmable alarms, and the ability to run programs is so useful.

Calculators still have a place and utility even when you have unlimited CPU capability at your fingertips. Sometimes a purpose built tool can still beat a GUI.

XML (and SGML before it) is a meta language. From that you derive a description language for the specific use. HTML meets the needs for an on-line presentation of information. HTML is not designed and does not work well for printed materials. DocBook is designed to be used for multiple ways of presenting information and has the features for books and other printed media.

To use a bad analogy, think of XML and C. You can write the "hello world" example in C, but it doesn't replace a database application written in C. C can be used for big or small applications. XML can be used for relatively simple description languages (such as HTML) or very rich description languages for large, complex documents (such as DocBook).

I've been using FVWM with multiple monitors for years. xrandr has simplified things considerably. I can drag from one monitor to another with no problem. Below is my current xorg.conf (note that I am running on Fedora 10). You can use a Radeon card by changing the driver to 'radeon'. Use 'lspci' to get the appropriate BusID for your card(s). There may be simpler solutions but this has worked well for me.

And for those saying to use a different window manager please note that FVWM has not stood still but is still true to the name it had when I began using it 15 years ago: the Frugal Virtual Window manager. It is frugal with regards to RAM and CPU use. I also like it because I can edit a file (gasp) to modify the configuration. For old farts like me that's a plus. YMMV.

Section "InputDevice"
# keyboard added by rhpxl
                Identifier "Generic Keyboard"
                Driver "kbd"
                Option "XkbModel" "pc105"
                Option "XkbLayout" "us"
EndSection

Section "Monitor"
                Identifier "DVI0"
                Option "Enable" "true"
                Option "DPMS"
EndSection

Section "Monitor"
                Identifier "DVI1"
                Option "LeftOf" "DVI0"
                Option "Enable" "true"
                Option "DPMS"
EndSection

Section "Device"
                Identifier "nVidia Corporation GeForce 8600 GT"
                Driver "nv"
                BusID "PCI:1:00:0"
                #Option "Monitor-DVI0" "DVI1"
EndSection

Section "Screen"
                Identifier "Default Screen"
                Device "nVidia Corporation GeForce 8600 GT"
                DefaultDepth 24
                SubSection "Display"
                                Depth 24
                                Virtual 3840 1200
                EndSubSection
EndSection

Section "ServerLayout"
                Identifier "Default Layout"
                Screen "Default Screen"
                InputDevice "Generic Keyboard"
EndSection

Two comments:

1. Comments are there to tell WHY the code is doing what it is doing, not necessarily what the code is doing. I deal with code all the time that has comments that tell me what I can easily learn by reading the code, but they don't tell me why so when it is broken I don't know if it is because there is a subtle problem with the code or that the developer didn't know what they were doing.

2. After literally getting headaches from reading code written by other people I came up with a simple metric: The complexity of the coding solution to a problem is inversely proportional to how well the developer understood the problem they were trying to solve. In other words, someone who understands the problem will have a simpler solution than someone who doesn't understand the problem as well. You can apply this metric to things other than code, too, but it is usually very apparent with software.