One of Django applications I maintain is our internal tool used at SUSE used for managing incoming L3 requests. Recently request to add some API arose (read only for now). Looking at available solutions, I came to conclusion that django-piston should be the best choice for me. Adding simple model based API with it is indeed quite simple, all basic information you need is written in getting started part of their documentation. On the other side, things can never go without problems, so I was hit by well known bug. Fortunately fix exists, though it is not yet merged upstream. While digging so deep into problem anyway, I've submitted a request to include this patch in devel:languages:python OBS repo.

Filed under: Django English Suse 4 comments Flattr this!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512

Hello,

I'm transitioning from my 2003 GPG key to a new one.

The old key will continue to be valid for some time, but I eventually 
plan to revoke it, so please use the new one from now on. I would also 
like this new key to be re-integrated into the web of trust. This message 
is signed by both keys to certify the transition.

The old key was:

pub   1024D/FC7F6D0F 2003-07-10
      Key fingerprint = E6A8 8BA0 D28A 3629 30A9  899F 82D7 DF6D FC7F 6D0F

The new key is:

pub   4096R/90BDD207 2012-01-06
      Key fingerprint = 6B85 4D46 E843 3CD7 CDC0  3630 E0F7 59F7 90BD D207

To fetch my new key from a public key server, you can simply do:

  gpg --keyserver pgp.mit.edu --recv-key 90BDD207

If you already know my old key, you can now verify that the new key is 
signed by the old one:

  gpg --check-sigs 90BDD207

If you don't already know my old key, or you just want to be double 
extra paranoid, you can check the fingerprint against the one above:

  gpg --fingerprint 90BDD207

If you are satisfied that you've got the right key, and the UIDs match 
what you expect, I'd appreciate it if you would sign my key:

  gpg --sign-key 90BDD207

Lastly, if you could send me these signatures, i would appreciate it. 
You can either send me an e-mail with the new signatures by attaching 
the following file:

  gpg --armor --export 90BDD207 > timojyrinki.asc

Or you can just upload the signatures to a public keyserver directly:

  gpg --keyserver pgp.mit.edu --send-key 90BDD207

Please let me know if there is any trouble, and sorry for the inconvenience.

