Reading Brian’s blog I came across his posting on Real Ultimate Power
Facts:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.
…I finally realized what the George Bush and Michael Moore sites where parodying
Facts:
1. George W Bush is a mammal.
2. George W Bush fights Terrorists ALL the time.
3. The purpose of George W Bush is to flip out
and kill terrorists.
Facts:
1. Michael Moore is a mammal.
2. Michael Moore makes documentaries ALL the time.
3. The purpose of Michael Moore is to flip out
and bash right-wing conservatives.
There has been a lot of noise of late around a new ‘killer’ feature in Solaris 10 called DTrace. Initially I viewed it with some scepticism, but increasily I’m coming to see the huge step forward this is for Solaris. Linux / UNIX has always had a plethora of debugging tools, available to admins
- strace – trace system calls made by a process
- ltrace – trace library function calls made by a process
- mcheck – trace memory allocations
- sar – monitor system resource instrumentation counters
- ps – list processes
- top – monitor processes
- lsof – list open file handles per process
- tcpdump – monitor network traffic
- gdb – trace program execution
- oprofile – monitor program execution via hardware CPU counters
- iostat – monitor filesystem I/O
- vmstat – monitor VM system operation
…but for any typical debugging task, a combination of one-or-more of these tools is required. Tieing together the datasets generated by each tool is possible (most stats are correlated by process ID), but alot of work for the programmer. When threads come into play correlating the data gets even harder. Another aspect of these tools is that they are intrusive to the operation of program being debugged. While a performance hit is acceptable in some cases, the way ptrace() syscall works on Linux can actually cause the programs to crash or behave in abnormal ways.
Enter DTrace. In a nutshell, DTrace provides a single tool that can monitor any aspect of the system, from across both kernel and userspace, system wide, per process, or somewhere in between. This provides an immediate win by removing the need for manual cross-correlation of data from a disperate set of tools. DTrace runtime defines a standard set of many thousands of probes covering all common system events. A simple C-like programming language (with addition of associative arrays and garbage collection) is provided for collecting and processing data when probes are fired. The language is highly optimized & written with safety as a top priority, such that running probes incurrs no overhead or risk to the system being monitored. This allows admins to be confident of using it to diagnose problems on critical production servers.
Enter Linux. So what can Linux provide to answer to DTrace ? In the event it turns out that there are a number of options available, although none quite as comprehensive as DTrace (yet!):
- KProbes – provides an API for inserting probes at arbitrary machine instructions. When the instruction is hit a callback is invoked to perform any required processing & then control returns to the original instruction. An inserted, but inactive probe is a merely 2 instruction overhead.
- DProbes – is a level higher up, using the KProbes functionality. It provides a simple RPN (Reverse Polish Notation) interpreter for creating probe callbacks, the key being safety and efficiency of the callbacks. At a higher level there is a mini-C language which compiles down to RHN. This is close to but not quite as powerful as D, since it lacks garbage collection & associative arrays.
- LTT – is a general purpose Linux tracing toolkit. It can pull together data from a number of sources. One such source is a simple kernel module defining 40 or so events, another source can be DProbes.
There are a number of other tools available with varying degrees of coverage, but nothing really comes close to the polished-perfection of DTrace. Out of all of them, DProbes is probably the open source tool with the most potential, but even that needs more work:
- Safety. Protection is needed to make it impossible for a probe to crash the program being traced
- Ease-of-use. The mini-C language could do with a few higher level features like garbage collectioon, associative arrays, thread local storage
- Documentation. Never underestimate the importance of through documentation (conversely the difficulty of creating good documentation!)
- Probe library. A large library of pre-defined probe points that with stable API across kernel upgrades.
I for one hope that Linux community (& vendors supporting it) realize the value of a polished tool like DTrace and take prompt steps to close the gap to Solaris. For the interested here are more links
Reading the comments on a recent posting about a free certificate authority came across this point about the limitations of the current use of certificates.
Without CA’s and revocation information, SSL-style (RSA) public key infrastructures are useless. That means every client needs access to recently updated and TRUSTED revocation lists to make sure that no cert’s have been forged or stolen. Every meaningful SSL client should periodically verify that any server certificates it uses are and remain valid. Using the CA’s public key is absolutely NOT sufficient.
…the implementation of the certs is screwy, since basically it means nothing at this point other than the fact that you are communicating over SSL. Basically from a browser standpoint the implementation of certificates is completely worthless since the authentication checking is just not there. The X.509 cert’s were originally designed to completely authenticate that you are talking to the host/person you intended to. Since browsers currently do absolutely nothing but a check vs. the public CA key, basically any cert the CA issued regardless of status (other that those that have expired with time) are complete valid certs. They could have been forged, stolen, or otherwise abused but we trust them anyway… Really a sad state of things…. X.509 revocations do exist, but since there really is no universal Public Key Infrastructure (for the non-security guru), or rather the browsers don’t even TRY or HAVE A WAY to validate them in most cases they really don’t mean much at all…
And yet another example of ridiculous application of DRM…curtosy of Laurance Lessig via LWN
Amazon.com is offering an electronic version of the U.S. Constitution aimed at Microsoft’s reader. It’s all nicely equipped with the usual digital rights management stuff; according to Amazon, permission to print the Constitution has been denied.
…if somebody were to get around the DRM and dump a copy of this electronic book onto their printer, it would be a clear violation of the DMCA. For somebody looking for a day in court, it would be harder to find a more desirable case to defend than being charged with printing the U.S. Constitution. Explaining the problems of U.S. copyright law to otherwise uninterested parties has always been a challenge; given enough products like this one, that task is likely to get easier