Saturday, December 25, 2010

Question to Google

Dear Madam or Sir,

As of today, Dec. 25, 2010, the Google Terms of Service in paragraph 8.3 seems to allow Google to censor the content provided by users. It does not have a reference to overriding documents.

My concern is about email usage. Also as of today, Gmail's terms do not touch on the issue and in fact refer back to that same document which seems to allow censorship.

Does that mean that Google acquired the legal capacity to censor any materials it wants in emails? Please, note, that I am not asking about an intent, but about the current legal capacity granted by users who accepted the above mentioned terms and conditions.

Sincerely,
Vlad Didenko

Sunday, September 12, 2010

Meta-creation, anyone?

Why some religions are so anti-evolution? Would not God which created (programmed) such simple and cool evolution rules be cool? Kinda, meta-creation-cool? I mean, that may move dogma a bit, but it may actually win some extra friends, would not it?

Friday, September 10, 2010

Pain Ray from Raytheon

The NPR story on the Raytheon device followed today the ongoing ACLU reporting and the specific coverage of the terrible invention.

Very, horribly bad development. Patching the result, not the root cause of the problem - and deteriorating the society in process. The device's safety is absolutely unclear. We are still convinced that microwaving eye's cornea to 2/3 of it's depth is a bad thing. Witness accounts tell that is feels like scalding their skin. Would anyone consider scalding one's eyes healthy? Other health concerns are posted in the same ACLU article.

But the worst effect is the moral one, mentioned by some commenters to the NPR story. Using the device is like a video game for prison staff - they are removed from the action. It is an ultimate humiliation and indignity for inmates, being tortured by a human "above them". The device application is not improving inmates' social outlook, it's making them feel whipped animals and gives a moral "permit" to be anti-social. All because bureaucrats mis-balanced prison occupancy and laws and now quick-fixing their mistakes at the expense of human lives.

Zimbardo's study is directly applicable here with it's effects and discoveries.

The other issue is that the NPR story is very unbalanced, showing lots of "pro" material and no elaboration on "cons" considerations. We hope NPR sticks to better reporting.

Tuesday, August 31, 2010

Locking daemons in bash

NOTE: Scripts in this post were tested in CentOS release 5.3, Ubuntu 14.04 and may not work in other Unix dialects. For example, flock(1) utility is absent from OS X 10.6.

TL;DR

Shell scripts designed to have only one copy running often require manual clean-up after an ungraceful shutdown or process crash. This solution provides a "self-cleaning" alternative. The full example script is posted on the gitHub page. Run two instances of the script to see it work. As a script writer you are still responsible for any other resource cleanup to achieve a proper startup.

Details

When writing a daemon shell script we traditionally use *.pid files to store the process ID for later use and to avoid multiple copies running simultaneously and potentially colliding. The common pattern of such use is:

self=$(basename $0)
lock=/tmp/${self}.pid
if [ -f ${lock} ]
then
    echo "Another copy of ${self} potentially running." >&2
    echo "Check the ${lock} lock and remove if necessary." >&2
    exit 1
else
    echo $$ >${lock}
    trap "rm -f ${lock}" EXIT
fi

The problem with this approach is that after a process or system crash the lock is stale and the new copy of the daemon will not start without manual cleanup.

Another approach, documented in the flock(1) man page and used by system programmers all along, is to use a process file descriptor locked exclusively on a “pid” file. In this case, the pid file becomes a bearer of the lock instead of being a lock itself. A file descriptor lock on a file exists only as long as the file descriptor is alive. When file descriptor owner processes die, the file descriptor is destroyed together with file locks associated with it. In essence, the process holds the lock in it's memory, not in file, and lock is cleaned by the operating system when the process quits or dies. That solves the crash problem of the first approach.

Let’s look at the code:

1:   pidf=/tmp/${self}.pid                 # Define lock file name
2:   exec 221>${pidf}                      # Open the file with descriptor 221
3:   flock --exclusive --nonblock 221 ||   # Attempt to acquire the lock
4:   {
5:       # Lock acquisition failure code   # Your custom error handler here
6:       exit 1                            # optionally exit the script
7:   }
8:   echo $$ >&221                         # Put the PID in lock file

After this block of code, the .pid file has a lock from the current process and it’s new children. Children receive the lock with file descriptors, which they inherit from the parent.

To release the lock, one can either close all file descriptors holding the lock, or use the /sbin/flock --unlock ... command to explicitly release the lock.

A user may check the presence of a lock on a file using the fuser(1) utility:

$ /sbin/fuser -v monitord.pid

                     USER       PID ACCESS COMMAND
monitord.pid:        auser    28576 F....  monitord
                     auser    28579 F....  ping

Note, that line 8 of the locking code which stores PID of the locking process in a .pid file is redundant, as the information can be retrieved for the lock itself. It is only stored in the file for convenience later in the code, when we need to use the PID to inquiry or manage the process. It is very important to note, that a mere presence of the .pid file in this arrangement does not mean, that the lock is active. It only records a PID of the process which currently holds the lock or was the last one to hold it.

