Computing notes 2014 part one

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

140628 Sat: Advantages and disadvantages of IPS and VA panels

While IPS and VA panels have many variants, they are of broadly similar quality, and the main difference between VA and IPS panels are:

Defective pixels can only be stuck dark in IPS panels, but they can be stuck bright in VA panels.
Both VA and IPS panels tend to be slower at updating pixels than TN panels, and VA ones are a bit slower than IPS ones.
IPS panels have slightly better viewing angles tha VA panels as VA panels usually a bit more contrast at wide angles of view.
With dark shades IPS results in a slight glow when viewed off center, while VA panels give them a slight purple glow when they are viewed directly.
IPS usually give somewhat better color reproduction than VA.
VA usually gives much higher contrast than VA, due mostly to deeper blacks.
Many VA panel variants are less transparent than IPS panels, so they are either dimmer or require more powerful backlights that draw more power.

Overall I like IPS more for general activities uncluding viewing media, and VA more for office work involving mostly test and diagrams.

140624 Tue: Impressions of the Acer B326HUL 32in monitor

The Acer B326HUL is a very recently released monitor product that has some unusual characteristics, most notably that it has a 32in panel diagonal, a VA panel and a 2560×1440 pixel size, and it is less expensive than most 30in monitors.

Typically a 2560×1440 pixel size is for monitors with a 27in panel, and these are almost always TN or IPS rather than VA.

VA and IPS panels have much better display quality than the cheaper TN panels, in particular as to viewing angles (especially vertical ones), and therefore they are rather more desirable than TN panels especially for television and tablet or smartphone use, which are often viewed from some angle. They also tend to have better color reproduction.

For over ten years VA and IPS panels have been used mostly in fairly expensive monitors. I suspect this was mostly due to their main inventors (Samsung, Hitachi) owning the core patents and demanding high royalties. In the past few years however they have also started appearing in mid-price products and even in some low price ones, perhaps because patents last at most 15-20 years in most countries and the first variants of IPS and VA panels were announced in 1991-1998.

Usually I have bought monitors with IPS panels because they have been much easier to find than monitors with VA panels, especially in mid-price products. The only manufacturer of mid-price VA panels seems to be AUO and they seemed to have a limited range.

However I was fairly impressed recently by the Samsung F2380 and the BenQ BL2400PT as both had good colour ranges with fairly wide viewing angles (the F2380 better than the BL2400PT), and really good contrast and deep blacks, which notably improved reading text; and the monitors were both well built and designed office range product, with a good stands and useful features, and the price was good.

I was interested in a larger monitor with a higher pixel size, such as monitors with 27in IPS panels with 2560×1440 pixel size (for example 1, 2, 3, 4) to replace my excellent Philips or Dell monitors with 24in IPS panels with a 1920×1200 pixel size.

The reason for my interest was my decision to put the monitor at a longer reading distance of around 80-100cm and to increase accordingly the size of the fonts, thus requiring some larger panel to give the same apparent (angular) size.

Then I discovered that AUO had releases this new 32in VA panel and it was initially available in the Acer B326HUL and also the BL3200PT, with relatively small differences among them. Being very newly released I found only a few reviews (1, 2, 3) that were rather positive about the panel and the monitors.

Eventually I bought the B326HUL instead of the BL3200PT because the former was cheaper at around £450 (incl. VAT) rather than around £480 (incl. VAT) and I did not need the slightly better features of the latter; for example the BL3200PT stand can pivot the screen to support portrait mode, and then the display automatically switches to portrait mode, but portrait mode on a 24in screen is already a bit too tall, and on a 32in screen it is not very useful.

Having that the B326HUL my first impressions are very positive, and the reviews were quite reliable. Some points:

The size of 32in seems good for a pixel size of 2560×1440 than 27in at a distance of around 80-100cm; the panel pitch is around 92DPI (rather than 108), which is the same as for a 1920×1200 24in panel and good enough for pixels to be essentially invisible at around 80-100cm, and gives notably larger angular space.
The contrast is excellent as expected and indeed helps with reading text.
Since I have it next to a monitor with an extended gamut lamp as backlight the use of a LED backlight (like almost all current monitors) gives a clearly colder, flatter range of colors, but also switches to maximum brightness much faster, instead of the 20-30 minutes that a lamp backlight takes to reach proper brightness.
Also the B326HUL like the BL3200PT and my previous monitor the Dell U2412M don't use PWM to change the brightness of the backlight, and this will avoid fatigue and headaches that can happen when it is used.
Both color quality and the viewing angles seem much better than those for older VA panels, and to me both seem hard to distinguish from those of an IPS panel in a monitor of equivalent price. Even a passionate photographer who looked at his photos on the B326HUL was rather impressed with the color reproduction. I suspect that some patents on improved VA variants have expired very recently, and these have been incorporated into this panel to make it distinctly better than those in the BL2400PT and the F2380.
The stand of the B326HUL is indeed rather solid and stable and I don't miss the ability to pivot that makes the stand of the BL3200PT reportedly a bit wobbly.
As one review mentioned since VA panels update fairly slowly both Acer and BenQ decided to apply a lot of movement overcompensation, which results in a lot of ghosting for fast moving high contrast objects. However in my normal use that is only the cursor, and I don't care. There seems to be no noticeable ghosting with movies.
There is no analogue/VGA input, even the DVI connector is digital only. This means that VGA-only output devices like old laptops cannot use this monitor at all, even at lower pixel sizes than the nominal 2560×1440.

So I think that it is a very good monitor with an excellent panel (just like the BL3200PT), and I think that I made the right choice in going for a recent VA panel rather than an IPS one for text oriented usage (I would probably do the opposite for a game oriented monitor) and on a 32in panel rather than a 27in panel, especially as the price is nearly the same, and way below that of most 30in monitors too.

140608 Sun: Firefox color preference disabled background images

For a rather long time I have wondered box background images would not display when using my main Firefox profile, but would with other profiles. I thought is was due to some stylesheet issue, but even disabling my user stylesheet did not change that. The issue is annoying because a lot of sites have stylesheets that use background images in empty boxes to display those images, instead of using the <img> tag, in particular to display link navigation icons (a double violation of the spirit of HTML).

