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]
While IPS and VA panels have many variants, they are of broadly similar quality, and the main difference between VA and IPS panels are:
Overall I like IPS more for general activities uncluding viewing media, and VA more for office work involving mostly test and diagrams.
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:
VGAinput, 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.
For a rather long time I have wondered
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
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
with peculiar colour combinations, and background images are
widely and improperly used to just display images instead of
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
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:
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.
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.
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
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
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.
Linux is one of the few operating system kernels that takes
route metrics, which can be
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
My practice is to assign a metric to every route, with the convention that the metric value is 1011 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
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
does not depend on PHP for its web interface, and in any case
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
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
as an alternative, in part because since it is developed by a
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
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
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.
I have been using the Linux driver
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:
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.
game downloading system by
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
distribution but it also works on the
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
of a Debian 7 system the
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):
backportof 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.
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:
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.
Following the previous
post on font rasterization and DPI
I found a discussion of
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
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.
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
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.
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
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.
retina displays for tablets and
smartphones have resolutions of 300DPI and sometimes higher.
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
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
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
that take into account viewing distance, so the available
options are to scale point size or DPI with varying viewing
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:
There are also some other adverse technical details:
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.
and asked to forward
to the target host will only forward tickets marked as
forwardable and mark their copies on the
target host as
This is regrettable because
for Kerberos tickets and SSH
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
on the target host, even when not needed.
This leads to ask what
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:
What the documentation does not say explicitly is that the
forwarded ticket will differ from the original in another
respect: a different
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
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:
What ssh should is much simpler:
credentials cacheand 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:
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.
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
who have a long tradition of offering slow, large, low power
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
for example the
which has been designed with massive
overprovisioning to deliver something like
10 drive fills per day for five years which translates
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
10000PRM or 15000RPM disk drives especially as it is also
delivers reliably low latency times,
updating my previous impressions.