Thu May 12 23:01:00 EDT 2011
OpenSSH LDAP public key patch
The patch is here.
Wed Aug 11 23:51:50 EDT 2010
Those seeking knowledge... should go elsewhere.
I have benefited greatly from reading. You could say that my entire livelihood is indebted to people who shared information with me through text. There is nothing better than becoming absorbed in the text of someone who knows a subject while they lead you plainly through the matter at hand. Their words and phrases are tools brought out at the right time to convey meaning with precision. On the other hand, there is nothing more frustrating than someone who wants stroke his own ego by bewildering you with words which exclude your understanding. He strings together bits of refuse, and presents them as if they were a string full of unobtainable and priceless pearls reserved for someone greater than yourself.
Here is an example. Today I was reading something and enjoying myself when I followed a link to wikipedia, and ran into this...
In type theory, the type of functions accepting values of type A and returning values of type B may be written as A → B or BA. In the Curry-Howard correspondence, function types are related to logical implication; lambda abstraction corresponds to discharging hypothetical assumptions and function application corresponds to the modus ponens inference rule. Besides the usual case of programming functions, type theory also uses first-class functions to model associative arrays and similar data structures.
I have a hard time thinking this is anything other than logorrhoea. Who will possibly be helped by that? That can't possibly be the crystal clear product of the authors distillation for the masses. Reference books within a profession might need to rely on everyone sharing a vocabulary and history of ideas. In that case, it is likely the language would seem obtuse to an outsider. In the case of wikipedia, I'm not sure that it is meant to be a reference in that sense. It is meant more to explain things to people who don't already know about them.
Mon Jun 7 14:33:11 EDT 2010
Openvz patch for atop 1.25
You can get it here.
This will allow you to see what veid a process belongs to. It will also let you group processes by veid and sort them based on whatever atop will let you sort by (cpu, disk, memory etc.).
Fri Mar 12 13:22:26 EST 2010
Getting to BIOS from serial console
Finally, someone at work dug this out from some somewhere on the 75th page of a google search.
Press esc and then - (the minus key), and it should work.
Tue Sep 22 23:21:03 EDT 2009
I've written up a description of my adventure with it in one of those nifty article links to the left. You can read it here.
Wed Sep 9 23:56:13 EDT 2009
atop patch update
Wed Sep 9 23:05:32 EDT 2009
AVR RISC intstruction set: LPM & the Z pointer
Have you ever had a time where something you've known for a while or read several times hits you in a whole new way? Typically it is when you realize another facet of a truth. Notice I didn't say a new interpretation of truth, but a new facet (this difference deserves a post just by itself).
Anyway, I just had this experience. It just happened for me with the Z pointer for accessing flash memory. In this case, I think I realized that I wasn't thinking about it at all before.
Program memory on these chips is organized in 16 bit words. The manuals simply state that:
The 15 most significant bits selects the word address in Program memory.
Because of this, the word address is multiplied by two before it is put in the
Z-register. The least significant bit of the Z Address Register selects
either Low byte (0) or High byte(1) of the Program memory word
No big deal right? This instruction just stuffs the result in register 0. The registers are 8 bits, so you only get half at a time.
Here is where I realized that I was a moron.... Typically, you just load up two 8 bit registers with your address split across both. Dutifully, you multiply it by two before hand, load the result, read it, increment the pointer by one and load the result again to get the second half. I always thought that the addresses were somehow indexed at 16 bits, and that lower bit was somehow magical. The point is that yes, if you use 15 bits, you effectively do index by 16, but the addresses really work on chunks of 8 bits. For some reason they take a really round about way to say that the addresses work on 8 bit intervals, but the architecture is built to work on 16 bits at a time from program memory (typically 8 bits for the opcode, and 8 bits for the operand).
Sat Aug 29 00:09:08 EDT 2009
I nearly forgot to mention that I am maintaining the pam-abl code now. I needed this for work, and started making changes, so I figured I would maintain it.
Basically pam-abl is a PAM module that automatically blocks people who fail to log in correctly more than a few times. Currently, it just makes it impossible to log in even with the right password. The changes I'm making allow you to do more things like change the firewall, and update a global database (LDAP) for the sake of other servers on the network.
When these changes are done at work, and make sense, I'll unleash/release them to the public.Here's the link
Wed Jun 10 23:56:10 EDT 2009
WD HD Media Player Fun Facts
I was recently asked to take a look at customizing a WD HD media player. I can't stand TV (I don't even own one), and I don't watch that many movies, but this little thing is cool nonetheless. It's tiny, and it runs linux. To make changes to it, you can make some blind changes to the firmware, and hope you did it right, or you can hook up a serial cable to the connector on the inside.
You'll need a level converter to convert from RS232 to TTL. I didn't have one on hand, but found a handy kit at nkcelectronics. You could bread board it easily enough, or buy a premade cable. It just depends on what you have around and how much hassle you want.
For those of you who are used to running minicom at 9600 baud for other things, you'll only see gobbly gook. You need to set up minicom for 115200 8N1.
I hooked up a serial cable to the connector inside the device, and started poking around. I thought I'd post a few facts about what's on the inside.
- The hostname is Cynthia
- Here's a list of all the files on the box as it comes from the factory.
- Here is the original firmware from the factory.
- Here's a little info on the processor.
system type : Sigma Designs TangoX processor : 0 cpu model : MIPS 4KEc V6.9 Initial BogoMIPS : 292.86 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes ASEs implemented : mips16 VCED exceptions : not available VCEI exceptions : not available System bus frequency : 198000000 Hz CPU frequency : 297000000 Hz DSP frequency : 297000000 Hz
Unfortunately, the proprietary chip they use is what does most of the "stuff" that this box is useful for. All of the programs that communicate with it are also closed source. There isn't a good way to say, play a movie from the command line. It would be really nice to have a way to simply control playback.
Also, another bugger about this thing, is that they stuff the repeat settings into flash. That means if you are trying to work around the lack of interface by jacking right into the IR port with eirid, every time you hit the repeat button, it will be one off from where it was last time. Watch on the console after you hit the repeat button! A second or two later, you'll see it saving the new "config" to memory. It doesn't actually use this repeat setting on the next playback, it's just there to annoy you!
For instance, let's say you programatically press the repeat button once. This bring you to repeat-1 (repeat this movie). Now you shut off the power, turn it back on and try to do the same thing again. What will you get? You'll get the next repeat option up, which is repeat all. If you pull that movie out, put in a new one and try to hit repeat again, you'll shut off repeat all together!
What would make sense here is if that saved setting actually did anything. That way you could just check the last setting, and leave it if already set. It doesn't make a difference though, and your movie will not repeat even if the last repeat setting is stuffed in memory. I needed to manually change the video playback mode in the config file (somewhere in /tmp if I remember correctly). When you change the file in any way, it is automatically saved to memory. So what I did was reset it to no repeat in the file, and then programatically send the commands to repeat through the IR interface.
More info on the player can be found here.
Thu Apr 23 20:22:05 EDT 2009
I just tried the -fprofile-generate/-fprofile-use feature of gcc, and I must say that I was more than surprised at the benefit. We switched to some different server software on our resolvers because BIND couldn't handle the load. That in itself was a big improvement. Following the authors suggestion, I tried out that feature of the gcc compiler, and wow.
When I say wow, let me define that. With BIND the server was on its knees, begging for death and causing massive backups on all our email servers. With the switch to pdns-resolver, that went down to 30-50% cpu usage. With the recompile, it hangs out around 8-30%. The server is barely breaking a sweat now.
I had to cross compile on a computer that had gcc, and move it to the server. If you need to try something similar, just be aware that when the program dies, the profiling information will land in the exact same path as where you compiled the program. I had assumed they would land in the current working directory. There appears to have been a -fprofile-dir option at one time, but it doesn't seem to exist anymore. No big deal, it just creates all the needed directories if they don't exist (which they didn't in my case). It might be something to think about if you have a similar directory hierarchy on the other server, and don't want to lose the files in a mess of other stuff or overwrite things.
When you compile the binary this way and run it, it gathers data and dumps it in files when the program stops.
All the files have gcda and gcno extensions. They have profiling information which gcc uses later to know where it should spend its time optimizing and where it shouldn't bother. Like I said, this appears to work really well.
Mon Jan 12 23:15:30 EST 2009
Okay, after today, I just have to say, "If you love bloody knuckles, buy Craftsman."
I have had craftsman tools for quite a while as many of them were given to me as gifts as a teenager and throughout college (since my wife and I have always too freaking poor to buy much other than groceries, and pay somebody rent. People figure that at least I can maybe fix stuff that I can't afford to replace if they buy me tools). Things haven't changed much, and I still have to wrench on old cars every now and then.
The one tool I have had the most problems with is the dreaded Craftsman ratchet. The ratchet mechanism has an underpowered spring that doesn't actually click the lock back inside the ratchet head all the way. Somehow or another, it will suddenly let go when you are exerting all kinds of force on it, and the handle flies free to let your hand and most notably your knuckles go flying with it, so that you punch large jagged metal object with all your might. If that weren't really enough, you have to manually hold the direction switch over for the thing to even work after a while. I've returned one particular ratchet several times now, figuring them to be flukes. I must admit the lifetime warranty can make you forget the bloody knuckles one or two times. But today, I've determined that they just plain suck.
As Huey Lewis put it, "Sometimes bad is bad." Craftsman ratchets are the badest ratchets around.
Sun Jan 4 17:52:29 EST 2009
Atop patch to compensate for Centos 5's missing process IO stats
We have a mix of Centos 4 & 5 boxes at work. These servers are loaded to the gills. Quite a few time we will need to track down load issued caused by IO wait. These buggers are hard since they don't come up with "top". We started using atop since it can show per process disk usage stats (not to mention the ability to go back in time an examine a problem we couldn't catch when it happened). This only works on Centos 4 though.
For some reason, the people over at Redhat thought it would be cool to remove /proc/PID/io from the kernel stats, and it wound up in Centos 5. I have no idea why this happened. I couldn't find the functionality anywhere, but I could be an idiot too. All these things could be solved by a simple kernel patch, but changing our kernels isn't that simple.
To compensate for this, I wrote a patch that helps us out by showing which process is waiting for IO. It doesn't explicitly show you who is using how much disk IO, but it is just about as useful for our purposes. Since the problems are caused by a lot of IO wait, knowing which process is doing all the waiting is a pretty good indication of who is causing it (not always mind you). Depending on your IO scheduler, everything may look like it is waiting the same amount of time. If you have something hosing up your system pretty bad though, you can increase the sample interval to make it stand out from the processes that have a short lifespan. After that, you'll have to use good old experience and intuition. The patch isn't a great solution, but it certainly helps.
If you think it might be useful, give it a try. atop patch
Mon July 9 17:33:09 EST 2007
dvdread and g++
Just remember this line:
- #define __STDC_LIMIT_MACROS
Without this line, you can include stdint.h all you want, and ifo_types.h will still complain that it isn't included. That's because dvdread won't work with C++ code without __STDC_LIMIT_MACROS defined. stdint.h will not define the macros that ifo_types tests for when compiling with a C++ compiler. This triggers the warnings even though you can see that stdint is indeed included.
Do a "grep STDC_LIMIT_MACROS /usr/include/stdint.h" to see what I am talking about.