The context here is that that some web pages are themed with peculiar colour combinations, and background images are widely and improperly used to just display images instead of the img element.

Unfortunately the temptation by site authors to put content in HTML attributes and in CSS attributes is very strong, even if it is entirely pointless to do so, so I finally spent some hours looking into the reason.

My investigation started by using the WebDeveloper builtin tools and the Web Developer extension at the HTML and CSS on affected pages, and I found that they displayed the CSS property background-image: none as overriding any other setting coming from the builtin or downloaded stylesheets, but seemingly coming from nowhere.

So knowing that this was an issue that appeared in some Firefox profiles but not others I started manually hiding some files in one of the affected profiles, and after a long time of trial and error determined that the issue disappeared with a default version of the file prefs.js which contains the Firefox user preferences. This was rather a surprise, and after starting to remove custom preferences from it I eventually discovered that setting as false the preference:

browser.display.use_document_colors

(for Allow pages to choose their own colors) also has the side-effect of disabling background images.

This was rather surprising and then I found that it is a known issue and there is even a discussions of its rationale with a supporting argument that is surprising: that disabling site specified colors that been tuned for a specific background image may make text unreadable if that image is not disabled too, for example if the background image is dark and the foreground color is light: the default foreground color is dark and would be hard to read against the dark background image.

This seems to me easily solvable by having a new setting for retaining background images even if document background colors have been disabled. At the very least the Allow pages to choose their own colors caption should be updated to note that background images get disabled too.

Anyhow there is a workaround: keep browser.display.use_document_colors set as true but set default foreground and background colors in the user stylesheet, something that I would do anyhow.

140405 Sat: Big changes in Ubuntu and online game stores

Writing previously Ubuntu and Steam I mentioned the importance of having vested interests pay for long term support of softwarem, and before that I wrote about SteamOS being supported long term as it is a long term strategic move by its sponsor to create a platform they control for their Steam online games store, and the contrast with Debian and Ubuntu itself.

Recent events seem to underline that: the sponsors of Ubuntu have rather abruptly cancelled their major U1 online storage product, and Amazon have just launched their own game console.

The sudden disappearance of U1 is just the last example of how limited the staying power of technology products is, and the introduction of a (streaming) game console means that Amazon now own a platform to deliver their enormous online store, including many games:

Titles from Ubisoft, Double Fine, Telltale Games, EA, Disney, Sega, and Gameloft will be coming to the Fire TV. Thousands of games are expected to launch by next month, including Minecraft, The Walking Dead, NBA 2K14, and the Amazon Game Studios-developed Sev Zero.

The Amazon product makes Amazon into an even more direct competitor to Steam. Previously Amazon only sold game CDs and DVDs to install on a computer, and Steam delivered them directly over the Internet to the same computer, but now Amazon can do that too.

My impression is that this means that Valve Software now must regard both Microsoft and Amazon, two formidably large companies, as direct competitors to Steam and both of them own their own delivery platforms, and this it makes SteamOS and the forthcoming Steam boxes even more important for them.

Which reinforces the impression that Valve Software will be rather committed to developing Steam, but at the same time reduces a bit the chances that Valve Software themselves will be around in the long term.

Overall however I think that the Amazon move is a positive event for SteamOS, as Valve Software seems well managed and likely to survive for a long time.

140327 Thu: Debian 6 LTS, Ubuntu LTS, SteamOS, coolness

I have read with amusement the idea from some people in the Debian project to create a Debian LTS distribution by finding volunteeers to extend the commitment to provide security updates for the Debian 6/Squeeze release.

It is a bit ironic as in some important ways Debian 6 package versions are largely equivalent to those in Ubuntu 10.04 LTS and the sponsor of the latter have committed to provide security updates for it for another year; therefore the work of whoever volunteers to maintain Debian 6 LTS could largely amount to bring into Debian 6 the updates Ubuntu 10.04 LTS. Which is both a beautiful example of free software working as intended and of an unexpected relationship between Debian and one of its derivatives.

Part of the amusement is that one of several reasons why some people volunteer for a project like Debian is that it is cool and maybe even fun, but keeping old versions of software updated is rather uncool and not very much fun, and as a result usually it is paid work instead of volunteer work.

Some free software projects have faded as volunteers have become bored with them, and moved to more interesting topics, or topics that look more interesting to potential employers. Very recently someone has started worrying about refreshing the coolness of the Fedora Project having noticed that GitHub now hosts ten million repositories:

Even if we go with the rule that 90% of everything is crap, 10 million repos is still a large number, and much larger than the 14,000-some packages in Fedora. There’s just no way we could possibly capture all of that, and it is a lot of open source developer energy happening in a space that we’re not playing in.

Also: the base OS has developed to the point where it has become uninteresting. Now, we do a lot of things in Fedora which are really on top of what might be considered a bare base OS, but basically the thing we are doing as our primary activity in Fedora is considered boring.

Another irony is that one of my recent arguments as to why SteamOS might become an important distribution for a production server is that its sponsor will be committed to funding paid work to maintain it for a long time if it acquires a large installed base as it well might.

The rationale of my thoughts is the classic free software principle of scratch your itch, that people's contributions to free software are usually the result of a personal issue.

For long term support of obsolete software packages the itch can only plausibly be the desire to appease the owners of a large installed base of systems, because systems get stuck on old software packages when it is too much work and too risky to upgrade them, and that is plausible when there are many and usually delivering commercial services.

Obviously Ubuntu LTS is designed for that itch, and my earlier argument is that SteanOS may well satisfy the same itch; the proposal by Debian may be motivated by the plausbility of there being Debian adopters having too a large installed base where it means lots of work and significant risk to upgrade.

140326 Wed: Route metrics and address subnet prefixes

Linux is one of the few operating system kernels that takes into account route metrics, which can be useful in sophisticated routing setups but also in simple ones: at home some nodes like my laptop could use two or three routes to the Internet, a fast one via an Ethernet switch, and slower ones via a WiFi AP, or one via a cellular modem.