To programmatically test for the presence of the lock we need to attempt to grab the lock. If we fail, then there was another lock already on the file. If we succeed, then there was no lock on the file. In any case we need to close the file descriptor to avoid inadvertently holding the lock ourselves.

if flock --exclusive --nonblock 232 232<${pidf}
then
    echo "Open"
else
    echo "Locked"
fi
exec <&232-

This testing technique is only good to test the presence of the lock. It is more convenient to use the fuser(1) utility to send KILL or other signals to locking processes, like this:

/sbin/fuser -k ${pidf}

The fuser utility will send the kill signal to all processes with file descriptors holding the lock, which should take care of the parent and children processes, if any.

There is more to graceful daemon writing in bash. Other topics are logging with rotation, sleeping, and configuration. Be mindful that these issues do not magically disappear when using bash - you need to address them just like you would when writing any other program.

Friday, July 2, 2010

Introducing DB Relay

DB Relay is an open source project built around the NGiNX web server platform, providing an HTTP/JSON interface to a variety of database servers. It enables database access without drivers and web application development without middleware. Designed for operational efficiency and ease of maintenance. In this session we will introduce DB Relay and show how to deploy and use it for back-end scripting and intranet web development.

After quite some time in development we are finally going public and open-source with the DB Relay. Stop by our booth #520 at OSCON EXPO and come listen to the «DB Relay: An Introduction» session at the OSCON Conference.

See you in Portland!

Sunday, May 23, 2010

If Code is Law ...

Does it mean, that:
customerselectorate
usersconstituency
developerslegislative branch
testersjudicial branch
operationsexecutive branch
help desklaw enforcement

Thursday, March 18, 2010

Square display

When it comes to convenient display hardware I have always been perplexed with the absence of square displays.

When per pixel cost in the past was dis-proportionally high, companies would naturally try to maximize usability of one dimension while saving a buck on another. That lead to such inflexible solutions as rotating displays and ugly L-shaped dual display setups.

These days, when pixel density is high enough and Apple iMac 27" has resolution of 2560 by 1440 pixels at a very affordable price in the system, why would not one want a square display matching length of a modern 24-incher? Accidentally, a pixel count of 1920 by 1920 exactly matches that of the Apple's 27" screen - both are 3,686,400 pixels.

Think about it. You would loose that annoying feeling that you need a different orientation when you need it most. When viewing documents, you would have extra vertical space for tool palettes, widgets, instant messenger, whatnot. You would have enough real estate for two documents side-by-side, just like on a landscape 24" display, only better. A square display may be less conducive to maximizing windows thus actually helping your work flow. And that clunky screen rotating hardware and software - oh, please, you won't miss that, right?

I do photo. What is my primary show-off media? Correct, screen saver and slide shows. All my screens happen to be landscape these days and guess what? I rarely frame portrait images now. Even portraits. I would definitely think more flexible given a square display. Display is not a frame, it is a canvas. One can put either landscape or a portrait orientation object on a square canvas - be it an image or a software window.

I am not a manufacturing guy so I do not claim to know all the intricacies or potential problems of a square LCD matrix production. I also may not be a fan of a square display laptop. But I had a silly hope that the anticipated Apple's iPad would be square. Because it is useful. And because it mitigates complexity and unnecessary choice.

And for that I would vote any time.

Saturday, March 6, 2010

LXD

Would love to see these dancers in Chicago: http://www.youtube.com/watch?v=rrxOBxlQmho&hd=1. Hope they tour with the show The LXD.

Monday, February 15, 2010

Practical math education

Can not agree more with the TED presentation from Arthur Benjamin (below). Essentially he argues that proficiency in statistics, probability, and meaning of data(sets) should be the pinnacle of high school math education.

I never used differential equations in professional life, yet standard deviations needed monthly. Even when it comes for common knowledge meaning of data is a more common necessity than analytics.

Another case in point - Nancy Etcoff stated on the 45th second of her TED talk that there are "Over 120 million prescriptions for antidepressants". Well, considering that US population is approaching 309 Million at the time of this writing, it is hard to make sense of Ms. Etcoff's number of prescriptions without further context if you are alert about meaningful data.

Here is the Athur's presentation:

Sunday, January 3, 2010

Tacit collusion (a.k.a. uncommunicative cartel)

I was reading up on the concept of Tacit collusion (when firms agree to play a certain strategy without explicitly saying so), when watched the TED presentation of Steven Strogatz on sync. The metronome test (starting around 12:20) struck me as a profound mechanical analogy of the type of hidden communication which facilitates tacit collusion.

The Wikipedia article focuses on pure and obvious price cycles. The Strogatz's demo makes one wonder, if there are deeper underlying mechanisms, like supply chain cycles, talent and inventors contributions to an industry, legal events, and alike, which make companies to stay on the same wave without realizing it?

As far as I understand, the capitalism society works best, when companies have the minimal possible price synchronization horizontally in their industry - that is when the competition is at it's best. The multi-trillion question is: does an industry innovation and the capitalism society are better off when those underlying mechanisms from the above go out of sync? Which mechanisms may encourage such beneficial de-synchronizations?

Here is the Strogatz's demo: