Wednesday, May 28, 2008

Mechanics puzzle

Here is a nice mechanics puzzle: provide an example of the body which has non-zero momentum but whose kinetic energy is zero.

So far only one of my fellow physicists found how can it be. Feel free to leave your versions in comments. If you gave up, watch the 16th lecture by prof. Walter Lewin of MIT.

Anyway, Lewin's lectures are awesome!

Wednesday, May 21, 2008

Impressions from Sun University Day

I learned many interesting things from Sergey Pikalev's talk about Solaris, but I dislike the style of the talk. Instead of presenting slides, Sergey made all the examples in real-time in the terminal. Obviously, this caused inevitable delays and tired the public.

As far as I know, Python seminar Exception #08 will be held in similar fashion in a few days. Looking forward to hear their impressions about this form of presentation.

Returning to Solaris: its service manager reminded is similar to NixOS idea of building the whole system configuration from the nix expressions (except nix expressions are much more powerful then Solaris' XML, and also much more human-friendly).

Sergey also talked about zones and ZFS, but didn't cover dtrace.

The next talk was about NetBeans and using Java in corporate environment. I got an impression of Java being bureaucratic programming platform and left the seminar.

Sunday, May 18, 2008

Security is our common problem

When I found out about DSA-1571, I immediately upgraded my openssl package and regenerated ssh keys.

In a few days I received notification from code.haskell.org admins, which informed me that my code.haskell.org account is blocked due to the compromised ssh key (they checked all keys against ssh blacklist, provided by Debian). I installed that blacklist too, and my key really appeared to be weak. I tried to regenerate keys several times, and all of them were in blacklist.

Finally I figured out the problem: I upgraded openssl, but didn't touch libssl and openssh packages. From the one point, it was my fault -- I didn't upgraded all vulnerable packages. From the other, this problem could be avoided by bumping dependency versions, so that leaving vulnerable versions would be unacceptable by package manager. In any case, today you cannot just rely on software writers and maintainers and feel secure.

Tuesday, May 13, 2008

Sun University Day in Odessa

Sun University Day in Odessa

I'm going to attend the talk about OpenSolaris.

Anybody else?

Sunday, May 11, 2008

#gsoc

eth01you don't need to ask, just do it imo
eth01remember this is the internet, people can't physically attack you
r0bbyeth01: until a protocol is invented

Monday, May 5, 2008

DVCS experience

Together with Ivan Veselov we are going to write an article. Living in XXI century, we certainly are going to use distributed version control system. But it appeared not so simple...

The best workflow I could think of is just sending patches by email. In the case of two peers it's more comfortable than holding some "central" repository, as commonly done for larger communities.

However, none of popular DVCS'es seems to be able to satisfy my requirements. There are just three of them: respect locales (we use cyrillic in UTF-8 locale), no published repository, all patches are sent in one email.

So, here is our experience:

darcs
I really enjoyed darcs send experience while working on xmonad, but in our case darcs got confused by the absence of the remote repository:
% darcs send

darcs failed:  Missing argument:  [REPOSITORY]
We had some discussion on #darcs, and several workarounds were proposed, but I didn't like them (and was really upset).
mercurial
Mercurial (with patchbomb extension from Bryan O'Sullivan) feels ok even if there's no remote repository, but it sends one email per commit. There's an option --bundle, but it uses some binary format, and also with this option for some reason hg starts to complain about the absence of remote repository. Another problem with hg is that it does something terrible with cyrillic when patches are sent by mail, so it isn't actually usable in our case
git
Git appeared the best today. The only its shortcoming is one-email-per-commit. At least it deals well with cyrillic and does not expect some remote repo. And I know that given enough time I can write alternative to git-send-email which will behave as I want. Unfortunately, we don't have much time at the moment.

Sunday, May 4, 2008

Programming competitions

I've just returned from Vinnica, where complex olympiad in mathematics, physics and informatics was held. I was working in mathematical jury, but it was also interesting to observe the «informatical part» of olympiad. There was two competitions: individual and command one.

What I dislike about those competitions (but as far as I understood, this is common, at least for Ukraine):

  1. There's a strong limitation on language: it's either Pascal (Borland or Free Pascal) or C/C++ (Borland C or GNU C++). I don't think that many pupils know other languages, but on the other hand this discourages pupils to learn other languages. Otherwise pupils would certainly get interested in languages where you don't need to manage dynamically allocated memory or implement bignums by hand.
  2. There's a limitation on execution time of your solution. Yes, execution time of your program compiled with some (unknown) compiler with some (unknown) flags and run on some (unknown) hardware.
    But ok, let's suppose that participant can roughly predict his execution time. How much time does he get? When one pupil asked jury, he got answer «twice the time of the author's solution». Unknown! And no, participants cannot even test their work until competition ends (to find out whether they satisfy the time limitations).

The best form of programming competitions I've ever seen is the one used in Project Euler.

It would be also interesting to hold the «programming tournament» in the form similar to physics tournament. What can be discussed is mathematical proof of correctness, O-big asymptotics, optimizations etc.