My practice is to assign a metric to every route, with the convention that the metric value is 10¹¹ divided by the bits per second bandwidth of the link for that route (potentially with a correction factor for link usage), with metric 1 being thus for 100Gb/s links. This is not quite right because the metric ought to be proportional to time taken to transmit a packet through it, that is both bandwidth and latency, but that depends on the size of the packet too, and using just bandwidth is usually good enough.

However the default method of configuring an interface does not allow assigning a metric to the route to the subnet that interface may route into:

# ip a a 10.0.0.1/24 dev dummy0 metric 100
Error: either "local" is duplicate, or "metric" is a garbage.

This may be just a limitation of the ip command, but because of this and other considerations I have concluded that the older method of configuring an interface in two steps, first giving it an address and then adding a route to the subnet is in general preferable even if more verbose:

# ip a a 10.0.0.1/32 dev dummy0
# ip r a 10.0.0.0/24 dev dummy0 metric 100 mtu 1400

The latter way has also the advantage that it makes it possible to specify the route's MTU, which may be in several cases smaller than the interface's MTU, which then can be used to describe the maximum rather than the current MTU. This also offers a limited way to describe the situation where the incoming and outgoing MTUs may be different.

Setting the address and subnet route on an interface at the same time has one major advantage, which is it describes more precisely the situation with interfaces for multicast networks, but my impression is that the ability to describe the route metric and MTU trumps that. I have considered doing both:

# ip a a 10.0.0.1/24 dev dummy0
# ip r a 10.0.0.0/24 dev dummy0 metric 100 mtu 1400
# ip r l
10.0.0.0/24 dev dummy0  proto kernel  scope link  src 10.0.0.1 
10.0.0.0/24 dev dummy0  scope link  metric 100  mtu 1400

Rather regrettably the Linux kernel IP logic prefers routes without metrics to routes with metrics:

# ip r g 10.0.0.2
10.0.0.2 dev dummy0  src 10.0.0.1 
    cache 
# ip r d 10.0.0.0/24 dev dummy0  proto kernel  scope link  src 10.0.0.1
# ip r l
10.0.0.0/24 dev dummy0  scope link  metric 100  mtu 1400
# ip r g 10.0.0.2
10.0.0.2 dev dummy0  src 10.0.0.1 
    cache  mtu 1400

140324 Mon: Icinga and getting rid of PHP

I have been updating an old but still decent laptop I have, one that that I have not used since August 2013, and this with Ubuntu LTS 12.04 involved 963 package updates. Among them I spotted updates to PHP, which made me feel displeased. So I had a look at packages requiring it and they were GoSA. and the web interfaces for Ganglia and Nagios3.

To get rid of PHP I would not mind losing GoSA and even Ganglia, but I would rather keept (if only to test it) Nagios3, but then I noticed that its fork Icinga does not depend on PHP for its web interface, and in any case I am persuaded that it is preferable, I removed Nagios3 as well as GoSA and the Ganglia web interface, and thanks to Icinga not depending on it, PHP too.

140319 Wed: SteamOS may become a significant server Linux distribution

Both Linux and two of its most popular distributions have been around for more than 20 years, and they have become consolidated ecosystems on which production critical systems are based in many places, including where I work, where the Debian distrution has been chosen as a strategic platform because of the long life and stability of its ecosystem.

But something that is both a strength and a weakness in its ecosystem is that its development and maintenance is done by volunteers, many of them hobbysts, and the attraction of doing distribution maintenance is in part subject to fashion.

Then at some point many Debian users have considered its derivative Ubuntu as an alternative, in part because since it is developed by a dedicated commercial sponsor (Canonical) it may enjoy the benefits of tighter technical direction and greater commitment by that dedicated sponsor (compared to a variable collection of hobbysts), plus the sponsor business model is to offer support contracts, which may be useful in many organizations.

Then I have recently started looking at another Debian derivative, the SteamOS, for similar reason, also looking at its potential as an alternative to Debian for production critical servers.

This may seem surprising as it was developed as a computer games platform, but its background and ecosystem may be suitable for servers too.

To understand that it is necessary to first note why SteamOS has been developed and for what kind of user population.

A large source of revenue for its sponsor is the online game store Steam which was originally developed mainly for the MS-Windows platform owned by Microsoft.

Microsoft management have surely noticed the (large) success of Steam, which now accounts probably for a large majority of game sales on MS-Windows and are very much aware that Microsoft are also in the game business, with MS-Windows, but especially with their XBox game platform and their XBox Live game store.

Therefore Microsoft management may understandably see Steam as a competitor that is getting sales and profits that should go to Microsoft, and therefore begun pushing the MS-Windows version of their XBox game store, and as a reaction Valve started to develop Steam for Linux and to talk about SteamOS and SteamOS based game console competing with XBox and supported by their very popular Steam game store.

The Microsoft MS-Windows game store has been merged into the XBox game store and then that particular section has been closed and Microsoft now is looking at merging more of the XBox store with the MS-Windows platform.

The consequence of these moves by their biggest competitor means that for Valve it is very dangerous to have no alternative to run their games store on their competitor's MS-Windows platform, and therefore Steam for Linux and SteamOS are likely long term strategic commitments on which the survival of a large part of Valve's profits may depend.

Conversely Canonical is a much smaller business, they don't have yet a large Ubuntu related profit streams to protect, and to some extent they are still a project of a wealthy individual who may walk away from that project with only a small loss of money.

But another important aspect of the SteamOS ecosystem is potential scale: it may well end installed on dozens of millions of devices. It will therefore be exposed to high pressure for reliability and security as well as performance.

Android has ended up installed onto hundreds of devices, but in a very different way: it is embedded in the device in a way that discourages updates, and each device manufacturer ends up embedding a slightly different and largely unchanging version, while SteamOS would be installed on ordinary PC-like (more precisely, laptop-like) systems and probably all upgraded from Valve's repositories.

Subject to exposure to many different issues on a large number of devices it may well happen that Valve will have a large incentive to maintain it with zeal, to scratch their itch as they saying goes, and this might make SteamOS, or at least its key components like the kernel and base library packages, particularly robust for servers too.

This is just a possible scenario, but it is one that is possible for few if any other GNU/Linux distribution, so I am keen to watch and experience the SteamOS package updates and the effort and policies Valve invests in maintaining SteamOS.

