Archive for October, 2007

kdesvn-build speed improvements (and some KMail)

October 31st 2007

I’ve started on work to implement a feature requested in bug 109619. Namely, to allow kdesvn-build to start the build process as soon as the first module has been updated from subversion and then to run the two updates in parallel as much as possible.

It’s harder to do than it sounds at first but I think I have something working. If you try it out (latest kdesvn-build from trunk/KDE/kdesdk/scripts) and it’s broken for you please let me know.

Also some KMail/Kontact tips for you: I don’t know why but I was under the impression that the “Mark Thread As->” feature required you to click on the root email of the thread in question. That’s not the case, any message in the thread will cause the whole thread to have the desired attribute applied. Also, if you ever get messages in your inbox that simply refuse to go away then you may have a bad message folder cache. At least for Maildir type accounts. In that case, shut down Kontact and KMail (including from the system tray), go to your Maildir folder (mine was ~/Mail) and look for hidden files of the type .folderName.index* (I had .inbox.index, .inbox.index.ids, and .inbox.index.sorted in mine).

RENAME these files to something else (I moved them to a backup directory), and then restart Kontact. It may take a couple of seconds to rescan your folder (although it was near instantaneous on my system) and then you should have your folder corrected with all the undeletable messages gone.

Posted by mpyne under KDE & Useful Tricks & kdesvn-build | 3 Comments »

The USS Hampton

October 26th 2007

I’m sure many have seen the news about the nuclear fast attack submarine, USS Hampton, which has had its operations suspended due to failing to perform required inspections, and then trying to fake the required paperwork later.

We had heard inklings of what happened before it hit the news, so I knew that the media coverage of the story was predicably inaccurate but nothing too bad. But then I saw what may have been the stupidest blog post ever about it. Their description? “USS Hampton Submarine Crew Fails To Read Meter, Fakes Logbook, As Fluid That Keeps Reactor From Going Critical Runs Low”.

They then go on to talk about some magical ingredient that submarine nuclear reactors have that keeps the reactor from going critical which must be constantly maintained and which this crew was not doing. Then they accuse the Navy PAO who said that there was never a threat to the public or crew of a “Flat-out fucking lie”.

Unfortunately reality has a funny way of interposing. First off, though this may surprise people, the reactor is pretty much always critical while underway. This may be deduced from the definition of criticality: “2. Physics The point at which a nuclear reaction is self-sustaining.”

Even going by what I assume they mean by critical (i.e. chain reaction going out of control) the chemistry levels couldn’t cause that. Pretty much everything dealing with the actual operation of a naval nuclear power plant is classified CONFIDENTIAL but the fact that we use Pressurized Water Reactors is public knowledge, and Wikipedia has a good article on their operation. I’d like to point out the section dealing with control of reactor power: “Generally, reactor power can be viewed as following steam (turbine) demand”, and “Boron and control rods are used to maintain primary system temperature at the desired point.”. In other words, reactor power depends on the system demand (it automatically rises and falls as necessary), while control rods control temperature. What about boron, you ask? The article answers it in the last sentence of that section: “Due to design and fuel enrichment differences, naval nuclear reactors do not use boric acid.”

Notice nothing of that (besides boron, which I’ve covered) deals with chemicals. We do add chemicals to the water, obviously. But not for control of power. The author of the story I linked to then goes on to say that failure to maintain levels of this magical substance will cause alarms going off, and then “everyone becoming radioactive and the ship sinking.” Which is just so funny that I actually laughed at first until I realized he was serious.

He then says that it’s easy to measure the level, i.e. you just read a meter. That’s unfortunately not the case. It may be on civilian plants but monitoring chemistry levels on the submarine involves (at the very least) drawing a sample of water to perform the analyses on in the first place, which is rather involved due to the fact that the water is radioactive to at least some degree and therefore radiological controls are required during the entire sampling and analysis process.

He then compares adding more chemicals to maintaining the oil levels in your car. I don’t know how his car operates, but with mine I can just unscrew the lid, pour in a quart, and screw the lid back on. You can’t just “unscrew” a cap off of a very highly pressurized primary coolant system and pour some chemicals in. It’s not super hard but it is an involved process.

Next up: “This is in the course, mind you, of a 12 hour daily shift, most of which you spend, in the normal course of activities, bored. Having something to do is good.” To which all I can say is that the author has obviously never been underway. Between training, drills, monitored evolution periods, actual mission operations, cleaning, and qualifying it’s hard enough to find time to sleep. And it’s not a 12-hour shift, it’s (in theory) 6 hours of watch, 6 hours of maintenance/training/other work and 6 hours of off time in an 18-hour day.

Finally the author says that this is the very last bit of maintenance you would want to mess up and then calls the workers in “the reactor room” a bunch of “complete fuckups”. I can think of at least 3 maintenance items right off the top of my head that would be much more horrifying to “gaff off” and I’m sure there’s dozens more that more directly impact reactor safety. And there is no reactor room, and not every nuclear-trained worker was complicit, and the fact of the matter is that we don’t know what happened to cause this (the Commanding Officer has just been relieved of command however).

This is not to try and fluff off what happened (missing chemistry analyses is a *big* deal to Naval Reactors). I would like to think that the whole division did not ignore daily samples for a month (as this would involve not only the RL division in question but also all of the EOOWs and EWSs who had stood watch over that time) but instead had forgotten some sort of non-daily sample. But until more information is released about what exactly the Hampton did wrong it’s way too early to start calling the hardest-working department on a submarine a “complete fuckup”.

Planet KDE readers: I tried to include something relevant to KDE but I have no nifty unfinished work laying around at this time. :-(.

I realize that there is often confusion about how nuclear power works so if anyone has any questions feel free to ask in the comments section but if I’m vague at all (or just refer you to relevant Wikipedia entries) just realize that I have confidentiality standards I have to maintain.

Posted by mpyne under Navy | 11 Comments »

My scanner works

October 24th 2007

Spent a lot of time over the past two days scanning in some old photos that my Grandma has left me and trying to touch some of them up. I’m not good at photo editing but ye olde “Auto Adjust” feature has made a lot of these pictures look better. For a few of them they looked 100% better just from being scanned (xsane also has an auto-adjust feature).

Picture of myself as an infant

Sadly I look nowhere near this good nowadays. :)

Posted by mpyne under Personal & Pictures | No Comments »

ELF Library dependency viewer

October 24th 2007

So after having a Gentoo upgrade break a lot of programs, even after running the revdep-rebuild which rebuilds packages affected by a changed library, I decided that I had to have a way to find out what libraries in particular were causing programs to need to load the affected library. In my case an expat upgrade replaced libexpat.so.0 with libexpat.so.1. Even though revdep-rebuild was supposed to rebuild the affected packages it missed quite a few.

(I would eventually figure out that the reason it messed up is because the lib64 directory is symlinked to lib since I have a 64-bit system. The program would end up linked against a library in /usr/lib64, revdep-rebuild would look for programs linked against the exact same library, but in /usr/lib instead, and then not find it.)

Anyways, after playing around with ldd and discovering that it would not give a nice tree diagram showing what the dependencies of a program was I decided to make a tool that would do so. I call it ELF Library Viewer (elflibviewer on the command line):

Screenshot of the ELF library viewer in action

If it interests you at all it is available from my dumping ground. It requires Qt 4 and the readelf utility to be installed. It doesn’t really do much error handling (i.e. run it on ELF executables and libraries and you’ll be fine) but it shouldn’t ruin your binaries either.

It is rather Linux-specific at this point as well, but it should mirror the GNU binutils way of finding libraries closely. Instead of searching the ld.so cache it checks ld.so.conf to figure out what ld.so should be caching however. Let me know if this program proves useful for you (or if I’m just reinventing the wheel). Bonus tip: Type the name of the offending library into the search line and hit enter. It will highlight in red all of the libraries which depend on the offending library. It also recursively resolves dependencies, but only the first time it sees a library. It probably wouldn’t be too hard to copy over the dependency tree each time it reencounters a library but I can’t be bothered to implement it.

Posted by mpyne under Computing Troubles & KDE & Screenshots & Useful Tricks | 16 Comments »

Back again (with a book review too)

October 23rd 2007

Back from my last patrol. Now I’m close to being fully qualified. That will be nice to finally achieve.

I had been contacted by a representative of Packt Publishing before I left, who had read my article dealing with some QMail administration issues. They had a new book out, QMail Quickstarter by Kyle Wheeler and were wanting to know if I could review it.