(this post has been modified from the example at 
http://www.debian-administration.org/users/dkg/weblog/48)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8GuZoACgkQgtffbfx/bQ9nqACglWyHnDTFQfdKmz8OCd3oL6iR
hcEAmgKJ7RZsgwxwkRGPhygy5y1Ztb+3iQIcBAEBCgAGBQJPBrmaAAoJEOD3WfeQ
vdIHdVQQAMT1yvIogzbtK6sUnWqwbrXI9pDEFk7AzJTb80R+wzxsw7gu9gcBDk8G
BL2O26GKUqKWA3ytuApSl42FJam/Lusi9npT3XNkmHs6FaBMNuLYrqEXmCwXwWr/
OrLyeeLiF4yxgbNWbv+600BqAWqFlo6NeTgQKsJWtCjR3RVMxX3R8nzjDnKJuF+z
c6+2JKBWyx/HVUKcJpJrFDDR36HRFvVJomTuma2JCQ/RAl9vzAguqNYOi1QkuuQv
EF1gXH7gLifukGuwquP1DHP6SWWkj77jtRWr5ewC0xymbrArzAwKbvMQl3VpKBHh
MmpJjYP3ECyL14AKi/TY2Lidi0Sf6yqFMcPcreoih01N0OU0NXmD4IrHMT24/ssb
okDUe1o3YImjGq1jTACvlzC8s54EfLsqDgSP98SGVpuoDqPJUwVk4nuHj8q0vDSs
qZox26gVwB2FAOUi1BFiZbIzM5rsyYfCGyWUGiAwBFf54lYRAeCDCt8iAOOL1Ov/
TumIGYdLoXnDuOJq1VjXLGx2OFDrpyU8SPGoa3zNEVz39tgxQ48ASJEqcqt7HvBy
IW+TTsMLdJ1Ait9aCM3mzzr1iwP8TrL0qUsdRLOE6AKdAqocIfqXY8OeDKhbUiOJ
CXWk5q3xheK3sDWUXX7J63bAAUH4jFnpQEOVMJKBUNMKsWa0iXDS
=mklN
-----END PGP SIGNATURE-----

procps-ng version 3.3.2 was released today. This version fixes some bugs introduced in version 3.3.1 as well as a number of enhancements. Below is the most significant set of changes that 3.3.2 brings. NLS The most visible change is that procps-ng is now international. The NLS changes took a long windy path but we got there in the end. This means all procps-ng programs can now use standard gettext PO files to output in any supported language. While the programs have been enabled for translations, there are no po files as yet but we expect them to follow soon. Library Changes procps always had a closed library, meaning that it wasn t supposed to be used for other non-procps programs. This meant the library was always called libprocps-(version) rather than using a SONAME. Procps 3.3.2 now uses a SONAME of version 0.0.0 The API hasn t changed but it will be in subsequent versions. Patch Backporting Due to the stagnant natute of procps development in the past, there have been a large number of patches each distribution carries for procps. A significant number of patches have been incorportated into procps-ng, giving a more consistent look across the distributions and meaning any subsquent fixes or enhancements are done in one place. A major goal of procps-ng was to reduce the number of distribution specific patches which this change has helped greatly. debian Packages The Debian packages will be worked on soon and will clear up some confusion about the procps binaries and library packages as this will now be split into two. It also means that some programs that depend on libprocps will break, but going on from this point will be able to use the normal shlibs process to manage that, rather than the ugly crunch we will have now.

This is a tiny PSA prompted by my digging into a deadlock condition in the Launchpad application servers. We were observing a small number of servers stopping cold when we did log rotation, with no particularly rhyme or reason. tl;dr: do not call any non-reentrant code from a Python signal handler. This includes the signal handler itself, queueing tools, multiprocessing, anything with locks (including RLock). Tracking this down I found we were using an RLock from within the signal handler (via a library ) so I filed a bug upstream: http://bugs.python.org/issue13697 Some quick background: when a signal is received by Python, the VM sets a status flag saying that signal X has been received and returns. The next chance that thread 0 gets to run bytecode, (and its always thread 0) the signal handler in Python itself runs. For builtin handlers this is pretty safe e.g. for SIGINT a KeyboardInterrupt is raised. For custom signal handlers, the current frame is pushed and a new stack frame created, which is used to execute the signal handler. Now this means that the previous frame has been interrupted without regard for your code: it might be part way through evaluating a multi-condition if statement, or between receiving the result of a function and storing it in a variable. Its just suspended. If the code you call somehow ends up calling that suspended function (or other methods on the same object, or variations on this theme), there is no guarantee about the state of the object; it becomes very hard to reason about. Consider, for instance, a writelines() call, which you might think is safe. If the internal implementation is for line in lines: foo.write(line) , then a signal handler which also calls writelines, could have what it outputs appear between any two of the lines in writelines. True reentrancy is a step up from multithreading in terms of nastiness, primarily because guarding against it is very hard: a non-reentrant lock around the area needing guarding will force either a deadlock, or an exception from your reentered code; a reentrant lock around it will provide no protection. Both of these things apply because the reentering occurs within the same thread kindof like a generator but without any control or influence on what happens. Safe things to do are:

• Calling code which is threadsafe and only other threads will be concurrently calling.
• Performing atomic (any C function is atomic as far as signal handling in Python is concerned) operations such as list.append, or foo = 1 . (Note the use of a constant: anything obtained by reading is able to be subject to reentrancy races [unless you take care ])

In Launchpad s case, we will be setting a flag variable unconditionally from the signal handler, and the next log write that occurs will lock out other writers, consult the flag, and if needed do a rotation, resetting the flag. Writes after the rotation signal, which don t see the new flag, would be ok. This is the only possible race, if a write to the variable isn t seen by an in-progress or other-thread log write. That is all.

About 26-28 hours ago in #debian-release on IRC:

<nthykier> damn, a britney run in 5 minutes
<adsb> they happen
<adsb> you've been spoilt by never seeing b1 at her "finest" *cough*
<aba> you mean, running for more than a day?
<Ganneff> adsb wants night-long runs?
<aba> I can remember runs where we had to block certain packages to
      make sure the run could actually end *sometimes*
<adsb> I'm quite happy with just the memory of that sort of run,
       thanks 
<nthykier> I don't mind being spoiled if it stays at 5 minutes 

I took the liberty of collecting the resulting data for the Britney test suite. In its reduced state[1] in runs in 30 seconds on my machine. It is already my favourite live data sample in the test suite. [1] Only i386 and amd64 are considered, manual hints are ignored etc.

I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances. No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle). I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.

I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances. No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle). I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.

I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances. No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle). I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.

I've been a longtime mutt user, but have gotten somewhat annoyed of having to open a new terminal when I want to read or reply to a Debian bug with mutt (using 'bts show 123456'). How nice it would be to be able to fetch a bug report from within mutt! And so, ladies and gentlemen, I present to you mutt-fetchbug. It's extensively based on Zack's mutt-notmuch script (a nice interface between mutt and notmuch for searching mail, I highly recommend it). By adding a line like the following to your ~/.muttrc, you can simply press "F7" and enter a bug number from your mutt index in order to fetch and display a bug report's mbox file:

    macro index <f7> \
        "<enter-command>unset wait_key<enter><shell-escape>~/bin/mutt-fetchbug --prompt search<enter><change-folder-readonly>~/.cache/mutt_btsresults<enter><enter-command>set wait_key<enter>" \
        "fetch bug(s) (using bts show)"

The above presupposes you've downloaded mutt-fetchbug and placed it with executable permissions in ~/bin. Those interested in making improvements or extending mutt-fetchbug are more than welcome to do so, it's licensed under the GPLv3+. It can be fetched from my git branch. Update: Fixed the broken link to mutt-fetchbug, thanks Christian for the heads up.

Please note that the stats page had some breakage for level 3 these days. This is under repairbut newt translations are still missing as of now.

• 18 (out of 23) languages recover from breakage in partman-zfs
• Swedish completes level 1
• Italian and Ukrainian complete level 2. Italian now fully complete.
• Progress for Hebrew and Indonesian in level 1
• Spanish completes level 3 and now fully complete

Status for D-I level 1 (core D-I files):

• 18 languages 100%: cs de eo es fr it ja kk mr nb nl pl pt ru sk sv uk zh_CN
• 10 languages 99%: bg bs fa gu hi ko si ta te th
• 1 language 97%: eu
• 2 languages 96%: he sr
• 5 languages 95%: ar be bn dz tr
• 4 languages 94%: ast ga id ro
• 5 languages 93%: el hu is km lo
• 1 language 92%: sl
• 4 languages 91%: et pa vi zh_TW
• others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

• 14 languages 100%: cs de es fa fr it kk nl pt ru si sk uk zh_CN
• 9 languages 99%: be bg da eo id ja sl sv th
• 4 languages 98%: ca eu pt_BR ro
• 1 language 97%: is
• 1 language 96%: nb
• 3 langauges 95%: el fi he
• 7 languages 94%: ar ast dz gl hr vi zh_TW
• 8 languages 92%: bn bs hu ko ne pl sr tr
• 9 languages 91%: ga gu ka km lt mk mr ta te
• others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

• 26 languages 100%: be bg bs ca cs de el eo es fa fi fr ga gl is it ja kk nb nl pt ru sk sv th tr
• 4 languages 98%: he hu uk zh_CN
• others are 90% or below

Full 100% completeness (hall of fame) for: Czech, German, Spanish, French, Italian, Kazakh, Dutch, Portuguese, Russian, Slovak

It took me much more uploads than I expected, but ColorHug client is finally in unstable. I was fighting with various bugs, which I could not reproduce locally and of course with my own stupidity in configuring pbuilder. Anyway the buildds overview now shows mostly green, so this is good. The remaining ones mostly wait for libgusb, which needs build on armhf and needs to be ported to non Linux (or rather libusb needs to exist there). One of things I've learned on the way is that docbook-utils is not enough to convert docbook to man pages, you need docbook package as well. Still I don't understand why this did locally work for me... The one outstanding issue is that client code assumes it runs on little endian host (or rather same endianity as the ColorHug device) and thus will break on PPC and other big endian machines. The upstream is aware of that an I even managed to produce patch which should fix it, though I have no means to test it (lack of big endian hardware and lack of the ColorHug device itself).

Filed under: Debian English 4 comments Flattr this!

In KDE e.V. (which is to KDE</kde> what SPI is to Debian, Jenkins and others) there is some times a need to vote. For example about accepting new members. Mostly about accepting new members. With the new vote system (ballot.kde.org), voters need to do a bit more to check their votes afterwards. basically

• Take username
• Your own secret
• The vote token

and sha256 it in the right order with the right separator chars and so on. All sha256 sums are published together with where the vote was, so voters can verify that they are counted correctly. After failing to construct a couple of times on the command line, I decided to write a small GUI app to help me instead. There it is. Nice. Simple. Effective. Sources available. http://quickgit.kde.org/?p=scratch%2Fsune%2Fkrapyl.git&a=summary have fun, and remember to verify your votes.

In KDE e.V. (which is to KDE</kde> what SPI is to Debian, Jenkins and others) there is some times a need to vote. For example about accepting new members. Mostly about accepting new members. With the new vote system (ballot.kde.org), voters need to do a bit more to check their votes afterwards. basically

• Take username
• Your own secret
• The vote token

and sha256 it in the right order with the right separator chars and so on. All sha256 sums are published together with where the vote was, so voters can verify that they are counted correctly. After failing to construct a couple of times on the command line, I decided to write a small GUI app to help me instead. There it is. Nice. Simple. Effective. Sources available. http://quickgit.kde.org/?p=scratch%2Fsune%2Fkrapyl.git&a=summary have fun, and remember to verify your votes.

One of the GNOME features I really liked since the beginning of my GNOME usage is the ability to mount various network file system by a few clicks and keystrokes. It enables me to quickly access NFS shares or files via SFTP. But so far these mounts weren't actually mounts in a classical sense, so they were only rudimentary useful.

As a user who often works with terminals I was always halfway happy with that feature and halfway not:

- Applications have to be aware and enabled to make use of that feature, so its often neccessary to workaround problems (e.g. movie players not able to open a file on a share)
- No shell access to files

Previously this GNOME feature was realised with an abstraction layer called GNOME VFS, which all applications needed to use if they wanted to provide access to the "virtual mounts". It did no efforts to actually re-use common mechanisms of Un*x-like systems, like mount points. So it were doomed to fail at certain degrees.

Today GNOME uses a new mechanism, called GVFS. Its realized by a shared library and daemon components communicating over DBUS. At first glance it does not seem to change anything, so I was rather disappointed. But then I heard rumors, that Ubuntu was actually making these mounts available in a special mount point in ~/.gvfs.
My Debian GNOME installation were not.

So I investigated a bit and found evidence about a daemon called gvfs-fuse-daemon, which eventually is handling that. After that I figured this daemon to be in a package called gvfs-fuse and learned that installing it and restarting my GNOME session is actually all needed to do.
Now getting shell access to my GNOME "Connect to server" mounts is actually possible, which makes these mounts really useful after all. Only thing to find out is, if e.g. the video player example now works from Nautilus. But if it doesn't I'm still able to use it via a shell.

The solution is quiet obvious, on the one side. But totally non-obvious on the other.

A common user eventually will not find that solutin without aid. After all the package name does not really suggest what the package is used for, since its referring to technologies instead of the problem it solves. Which is understandable. What I don't understand is, why this package is not a dependency of the gnome meta package. But I haven't yet asked the maintainer, so I cannot really blame anybody.

However: Now GVFS is actually useful.

I ve got some performance problems with a mail server that s using DRBD so I ve done some benchmark tests to try and improve things. I used Postal for testing delivery to an LMTP server [1]. The version of Postal I released a few days ago had a bug that made LMTP not work, I ll release a new version to fix that next time I work on Postal or when someone sends me a request for LMTP support (so far no-one has asked for LMTP support so I presume that most users don t mind that it s not yet working). The local spool on my test server is managed by Dovecot, the Dovecot delivery agent stores the mail and the Dovecot POP and IMAP servers provide user access. For delivery I m using the LMTP server I wrote which has been almost ready for GPL release for a couple of years. All I need to write is a command-line parser to support delivery options for different local delivery agents. Currently my LMTP server is hard-coded to run /usr/lib/dovecot/deliver and has it s parameters hard-coded too. As an aside if someone would like to contribute some GPL C/C++ code to convert a string like /usr/lib/dovecot/deliver -e -f %from% -d %to% -n into something that will populate an argv array for execvp() then that would be really appreciated. Authentication is to a MySQL server running on a fast P4 system. The MySQL server was never at any fraction of it s CPU or disk IO capacity so using a different authentication system probably wouldn t have given different results. I used MySQL because it s what I m using in production. Apart from my LMTP server and the new version of Postal all software involved in the testing is from Debian/Squeeze. The Tests All tests were done on a 20G IDE disk. I started testing with a Pentium-4 1.5GHz system with 768M of RAM but then moved to a Pentium-4 2.8GHz system with 1G of RAM when I found CPU time to be a bottleneck with barrier=0. All test results are for the average number of messages delivered per minute for a 19 minute test run where the first minute s results are discarded. The delivery process used 12 threads to deliver mail.

	P4-1.5	p4-2.8
Default Ext4	1468	1663
Ext4 max_batch_time=30000	1385	1656
Ext4 barrier=0	1997	2875
Ext4 on DRBD no secondary	1810	2409

When doing the above tests the 1.5GHz system was using 100% CPU time when the filesystem was mounted with barrier=0, about half of that was for system (although I didn t make notes at the time). So the testing on the 1.5GHz system showed that increasing the Ext4 max_batch_time number doesn t give a benefit for a single disk, that mounting with barrier=0 gives a significant performance benefit, and that using DRBD in disconnected mode gives a good performance benefit through forcing barrier=0. As an aside I wonder why they didn t support barriers on DRBD given all the other features that they have for preserving data integrity. The tests with the 2.8GHz system demonstrate the performance benefits of having adequate CPU power, as an aside I hope that Ext4 is optimised for multi-core CPUs because if a 20G IDE disk needs a 2.8GHz P4 then modern RAID arrays probably require more CPU power than a single core can provide. It s also interesting to note that a degraded DRBD device (where the secondary has never been enabled) only gives 84% of the performance of /dev/sda4 when mounted with barrier=0.

	p4-2.8
Default Ext4	1663
Ext4 max_batch_time=30000	1656
Ext4 min_batch_time=15000,max_batch_time=30000	1626
Ext4 max_batch_time=0	1625
Ext4 barrier=0	2875
Ext4 on DRBD no secondary	2409
Ext4 on DRBD connected C	1575
Ext4 on DRBD connected B	1428
Ext4 on DRBD connected A	1284

Of all the options for batch times that I tried it seemed that every change decreased the performance slightly but as the greatest decrease in performance was only slightly more than 2% it doesn t matter much. One thing that really surprised me was the test results from different replication protocols. The DRBD replication protocols are documented here [2]. Protocol C is fully synchronous a write request doesn t complete until the remote node has it on disk. Protocol B is memory synchronous, the write is complete when it s on a local disk and in RAM on the other node. Protocol A is fully asynchronous, a write is complete when it s on a local disk. I had expected protocol A to give the best performance as it has lower latency for critical write operations and for protocol C to be the worst. My theory is that DRBD has a performance bug for the protocols that the developers don t recommend. One other thing I can t explain is that according to iostat the data partition on the secondary DRBD node had almost 1% more sectors written than the primary and the number of writes was more than 1% greater on the secondary. I had hoped that with protocol A the writes would be combined on the secondary node to give a lower disk IO load. I filed Debian bug report #654206 about the kernel not exposing the correct value for max_batch_time. The fact that no-one else has reported that bug (which is in kernels from at least 2.6.32 to 3.1.0) is an indication that not many people have found it useful. Conclusions When using DRBD use protocol C as it gives better integrity and better performance. Significant CPU power is apparently required for modern filesystems. The fact that a Maxtor 20G 7200rpm IDE disk [3] can t be driven at full speed by a 1.5GHz P4 was a surprise to me. DRBD significantly reduces performance when compared to a plain disk mounted with barrier=0 (for a fair comparison). The best that DRBD could do in my tests was 55% of native performance when connected and 84% of native performance when disconnected. When comparing a cluster of cheap machines running DRBD on RAID-1 arrays to a single system running RAID-6 with redundant PSUs etc the performance loss from DRBD is a serious problem that can push the economic benefit back towards the single system. Next I will benchmark DRBD on RAID-1 and test the performance hit of using bitmaps with Linux software RAID-1. If anyone knows how to make a HTML table look good then please let me know. It seems that the new blog theme that I m using prevents borders. Update: I mentioned my Debian bug report about the mount option and the fact that it s all on Debian/Squeeze.