140318 Tue: Replacing 'loop-AES' with 'dm-crypt'

I have been using the Linux driver loop-AES for encrypted block devices for a while, for example as it is quite important to have encrypted swap block devices (or files).

loop-AES is a well designed, reliable driver, developed by the deeply knowledgeable Jari Ruusu but unfortunately it has never been accepted in the main kernel sources, so it has been up to him to maintain it, and to its users to compile and install it, which requires some system administration knowledge.

I have been using version 3.7a for a while, and I recently discovered that it does not compile with recent kernels, for example 3.10 or later, and there are no recent updates for it, as 3.7a is still the latest version, released 2013-08-26 (1, 2).

This is quite sad as I particularly liked it because of the trust in the author and its good design. I suspect that part of the reason why it has not been updated is that its main alternative dm-crypt now has full in-place compatibility with loop-AES and being part of the (inappropriately) popular DM/LVM2 subsystem it is a standard part of Linux and thus requires no installation effort, and its development is effectively sponsored by some Linux distribution vendor.

The fading away of loop-AES is sad because technically it is significantly more appropriate than dm-crypt for several reasons:

The loop-AES is a derivative of the loop driver that simply wraps a file, or a block device, as a new block device, and it adds a simple transformation of the data in the new block device, which is entirely the right approach.
dm-crypt is instead a content tranformation system for a block device, but it is part of the DM subsystem, which is instead effectively a simple file-system for few, large mostly contiguous files, but can only deal with block devices.
DM itself is arguably pointless as large mostly contiguous files are well supported by good ordinary file-systems like JFS or XFS plus (ironically) loop or loop-AES to wrap them into block devices.
Since DM only deals with underlying block devices, dm-crypt can only encrypt the content of block devices, and not files, unless (ironically) the file is wrapped as a block device by the loop or loop-AES driver.

In other words rather than DM/LVM2 plus dm-crypt I would rather have JFS plus loop-AES, but sponsors have been found for the first alternative and not the second.

Note: dm-crypt has at least one arguable advantage over loop-AES: it optionally supports TRIM, FSTRIM on flash (and similar) storage devices. It reduces a bit security, and for this reason it was not added to loop-AES, but I think it is not a big deal, and it can be useful.

So it is very easy to replace loop-AES with dm-crypt when using recent kernel versions, in particular for single key mode; for example if /dev/sda5 is a single-key encrypted loop-AES block device with:

cryptsetup -y -c aes-cbc-plain -s 128 -h sha256 create sda5-e /dev/sda5

With some more effort (since kernel version 2.6.38) for the multi-key mode.

140317 Mon: Packages for Steam on Debian 7/Wheezy

The Steam game downloading system by Valve and several games it makes available has been available for GNU/Linux for a while, and I have been using it for a while and it works fairly well; it is targeted (for now) at the Ubuntu distribution but it also works on the SteamOS distribution that Valve have designed for it, as it seems that the owners of Ubuntu wanted to charge too much for it.

Ubuntu is based on Debian somewhat loosely, and this also involves most packages being close derivatives of the Debian ones, but slightly different, and with versions not aligned with those in Debian releases (even if usually there is similarity).

So I decided to have a look at SteamOS to see what kind of Debian derivative it is, and how compatible with Debian it is (Ubuntu is not very compatible) so I added to the APT configuration of a Debian 7 system the SteamOS repositories (pinned at a lower priority) and updated the local package database, and I was surprised.

I expected SteamOS to be an extension of Debian, that is a collection of packages to extend those in the standard Debian repositories, but instead SteamOS is a rebuild of Debian, like Ubuntu, where all SteamOS packages are slightly modified and recompiled.

However, for now at least, SteamOS packages and setup are a very close rebuild of Debian, as the current release of SteamOS ihas packages that are nearly identical to and compatible with Debian 7, except in a few areas, that unsurprisingly are similar to those listed for Ubuntu LTS 12.04 (which is sort of equivalent to Debian 7):

Xorg server packages version 7.7.
MesaGL packages version 10.0.1.
The LLVM packages version 3.3.
GNU C Library version 2.17 instead of 2.15, which is required by the MesaGL library version 10.
Linux kernel version 3.10 instead of 3.2, which is also required by the MesaGL library version 10 (it requires at least version 3.6). the use of version 3.10 is a bit surprising as Debian 7 has an official backport of 3.12, but then that backport was of 3.10 until some time ago.

The required upgrade to the kernel version is a significant change, but not that big as after all Debian 7 has an official backport of 3.12 and it is fairly widely used, and the kernel binary API is very tightly controlled, which means backwards compatibility.

The use of an updated C library is a more significant item because it is rather more intrusive as it is used by nearly every other package, and it means that SteamOS packages cannot be used on Debian 7 without upgrading the C library to the C one. It would perhaps been preferable to backport to the Debian 7 C library package the patches that MesaGL needs from version 2.17. However the C library API is also tightly comntrolled, also means backwards compatibility.

Many of the libraries also need to be installed in 32-bit versions on 64-bit systems as Steam games are usually compiled for 32-bit.