I agreed to do so, with the proviso that it was unlikely they’d be able to get the book to me in time. I was right. :-). However I’ve taken some time to read it and think I can get a decent, if belated, review. Note: The review copy of the book was provided to me free of charge, for those who are concerned about that sort of thing.

The book is a relatively short affair, which bills itself as an easy to follow guide that can get you up and running quickly using QMail. It is certainly true as far as this is concerned. Even with the standard material at the beginning describing the book layout, what QMail is, blah blah blah you can be issuing commands to start the installation by about page 6 or so. After you have QMail installed the author describes how to configure QMail, and goes more in depth on the actual operation of QMail. He also demonstrates his knowledge of the resources available to the QMail community with his sampling of commonly-encountered problems (and solutions) and his descriptions of available patches for QMail. This includes patches to QMail to allow for better filtering when receiving messages over SMTP, patches to provide SPF and DomainKeys support, and recipient validation patches to help prevent “joe-jobs“.

There are, of course, several areas where the book comes up short:

  • The installation and configuration steps are well done overall with a procedure to follow that will lead you to a configured and working qmail installation. However, although several tricky points of concern are addressed (including build fixes for glibc > 2.3.1 and the well-known qmail prohibition on delivering to root), there’s not a lot of detail on what to do if something goes wrong. This is a minor point given that it’s a quickstarter guide and some knowledge of UNIX and Google use needs to be assumed implicitly.
  • Also, no mention is made of using distribution-provided packages. My QMail is the distribution provided one and the book works fine against it. However many distributions will apply patches to the QMail installation and it may be useful for the reader to know if they can use the distribution QMail and if so, to warn them that it may be already patched.
  • Speaking of patches, although they are often referenced, and the author does a very good job of explaining why they are (and are not) useful, he doesn’t go into a ton of detail on how to actually use them. If you follow the directions from the beginning you’ll likely have to recompile QMail at least one time as you’ll have it installed and mostly working before you realize that you want to install a patch.
  • And finally, just as an overall point the author is kind of hit and miss on providing procedures to do some of the neat things he references from about the middle of the book on. For example, he gives instructions on how to authenticate POP3 communications using checkpassword. The very next section describes webmail without so much as an appropriate program to look at. Likewise for DomainKeys (which have examples detailing how to use them) and SPF (which is described, including its weaknesses but without implementation help).

The book however has a lot to recommend it:

  • If you are someone who learns better from diagrams then you will like this book. It includes diagrams on the email flow of a qmail installation, including which portions are root, which portions share the same protection, etc. This diagram in particular makes the entire system much easier to understand, and makes it easy to pick out where to add filter programs (i.e. for virus scanning, user validation) or what you’d need to change/patch to add support for new features.
  • The included diagram/flowchart on virtual domains is also very useful although I don’t use virtual domains.
  • The book is filled with little tips, gotchas, and other notable things that you may miss if you’re not paying attention on your initial read-through (for instance, what happens to mail being delivered to an address with an empty alias file, or the headers qmail-inject uses to guess recipients and senders). I almost had wished they were more obvious but the book is a short read without much fluff so you owe it to yourself to just read through it.
  • The book covers the stuff that needs covered, like config file syntax, command syntax, how to use tcpserver and svscan for those going the whole DJB way, etc. Although the author may not spell out the most useful situations he covers enough between the examples and diagrams that it shouldn’t be hard to add that one feature you want (especially if you already have the program and you just need to place to plug it in).
  • He covers enough material in the book to at least glance on such topics as: .qmail/.forward files, aliases and defined users, QMTP, virtual domains, vpopmail, IMAP, Spam and virus filtering, encryption, mailing lists, logging, log analysis, and optimization techniques.

The final verdict? It depends on what you need. It is $25, which although cheap for a computer book is probably slightly more expensive than its size would have you believe. However if you are new to QMail then you should get this book as you will save enough time overall to be worth the $25. If you are already familiar with QMail and have a working installation then the book could be useful as a reference but you’ll probably be OK with Google and the man pages you already have.


Also of note: kdesvn-build has been updated to version 1.5. If you haven’t already removed kdeaddons from your .kdesvn-buildrc you probably should as it’s gone from SVN. Likewise with kdenonbeta (1.5 has fixed unsermake support to deal with the new layout). Other than that there’s not a lot of major new stuff in the latest release.

Posted by mpyne under Book Review & KDE & kdesvn-build | 1 Comment »