• [1] http://doc.coker.com.au/projects/postal/
• [2] http://www.drbd.org/users-guide/s-replication-protocols.html
• [3] http://support.dell.com/support/edocs/storage/7j376/specs.htm

Related posts:

1. I need an LMTP server I am working on a system where a front-end mail...
2. Some Notes on DRBD DRBD is a system for replicating a block device across...
3. paper about ZCAV This paper by Rodney Van Meter about ZCAV (Zoned Constant...

By now hopefully you got a chance to see my Jeopardy! episode so it won't be much of a spoiler to mention that I didn't win. It went like this. I flew into LA on the night of October 31st. The taping was to take place on the next two days. Jeopardy! tapes two weeks of shows, two days a week for a total of 10 episodes. Contestants are randomly chosen for one of those 10 episodes but you don't find out which one you will be on until the last minute. Randomness and secrecy have become become a big part of the production process in games since the quiz show scandals of the 1950s. (Interesting fact: it is a Federal felony to tamper with a TV game show.) There were a group of just under 20 0f us altogether waiting to go on. All very nice people. Here in the New York area one tends to equate very intelligent people with "Type A" personalities but we got on well together. Interspersed between the tapings, we had short practice sessions to familiarize ourselves with the studio setup and this is where I first started getting a little apprehensive. Jeopardy! is not just about general knowledge, there is a physical element too in that you have to buzz in by pressing a button on a stick which is wired up to some producers console. You can't buzz in before Alex has finished reading the question and obviously you can't buzz in if someone is already answering the question. If you buzz at the wrong time, your buzzer locks for 0.75 seconds so just jamming your finger on the button. I didn't even get that far as on the entire first day I failed to buzz in at all despite changing hands, changing grip different ways and other strategies. I was pretty despondent by the second day but then miraculously I managed to get the hang of it. So when I was finally selected (for the 3rd game of that day.) I was back to my usual cool self. I was up against Dave Leach and Nicholas Campiz who were returning after having tied in the previous game. And the game did start well enough. Oh one thing you may notice is that Alex mispronounces my name Jaldhal. I knew he did that once or twice and even mentioned it to a producer but it was only viewing the episode right now that I see he does it consistently. I assumed such things would be fixed up in post-editting but I guess not. Oh well, after living in this country for so many years I've learned to be happy whenever two consonants are more or less in the right place. This particular mispronunciation is actually fairly common, even Indian people have been known to make it. The alternative theory is that Alex couldn't read my horrible handwriting which is also plausible. Anyway, I digress. I started off fairly well. My first mistake was in a category about alcoholic drinks. I answered vermouth when the correct response was gin. In my defense I'm a strict teetoler so none of these words mean anything to me. I also earned the disapproval of my superhero fan son by mistaking Dr. Strange for Dr. Doom. I did get the one about Spiderman villain Dr. Octopus so that mollified him somewhat. The highlight of my evening was strangely enough in a category about books of the Bible. I got a Daily Double. It was a risky move but I have always wanted to make a "true" daily double so I threw caution to the winds and wagered everything I had. To my surprise as much as anyones, got the answer right doubling my score. I was in a pretty good position for the Double Jeopardy but thats when Dave started dominating. If you haven't been watching previous games, Dave Leach is arguably the best player this season. Not only is he smart but he is almost supernaturally fast on the buzzer. You can't see because I kept my hands behind the podium but I again and again I would desperately try to ring in on a question I knew the answer to only to be beaten to the punch by Dave. This caused me to start getting a bit reckless and answering questions where I was less than certain which cost me dearly. One particularly dumb mistake was in a category where all the answers were supposed to start with the letter g. I said compass when I should said gyrocompass but actually I should have left that category alone entirely. By the time Final Jeopardy came around winning was no longer an option as Dave was too far in the lead. I was slightly ahead of Nicholas in 2nd place. This is where I again made a strategic error. My original plan to bet nothing in Final Jeopardy but the category was "1930s Novels" and I liked my chances. The clue was read out and it involved an anti-war novel whose author was blacklisted. I was elated. It had to be "All Quiet on the Western Front" right? The blacklist bit gave me pause as the author Erich Maria Remarque was German and this was obviously a reference to the anti-Communist blacklist in the 1950s USA. But somehow I remembered that he had spent the end of his life in Hollywood or maybe I just convinced myself that it was plausible. Evidently my thought process wasn't too crazy because all three of us came up with the same answer. All three of us were wrong. The correct answer was "Johnny Got His Gun" by Daltan Trumbo. In hindsight I knew this but it illustrates the strange ways the mind works. I knew because the video for Metallicas song "One" from "...And Justice for All" is based on the film adaptation of this book. However in a previous orientation session the lady who is the contestant coordinator for Jeopardy! had mentioned AQOTHWF as anexample of something and this got stuck in my brain crowding out the previously known fact. So when all was said and done I ended up in 3rd place. (I bet big whereas Nicholas was more conservative.) Oh well. Despite not winning I had a blast. I fulfilled my dream of appearing on Jeopardy! I met Alex Trebek. (And I should be receiving an autographed picture of us together soon.) My witty banter was sufficiently witty. I made enough money to cover my travel expenses and still have a nice amount left. And I got to meet lots of interesting and wonderful people. So I'm satisfied.

Probably most of you already heard about weakness in Wifi Protected Setup discovered recently.
Using it you can reduce PIN authentication probes from 100000000 to only 11000 making brute force attack possible and reveal password to network in about 4 hours (usually even sooner). Most AccessPoints are vulnerable thus with this attack you can brute-force almost any network around. Doesn t matter if it uses WPA/WPA2 nor which method PSK/Radius. It only needs to be WPS enabled and most of APs are. I ve just packaged reaver-wps tool for Debian (I m also an author of its ArchLinux PKGBUILD) and it s now waiting in new queue. If you want to try it before it enters unstable I put it also on my people.debian.org account.
After installing it all you have to do is enable monitor mode in your wifi card (you need aircrack-ng package for that):

airmon-ng start wlan0

Then start attack:

reaver -i mon0 -b xx:xx:xx:xx:xx:xx -vv

Of course name of interfaces may differ as their depend on your wifi driver. After -b switch you have to enter BSSID of the target AP. That s all. Happy ha^Wcracking I wonder if it really enter Debian archive, cause it s shipped with several libraries already included in Debian. Mainly Linux Wireless Extensions library, and some part of wpa-supplicant package (this are at least slightly modified). In fact there are chances that reaver will became the part of the aircrack-ng suite (they discuss it already), but that won t happen soon, so it still would be great to have this package in Debian.

I recently completed "Ready Player One", Ernest Cline's debut novel. It's a Sci-Fi fan-service novel that explores a dystopian future (yes, another one) where the majority of the populace hide inside a VR environment to escape their "real" lives. The sole-genius who authored the VR software hid a series of easter eggs inside, in the form of challenges relating to pop-culture and video game trivia circa the 80s. He constructs his will such that whoever first completes the challenges inherits the mega-bucks company who control the VR simulation. Mike Hoye has an excellent summary:

Ready Player One is a nerdculture bender of a book, about as hard to hate while you re in the middle of it as it is to love in hindsight; it s young adult literature for people who were born in the late seventies and haven t really grown up yet. Of which I am apparently one, it has become clear, but you re still left with the sense that you re reading a Cory Doctorow book whose discerning virtue is that the lead isn t a thinly-veiled Cory Doctorow. Which is a huge, huge improvement, make no mistake, but it s stills relentless, pandering fanservice.

(Whilst you are over on Mike's website you should really read this excellent piece on libraries and publishers.) Despite the points above, I enjoyed the book. My biggest complaint was that the ending was quite abrupt. Quite often when I read a story which is essentially about a journey, I am disappointed if the story ends when the journey does. I hope I am not spoiling too much here by revealing that someone eventually solves the riddles and inherits essentially the earth. But what do they do with it? What impact do they make on the miserable world, described only briefly in sparse passages dotted around the bulk of the text detailing the VR one? During the book, the characters opine on what to do with the fortune, but we never see that come to fruition. Perhaps in a sequel.

My post yesterday on how Google gains financial benefit from vendor GPL violations contained an assertion that some people have questioned - namely, "unscrupulous hardware vendors save money by ignoring their GPL obligations". And, to be fair, as written it's true but not entirely convincing. So instead, let's consider "unscrupulous hardware vendors have economic incentives to ignore their GPL obligations".

The direct act of compliance costs money
Complying with the GPL means having the source code that built the binaries you ship. This is easy if your workflow involves putting source in at one end and getting binaries out at the other, but getting to that workflow means having a certain degree of engineering rigour. If your current build process involves mixing a bunch of known good binaries you got from somewhere but you can't remember where with a hacked up source tree that exists on someone's hard drive and then pushing all of these into a tool that only runs on Windows ME, before taking the resulting image and replacing chunks of it by hand, compliance is effectively impossible.

We all know that this is against all kinds of best practices and probably causes so many problems that it's more expensive in the long term, but retooling and hiring someone to oversee all of this takes time and money, and given the margins on many of these devices that's probably enough to make you uncompetitive for a couple of product cycles. Maybe you'll be in a better position afterwards, but you don't know that there'll be an afterwards.

Suppliers who don't provide you with the source code may be cheaper than those who do
You can't be in compliance if you don't have the source code in the first place. The same arguments that apply to the hardware vendors also apply to the people selling you your chips, so there's also an economic incentive for them to avoid complying. And there's an obvious incentive for you to choose the cheaper chipset, even if they don't comply.

Getting the source may cost money
Buying a chipset doesn't necessarily get you the software that makes it work - several silicon vendors will charge you for the SDK. But many of these devices are effectively reference platforms, so are basically identical from a hardware perspective. So if one of your competitors paid for the SDK, you can just dump the binaries off their machine, flash them onto your own boards and save yourself a decent amount of money. You obviously don't get the source, and nor do you have the standing to insist that the vendor whose binaries you misappropriated give you the source.

In the absence of enforcement, GPL compliance only works if it's the norm
Let's imagine two companies, A and B. Both build a tablet device, and buy the full SDK including source code. Both find a bunch of bugs in the vendor SDK and fix a different subset of them. They ship. A provides source code. B doesn't. B can now take A's bugfixes and incorporate them, resulting in a more compelling product without any significant extra cost. You now have two products that can sell for the same price, but B's is better. A would need to prove that B copied their bugfixes rather than simply fixing them themselves , which probably isn't going to happen.

In a larger market, if B is the only vendor who does this then their advantage isn't large - some of A's work is misappropriated by B, but A does benefit from the engineering work contributed by C, D, E, F and G. A combination of social pressure and legal threats may bring B into compliance. But if infringement is the norm, A has no incentive at all to release the source - by doing so they'll be helping not only B, but also C, D, E, F and G. Everyone undercuts A and they go out of business quite quickly.

Moral: In the absence of enforcement, if everyone else is infringing, a single company who complies is at a disadvantage.

If compliance cost nothing then everyone would do it
You can argue that cheap tablets from China are infringing simply because nobody knows better. But what's HTC's excuse? They've clearly decided that there's a benefit in holding back their source code releases[1], balancing this against the risk of being sued. They know full well what they're doing. If compliance was free they'd ship the source at the same time as they shipped the binaries. Other significant vendors are also fully aware of their obligations but choose to ignore them anyway.

Summary
There are economic incentives to infringe the GPL, and therefore (all else being equal) an infringing device can be sold for less money. All else being equal, a cheaper device will sell more units. More sales means more devices selling adverts for Google. Google makes more money because Android vendors infringe the GPL.

Edited to add:

But don't just take my word for it - Jean-Baptiste Queru says the same here (search for "scrubbing" - is there any way to link directly to a Google plus comment?)

[1] The usual argument is "We will release the source code within 120 days", implying that it's a process that takes time and we should just be patient. Every single time I've started making threatening noises, the source has appeared within a week.

comments

uTidyLib is definitely something you would call a dead project - no new release for seven years, dozens of open bugs and submitted patches and no active development. On the other side it is still used by several packages in Debian, thus worth maintaining. This is also reason, why there are few crucial patches in Debian repository to make it work (for example on 64-bit architectures). While googling whether there is something new going on with uTidyLib, I've noticed two efforts. One is PyTidyLib, a complete reimplementation, which provides different API and thus does not seem to be used anywhere yet. Another (well almost two years old, but I did not look earlier) effort is to fork in on Github and make it work with MacOS X. Okay, when somebody took the "effort", lets try to merge Debian patches there, hopefully there will be a release sometimes. So here is the pull request. Update: I've just learned, there is another fork going on - https://github.com/lachlan-00/utidylib2

Filed under: Debian English 0 comments Flattr this!