Anyhow I found that not many packages are needed to run Steam on a Debian 7/Wheezy system as if it were SteamOS, and this is the main list (from an Aptitude screenful):

    i A 4600 kB  10.3 MB  2.17-97+steamo 2.17-97+steamo testing libc6
    i A 3956 kB  9012 kB  2.17-97+steamo 2.17-97+steamo testing libc6:i386
    i A 2997 kB  11.9 MB  2.17-97+steamo 2.17-97+steamo testing libc6-dev
    i A 4123 kB  9677 kB  2.17-97+steamo 2.17-97+steamo testing libc6-i386
    i   1299 kB  3104 kB  2.17-97+steamo 2.17-97+steamo testing libc6-i686:i386
    i A 8714 kB  73.2 MB  10.0.1+steamos 10.0.1+steamos testing libgl1-mesa-dri
    i   8801 kB  74.8 MB  10.0.1+steamos 10.0.1+steamos testing libgl1-mesa-dri:i386
    i A 140 kB   486 kB   10.0.1+steamos 10.0.1+steamos testing libgl1-mesa-glx
    i A 138 kB   465 kB   10.0.1+steamos 10.0.1+steamos testing libgl1-mesa-glx:i386
    i A 49.9 kB  243 kB   10.0.1+steamos 10.0.1+steamos testing libglapi-mesa
    i A 50.6 kB  177 kB   10.0.1+steamos 10.0.1+steamos testing libglapi-mesa:i386
    i A 195 kB   495 kB   9.0.0-2+bsos1  9.0.0-2+bsos1  testing libglu1-mesa
    i A 200 kB   514 kB   9.0.0-2+bsos1  9.0.0-2+bsos1  testing libglu1-mesa:i386
    i A 8844 kB  24.3 MB  1:3.3-12+bsos1 1:3.3-12+bsos1 testing libllvm3.3
    i A 9293 kB  24.7 MB  1:3.3-12+bsos1 1:3.3-12+bsos1 testing libllvm3.3:i386
    i   25.1 MB  117 MB   3.10.11-1+stea 3.10.11-1+stea testing linux-image-3.10-3-amd64
    i   1603 kB  3847 kB  1:3.3-12+bsos1 1:3.3-12+bsos1 testing llvm-3.3
    i A 42.9 kB  155 kB   1:3.3-12+bsos1 1:3.3-12+bsos1 testing llvm-3.3-runtime
    i   30.4 kB  116 kB   8.0.1-2+bsos1  8.0.1-2+bsos1  testing mesa-utils
    i   36.8 kB  79.9 kB  1:7.7+3~deb7u1 1:7.7+3~deb7u1 testing xorg
    i A 111 kB   370 kB   1:7.7+3~deb7u1 1:7.7+3~deb7u1 testing xserver-xorg
    i A 1730 kB  4068 kB  2:1.12.4-6+ste 2:1.12.4-6+ste testing xserver-xorg-core
    i A 104 kB   190 kB   1:2.7.0-1+bsos 1:2.7.0-1+bsos testing xserver-xorg-input-evdev
    i A 66.1 kB  153 kB   1:1.7.2-3+bsos 1:1.7.2-3+bsos testing xserver-xorg-input-mouse
    i A 208 kB   344 kB   1.6.2-2+bsos6  1.6.2-2+bsos6  testing xserver-xorg-input-synaptics
    i A 23.4 kB  94.2 kB  1:0.4.2-4+bsos 1:0.4.2-4+bsos testing xserver-xorg-video-fbdev
    i A 1442 kB  2575 kB  2:2.21.15-1+bs 2:2.21.15-1+bs testing xserver-xorg-video-intel
    i A 307 kB   481 kB   1:1.0.1-5+bsos 1:1.0.1-5+bsos testing xserver-xorg-video-nouveau
    i A 720 kB   1552 kB  1:6.14.4-8+bso 1:6.14.4-8+bso testing xserver-xorg-video-radeon
    i A 31.2 kB  103 kB   1:2.3.1-1+bsos 1:2.3.1-1+bsos testing xserver-xorg-video-vesa

Since Debian releases are infrequent and stable the above list for Debian 7 will continue to be useful for quite a while, and it will be interesting to see how the SteamOS evolves as to these aspects too.

140315 Sat: Packages for Steam on Ubuntu LTS 12.04

Ubuntu LTS 12.04 is stable and nice, but some of its components are a bit too old to support some important aspects of many recent games available from Steam, I have mentioned previously some of the more important details, in particular relating to the AMD/ATI graphics drivers, but it is also important to have these updated components:

Xorg server packages version 7,7 (with suffix lts-saucy rom the Ubuntu X-SWAT team stable updates repository.
MesaGL packages version 9.2.1 (with suffix lts-saucy) from the same repository above.
The LLVM packages version 3.3.

Many of the libraries also need to be installed in 32-bit versions on 64-bit systems as Steam games are usually compiled for 32-bit.

The list of packages I used is thus (from an Aptitude screeful):

    i   1152 kB  3937 kB  9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libegl1-mesa-drivers-lts-saucy
    i   1158 kB  3806 kB  9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libegl1-mesa-drivers-lts-saucy:i386
    i A 54.7 kB  236 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libegl1-mesa-lts-saucy
    i A 54.3 kB  233 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libegl1-mesa-lts-saucy:i386
    i A 3419 kB  16.4 MB  9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgl1-mesa-dri-lts-saucy
    i A 3363 kB  16.2 MB  9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgl1-mesa-dri-lts-saucy:i386
    i A 106 kB   495 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgl1-mesa-glx-lts-saucy
    i A 104 kB   467 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgl1-mesa-glx-lts-saucy:i386
    i A 21.0 kB  242 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libglapi-mesa-lts-saucy
    i A 20.9 kB  179 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libglapi-mesa-lts-saucy:i386
    i   11.5 kB  125 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgles1-mesa-lts-saucy
    i   11.3 kB  119 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgles1-mesa-lts-saucy:i386
    i   12.7 kB  130 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgles2-mesa-lts-saucy
    i   12.5 kB  126 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libgles2-mesa-lts-saucy:i386
    i A 9040 kB  24.8 MB  1:3.3-5ubuntu4 1:3.3-5ubuntu4 precise-updates libllvm3.3
    i A 9322 kB  24.5 MB  1:3.3-5ubuntu4 1:3.3-5ubuntu4 precise-updates libllvm3.3:i386
    i A 13.1 kB  129 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libopenvg1-mesa-lts-saucy
    i A 13.2 kB  122 kB   9.2.1-1ubuntu3 9.2.1-1ubuntu3 precise-updates libopenvg1-mesa-lts-saucy:i386
    i   1652 kB  3984 kB  1:3.3-5ubuntu4 1:3.3-5ubuntu4 precise-updates llvm-3.3
    i A 39.9 kB  163 kB   1:3.3-5ubuntu4 1:3.3-5ubuntu4 precise-updates llvm-3.3-runtime
    i A 1597 kB  3921 kB  2:1.14.5-1ubun 2:1.14.5-1ubun precise-updates xserver-xorg-core-lts-saucy
    i A 33.5 kB  140 kB   1:2.7.3-0ubunt 1:2.7.3-0ubunt precise-updates xserver-xorg-input-evdev-lts-saucy
    i A 23.3 kB  111 kB   1:1.6.1-1build 1:1.6.1-1build precise-updates xserver-xorg-input-joystick-lts-saucy
    i A 15.2 kB  98.3 kB  1:1.6.1-1build 1:1.6.1-1build precise-updates xserver-xorg-input-kbd-lts-saucy
    i A 25.3 kB  108 kB   0.3.0-1build1~ 0.3.0-1build1~ precise-updates xserver-xorg-input-mtrack-lts-saucy
    i A 66.4 kB  228 kB   1.7.1-0ubuntu1 1.7.1-0ubuntu1 precise-updates xserver-xorg-input-synaptics-lts-saucy
    i A 7620 B   74.8 kB  1:1.4.0-1build 1:1.4.0-1build precise-updates xserver-xorg-input-void-lts-saucy
    i   17.4 kB  194 kB   1:7.7+1ubuntu6 1:7.7+1ubuntu6 precise-updates xserver-xorg-lts-saucy
    i A 9816 B   68.6 kB  1:0.3.6-0ubunt 1:0.3.6-0ubunt precise-updates xserver-xorg-video-dummy-lts-saucy
    i A 13.4 kB  87.0 kB  1:0.4.3-0ubunt 1:0.4.3-0ubunt precise-updates xserver-xorg-video-fbdev-lts-saucy
    i A 726 kB   2665 kB  2:2.99.904-0ub 2:2.99.904-0ub precise-updates xserver-xorg-video-intel-lts-saucy
    i A 23.8 kB  106 kB   0.8.0-0ubuntu1 0.8.0-0ubuntu1 precise-updates xserver-xorg-video-modesetting-lts-sau
    i A 93.4 kB  308 kB   1:1.0.9-2ubunt 1:1.0.9-2ubunt precise-updates xserver-xorg-video-nouveau-lts-saucy
    i A 164 kB   510 kB   1:7.2.0-0ubunt 1:7.2.0-0ubunt precise-updates xserver-xorg-video-radeon-lts-saucy
    i A 16.3 kB  91.1 kB  1:2.3.2-0ubunt 1:2.3.2-0ubunt precise-updates xserver-xorg-video-vesa-lts-saucy

Note also that if you are using the free software graphics unit drivers, for example those for the graphics units built into Intel CPUs, it is probably a very good idea to upgrade the kernel package to latest version from the precise-backports archive because it contains much newer versions of those graphics drivers that work better with the upgrade Xorg server and Mesa3D libraries. But since I use the AMD/ATi proprietary drivers I did not do that. Currently it is:

    i   57.8 MB  203 MB   3.11.0-18.32~p 3.11.0-18.32~p precise-updates linux-image-3.11.0-18-generic

This post may seem a bit late as the new LTS release 14.04 has all these updates built-in, but the above list is still useful as many people will continue to use 12.04 for a while, the current version of Steam is targeted at it, and when some new version of Steam is released requiring updates to 14.04 it is very likely that these will still be to the same groups (Mesa3D, LLVM, Xorg server) of packages.

140312 Wed: Apple re-defines the unit of measure 'point'

Following the previous post on font rasterization and DPI I found a discussion of high-DPI rasterization on the popular Apple Retina displays in which the term point seemed to be used in a strange way.

Indeed, it turns out that Apple have re-defined point to mean not the traditional (approximately) 1/72 of an inch as per typographic tradition, but to mean a location on the screen in some screen Cartesian space independent of the pixel size of the screen:

Points Versus Pixels
In iOS, all coordinate values and distances are specified using floating-point values in units referred to as points.The measurable size of a point varies from device to device and is largely irrelevant.

140228 Fri: DPI, viewing distance and font glyph sizes

Best font sizes for reading

Centuries of experience with books and other printer matters have given us the notion that comfortable reading happens with text in 10 points fonts for viewing at normal reading distance of around 25-40cm (12-15in) (around the length of the forearm plus that of the palm) for pages with lines 60-70 characters long and 45-55 lines tall.

There are approximately 72 points per inch, and a 10 point font is supposed to have the letter x around 10 points high and wide, which means that the typical page should be around 600 points or 8 inches, plus perhaps half-inch margins, and (including inter-line space of around 20%) 9 inches plus header and footer of one inch each, we get the typical A4 or letter paper sizes.

Display and printer characteristics

My 24in Philips 240PW9 monitor has 1920×1200 square pixels, a display physical size of 518×324mm with a 24in diagonal, and a nominal DPI of 106; that is measured diagonally, that is over a diagonal of nominally 2264 pixels. The vertical and horizontal DPI are around 94, for a pixel pitch of around 0.27mm, or equivalently 13 pixels per 10 points.

The human eye can resolve around 300DPI at normal reading distance, and this has been turned in a simple rule, that given a certain screen DPI a viewing distance in inches of 3843/DPI results in pixels becoming indistinguishable. Equivalently that is 10000/DPI for a viewing distance in centimeters.

So for example most printers have a printing resolution of at least 300DPI, so that text they print looks unpixelated at a reading distance of at least 33cm, which is within the range of the normal reading distance; many have higher resolutions to handle shorter viewing distances, or to improve quality with very fine character features.

Similarly retina displays for tablets and smartphones have resolutions of 300DPI and sometimes higher.

Desktop and laptop displays and viewing distance

Ordinary computer monitors for various reasons have almost always a 100DPI resolution, even if few higher DPI monitors have become available.

Viewed from normal reading distance a 100DPI display looks distinctly pixelated, and regrettable workarounds like anti-aliasing have been introduced to counter that.

However display sizes have significantly increased over time, and while years ago 12in and 15in displays were the most common, currently probably 23 to 27in displays are quite common, and it is difficult to buy displays smaller than 19in.

At normal reading distance a 24in display is hard to take in at a glance, as it can hold 230x65 fixed-pitch characters, that is 3 pages side-by-side, and therefore requires moving around the head.

A 24in 100DPI display also becomes a retina display according to the above formula at a viewing distance of around 38in/96cm, and I found that a bit shorter than that, a full arm's length, around 75-80cm is particularly confortable.

Note: my desk is around 80cm deep too, so I can keep the display at around 80-90cm, as I sit a bit further out from the near edge of the desk, and the display is a bit further in from the far edge.

But from that distance the size of characters at 10 points over 100DPI is too small to read comfortably, and that's designed for a reading distance of somewhat less than half, even if the pixels have nearly disappeared.

The same issue happens when I use my laptop on my knees, as then the distance between display and eyes is also close to a full arm's length.

Just like the apparent size of pixels shrinks the further away they are, so does the apparent size of chatacters, and 10 points if the font size that is good at normal reading distance, and needs to be larger at further distances.

That means that the pixel size of a glyph representing a character should depends not just on point size and display DPI, but also on the different between current viewing distance and normal reading distance.

Note: more precisely the scaling should be proportional to eye resolving power, because that is what diminishes with increasing distance; and some people with impaired vision have a lower resolving power than average at normal reading distance.

So glyph sizes should be scale so that have the same apparent size at different viewing distances. The scaling factor depends on keeping the perceived area of a glyph constant at different distances, so the linear ratio should be the square root (in first, linear, coarse approximation) of the ratio of the viewing distance to normal reading distance. For an arm's length viewing distance I find accordingly a linear ratio of 1.3 to 1.4. looks good.

Unfortunately there are no window systems that take into account viewing distance, so the available options are to scale point size or DPI with varying viewing distance.

Scaling the point size

The traditional option in typography is to change the point size, in part because issues of DPI are not immediately obvious, but also because of a strong and justified assumption that different reading distances imply different types of reading: ordinary text material like books, newspapers and magazines are always read at normal reading distance, as the reader can bring them to such distance, and that longer reading distances are associated with other types of text material, like signs, posters, ...

As that is the traditional option I have been trying to reconfigure my X Windows/KDE/Gtk desktop environment from 10 points at 100DPI for viewing at around arm's length, or twice normal reading reading distance, or even a bit more.

In theory this is now possible because UNIX fonts are available in a number of pixel sizes or are scalable (usually because tney are outline fonts like TrueType or PostScript font types). Unfortunately there are two main intrinsic problems:

Fonts at different point sizes and constant DPI have rather different character shapes, in part because the availabilty of more pixel for the glyphs constrains less the rendering.
Also many fonts are designed to look differently at various ranges of point sizes. This is because there is an assumption that all different point sizes are viewed at the same reading distance, and at the same reading distance characters look better if they are not scaled linearly with nominal point size.
Far more importantly as a rule the reading distance will be constant across all display technologies. Thus text set for 13 or 14 points that looks good on a display at arm's length distance will look too big when printed on paper to be viewed at normal reading distance.

There are also some other adverse technical details:

Some of the best quality fonts for GNU/Linux, in particular the old-style X11 bitmap fonts, are not available with glyph sizes 1.3-1.4 linear times the size of the glyphs at 10 points on 100DPI displays.
Unfortunately most font libraries and text layout libraries and applications for GNU/Linux cannot easily change text point sizes dynamically as it would be desirable when the distance to the display changes or the DPI of the screen changes; for example when an external monitor is attached to a laptop and becomes the main display. In part this is because they consider text point size an intrinsic absolute property of the text, independent of how it is displayed; this is reasonable, but they could instead consider it a relative property around a normal value, which is for example an option in CSS.

Scaling the DPI

The alternative is to scale the DPi that font rendering libraries also use in computing the size of the rendered glyph.

This is not quite the right thing to do, because DPI is supposed to be the device DPI, an intrinsic property of the device: a 100DPI display does not become a 130-140DPI display because it is being looked at from arm's length instead of forearm's length, even if the greater distance reduces the apparent size of its pixels.

However, given that current software does not allow to specify viewing distance, and that point size is regarded correctly as an intrisic property of the text, there is no other option really than to regard device DPI as a nominal value valid only at normal reading distance, and to scale it as if it were apparent, optical DPI at other distances.

From a technical point of view that is also promising because with X Windows there are some mechanisms to tell the X server about a changed DPI.

All font rendering libraries and the applications that use them need to take into account device DPI when rendering a glyph, so scaling DPI could be seen as a universal solution.

Unfortunately most only look at DPI when they start, which means that they have to restarted to notice a new DPI, which is rather disappointing.

140111 Sat: Kerberos tickets, addresses, forwarding, SSH

Regrettably ssh when using Kerberos and asked to forward tickets to the target host will only forward tickets marked as forwardable and mark their copies on the target host as forwardable too.

This is regrettable because forwardable for Kerberos tickets and SSH delegation of security tokens are completely different concepts, and confusing them both reduces the desirability of SSH delegation of Kerberos tickets and creates unnecessary risks, because it results in the presence on the target host of a fully further forwardable TGT on the target host, even when not needed.

This leads to ask what forwardable, and the similar proxiable really mean for Kerberos tickets, and the official definition is:

If a ticket is forwardable, then the KDC can issue a new ticket (with a different network address, if necessary) based on the forwardable ticket. This allows for authentication forwarding without requiring a password to be typed in again. For example, if a user with a forwardable TGT logs into a remote system, the KDC could issue a new TGT for that user with the netword address of the remote system, allowing authentication on that host to work as though the user were logged in locally.

When the KDC creates a new ticket based on a forwardable ticket, it sets the forwarded flag on that new ticket. Any tickets that are created based on a ticket with the forwarded flag set will also have their forwarded flags set.

A proxiable ticket is similar to a forwardable ticket in that it allows a service to take on the identity of the client. Unlike a forwardable ticket, however, a proxiable ticket is only issued for specific services. In other words, a ticket-granting ticket cannot be issued based on a ticket that is proxiable but not forwardable.

A proxy ticket is one that was issued based on a proxiable ticket.

So the difference between forwardable and proxiable is that the former applies to TGTs and the latter does not, and in both cases:

The TGS will issue a new ticket with authentication provided not by a TGT, but by the forwardable ticket being presented.
The TGS will allow the newly issued ticket to have a different address list from the one provided for authentication.
The other fields of the newly issued ticket will be copied from the ticket provided for the authentication.
Except that the newly issued ticket will have the new flags forwarded or proxied.

What the documentation does not say explicitly is that the forwarded ticket will differ from the original in another respect: a different session key.

The crucial point is however the ability to have a new ticket with a different address list: because since a ticket is just a number of bytes, ssh could as well copy the original ticket over to the target host, and it would work, except for the case where its address list were non-empty and did not include the target host's address.

That a forwarded ticket also has a different session key is the only other notable difference, but it is a minor detail, even if it might potentially very slightly enhance security (for weak definition of security).

Which leads to the question of whether there is any need of the forwardable or proxiable flag for addressless tickets, because these can be delegated (copied) as they are to the target host.

The answer is that there is no such need: addressless tickets can be delegated as they are, and that the copy does not contain a new session key is a mostly irrelevant detail.

The design mistakes in ssh are then numerous, all consequences of the decision to treat the forwardable (or proxiable) flag as a stricter form of its -K option that requests delegation of Kerberos tickets:

ssh when -K is specified will not delegate proxiable tickets.
ssh will not delegate all tickets if -K is specified, but only those flagged forwardable.
ssh will not delegate all forwardable tickets, but only the TGT.

What ssh should is much simpler:

Delegate all tickets when -K is specified, regardless of their Kerberos flags. Because those flags are only relevant to the Kerberos server. If a ticket being delegated is forwardable or proxiable, then ssh should ask the Kerberos server for forwarded or proxied copies, with the target host's address if applicable, and delegate them instead.
If users want to delegate a ticket with an address list that does not include the address(es) of the target host, that's their choice. Perhaps a warning should be optionally given.
Optionally have a finer grained mechanism by which to explicitly specify which tickets to delegate. But this mechanism is a mere convenience as users can always make a copy of the credentials cache and delete from it any tickets they want to avoid delegating.

The specific case where these design mistake annoy me is when I want to be able to use ksu root on the target host, with /root/.k5login containing a like like:

user@REALM

In theory all I need to delegate is a ticket for principal user/root@REALM, either addressless or with an address list including the address(es) of the target host, and flagged as forwarded (not forwardable) in the latter case.

The ksu documentation says:

Otherwise, ksu looks for an appropriate Kerberos ticket in the source cache.

The ticket can either be for the end-server or a ticket granting ticket (TGT) for the target principal's realm.

However ssh will delegate only a TGT, and only if it is flagged forwardable, and then will flag as forwardable the forwarded TGT. A forwardable TGT for a site's /root instance involves much wider risks than a non-TGT non-forwardable especially if the latter has an address list tying it to the specific system it is delegated to.

Here is an example of the issue:

source$  kdestroy
source$  kinit -f -S host/target.example.com
Password for user@EXAMPLE.COM:
source$  klist -f
Ticket cache: FILE:/tmp/krb5cc_2048
Default principal: user@EXAMPLE.COM

Valid starting     Expires            Service principal
12/01/14 09:59:25  13/01/14 05:59:16  host/target.example.com@EXAMPLE.COM
        renew until 16/01/14 09:59:16, Flags: FRIA
source$  ssh -K target
target$ klist -f
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_2048)

Instead of using a TGT, we ask the KDC directly for the ticket the target host SSH service's principal, using our user@EXAMPLE.COM principal, and the resulting ticket is forwardable, but it has not been delegated to the target host. To simulate the delegation we explicitly request a similar ticket:

target$ kinit -S host/target.example.com
Password for user@EXAMPLE.COM:
target$ klist
Ticket cache: FILE:/tmp/krb5cc_2048
Default principal: user@EXAMPLE.COM

Valid starting     Expires            Service principal
12/01/14 09:59:56  13/01/14 05:59:51  host/target.example.com@EXAMPLE.COM
        renew until 16/01/14 09:59:51, Flags: RIA
target$ ksu
Authenticated user@EXAMPLE.COM
Account root: authorization for user@EXAMPLE.COM successful
Changing uid to root (0)

With that ticket we can run ksu because there is a line user@EXAMPLE.COM in /root/.k5login and we have a ticket owned by that principal for host/target.example.com@EXAMPLE.COM.

140104 Sat: HGST 4TB archival storage disk drive profile

It turns out that HGST has in its product lineup a 4TB drive especially designed for archival storage, the MegaScale DC 4000.B:

The MegaScale DC 4000.B is designed to meet the needs of the scale-out data center where low-power, high-capacity, cost-effective storage is essential. MegaScale DC addresses low application workloads that operate within 180TB per year.

Typical low-workload applications include multi-drive replicated environments, disk-to-disk backup and restore snapshots, online archives, big data stores and long-term data retention that benefit from low cost or energy usage.

I did not expect this, because regular drives seem pretty good already for being shelved in cartridges and also because usually HGST aimed at higher speed segments of the market; but it has been acquired by WD who have a long tradition of offering slow, large, low power Green drives.

The profile of this drives seems target at semi-online storage, where the drives are kept in some kind of powered storage enclosure but nearly powered down.

The 180TB per year target transfers per year seem like a limitation that ordinary drives do not have, but really everything has a target duty cycle, and the usually very informative X bit laboratories produce a comparison with the equivalent online drive Ultrastar 7K4000 reporting that that it is specified for target transfers of 550TB per year.

Interesting numbers, especially compared with published endurance numbers of enterprise flash SSDs, for example the P400m which has been designed with massive overprovisioning to deliver something like 10 drive fills per day for five years which translates to for Endurance: Total bytes written (TBW) as 400GB: 7.00PB, which let's say over five years means 1400TB per year. Which is more than what a 7200RPM drive is rated for both reads and writes by a factor larger than 2, even if it has 1/10th of the capacity.

By comparison my 256GB laptop drive was reported as supporting 72TB or 40GB per day for 5 years which means 14-15TB per year; but note that it has 1/15 of the capacity of a 4TB drive, so scaling up would give 225TB per year at the same capacity, which is 1/2 of 550TB, but amazingly not far away.

Anyhow at those levels of endurance these enterprise flash SSD drives might well be suitable for replacing 2.5in SAS 10000RPM or 15000RPM disk drives especially as it is also claimed that delivers reliably low latency times, updating my previous impressions.