This site is now 100% read-only, and retired.

XML Logo

Posted by mcortese on Sun 17 May 2015 at 10:23
Tags: none.

I've just realized that the last version of GNOME (the one shipped with Jessie) allows to start the session under Wayland instead of the classic X. I think it's a only a preview to start collecting some feedback and bug reports from the field, and that it shouldn't be considered a mature, workable option.

On my admittedly underpowered system (an Atom-based netbook) the usability approaches zero, with xwayland taking up 99% of the CPU and several seconds of lag between action (mouse clicks, key presses) and feedback. In addition, synaptics options like tap-to-click are not recognized -- or not obeyed, I'm not sure.

I'd be curious about other users' experience, if any have been brave enough to try it out!


Posted by mcortese on Tue 17 Apr 2012 at 15:02
Tags: none.
It is amazing to count the number of substitutions and expansions that the PS1 variable undergoes before Bash splits it out as a prompt. Besides the documented 1-letter codes like \h or \w, and the general variable expansion like $EUID or even $?, I've recently learned that arithmetic expansion is possible as well.

The following code produces a green prompt in normal cases, which turns to red when the last command returned a non-zero code:

PS1='\[\e[$(($? ? 31 : 32))m\]whatever you want\[\e[39m\]'

How does it work? You should recognize the arithmetic expansion $(( ... )). Inside that, $? stands for the return code of the last command, and the construct expr ? expr-then : expr-else works like in C. So the whole arithmetic clause is evaluated as either 31 (if the return code is anything but zero) or 32 (if the return code is zero).

Now the sequence ESC[31m happens to be interpreted by the terminal as 'switch to red ink', while ESC[32m means 'switch to green ink'. That's it.

A complete example is then:

PS1='\[\e[$(($??31:32))m\]$? \w\[\e[39m\]: '


Posted by mcortese on Mon 18 Jul 2011 at 14:06
Tags: none.

As I posted in another weblog entry, I'm experiencing a curious shortage of entropy in my system. The one feature that constantly drains the pool is the address space layout randomization (ASLR), coupled with a unique choice of drivers (e.g. the ethernet adapter) that do not contribute any random data to the kernel. Forgetting the latter issue, for which I've laready worked out a patch, I'd like to focus on the ASLR topic.

My first reaction was of disbelief: is it possible that an apparently harmless feature, that has presumably received extensive scrutiny, is able to do so much damage? To answer this question, I made up a test to measure how much entropy is consumed every time a new process is spawned.

The quantity of entropy available to the kernel, expessed in bits, can be read from /proc/sys/kernel/random/entropy_avail. But even a simple cat used to get this number is deemed to spawn a new process, thus to further drain the entropy pool. Why not using this to actually measure the entity of such drain? Here is the code:

e0=$(cat /proc/sys/kernel/random/entropy_avail); \
e1=$(cat /proc/sys/kernel/random/entropy_avail); \
echo $((e1 - e0))
The result is the difference of entropy in bits before and after a cat invocation.

Note that this compound command must be entered in one go: you cannot split it into 3 lines, as the interrupts caused by your typing would contribute extra random bits and spoil the measurement.

Just to prove that this command has no other effect on the entropy than the one stated, let's try this counter-example:

e0=$(</proc/sys/kernel/random/entropy_avail); \
e1=$(</proc/sys/kernel/random/entropy_avail); \
echo $((e1 - e0))
This is the same code as before, but the cat is replaced by a Bash trick that does the same without spawning a new process. The expected result is zero.

Now a quick comment on the results I found: my 32-bit kernel with ASLR enabled, consumes exactly 128 bits of entropy for every new process. Missing any other source of random data, it takes as few as 32 commands to exhaust a full 4096-bit pool. No surprise, then, my system comes to a halt after just some minutes of unattended aptitude upgrade!


Posted by mcortese on Thu 30 Jun 2011 at 12:10
Tags: none.
After installing a 2.6.38 kernel, I've seen the machine unexpectedly pausing when I'm not in front of it (typical scenario: while aptitude installs or upgrades things). It then recovers immediately as soon as I move the mouse.

Tracking /proc/sys/kernel/random/entropy_avail reveals it is constantly below 1000, quickly going down to ~100 in just a few seconds of inactivity.

I'm curious to track down who's eating up my entropy. Anybody knows how?

Then I wonder what changed in the latest kernel that's causing this behaviour.

Anybody has the same issue?


Posted by mcortese on Fri 25 Mar 2011 at 15:35
Tags: ,
I'm fighting with Grub2 to get a completely quiet boot... without success! I edited /etc/default/grub:
but nevertheless the Squeeze background flashes for about 1 second.

I also tried with GRUB_HIDDEN_TIMEOUT=0, but likely the Shift key is not detected on my Asus EeePC 901.

Any clue?


Posted by mcortese on Fri 15 Oct 2010 at 11:15
Tags: none.
Waiting for Debian CUT, my upgrading scheme has always been: upgrade when there's and upstream change, don't upgrade when there's a Debian release adjustment. I can tell in which of the two situations I am by checking whether the major version number (the part before the dash) changes or not.

To make it automatic is just 3 steps away:

  1. Get from aptitude the list of packages ready for upgrade (aptitude search '~U'), complete with the current and new versions (-F '%p %V %v').
  2. Pass the list through awk, which splits the version strings at the dash (split($2,Cur,"-");split($3,New,"-")) and prints the package name only if the major versions differ (if (Cur[1] != New[1]) print $1).
  3. If the output is not empty ([ -s file ]) upgrade.

The final script (omitting sanity checks etc.) is following.

aptitude search '~U' -F '%p %?V %?v' | awk \
  '{split($2,Cur,"-");split($3,New,"-"); if (Cur[1] != New[1]) print $1}' >$tmp
[ -s $tmp ] && aptitude install $(<$tmp)
rm $tmp


Posted by mcortese on Mon 27 Sep 2010 at 13:18
Tags: none.
I'm a happy user of vi(m), but sometimes I find myself trying to use Shift+arrows for selection, a habit shaped into my muscles by too many hours spent in Visual Basic Editor debugging macros for my employer.

Of course, Vim supports this selection model:

:set selectmode=key
:set keymodel=startsel,stopsel
After setting these options (either on the command line or in the .vimrc file), pressing Shift+arrow starts or extends the selection, while any unshifted arrow key clears it. This selection differs from the "usual" Visual mode in that any printable key replaces the selection, instead of being interpreted as command like in Visual mode.

The drawback is that the keymode option also affects the Visual mode, so that any unshifted arrow key after v, V or ^V obeys the stopsel and immediately stops Visual mode.

The solution I found is to remap the arrow keys with :xmap, a command that applies a mapping to Visual mode only (:vmap on the other hand, applies the mapping to both Visual and Selection modes):

:xmap <Up> k
:xmap <Down> j
:xmap <Left> h
:xmap <Right> l


Posted by mcortese on Wed 7 Apr 2010 at 09:54
Tags: none.
Has anybody really understood the logic behind the twin hwclock* init scripts?

Personally, having compiled the RTC support into the kernel, I disabled both of them at boot, and it works like a charm.


Posted by mcortese on Thu 24 Sep 2009 at 19:16
Tags: none.
I've recently upgraded Xorg from 7.3 to 7.4 (the version currently in testing), only to discover that mouse and keyboard were not recognized any more. Booting in single user mode and typing
# /etc/init.d/gdm start; sleep 10; /etc/init.d/gdm stop
was enough to get myself a useful log to inspect.

The issue showed up in two surprisingly innocent lines:

(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
You have read correctly: they are classified "(II)", merely informational.

I, like many other users, have done without a conf file for a long time, as Xorg is perfectly able to configure itself without the user's help. Or so I thought...

Apparently, the new Xorg put all the burden of detecting and supporting input devices on HAL's shoulders, unless you specify otherwise in the conf file. HAL is the Hardware Abstraction Level, a subsystem that is supposed to take care of the low-level management of the hardware and just exposes a common interface to the applications that use it.

The new version of Xorg trusts HAL so much that it has the option AllowEmptyInput enabled by default. This means that if HAL, for some reason, does not pass any valid input device over to Xorg, the latter will be happy nonetheless. Hence the (II) non-warnings.

Now, I still have to understand why HAL fails to detect my pretty standard keyboard and mouse, but, at least, I discovered how to make my Xorg work in spite of this.

As I said before, Xorg defaults to blindly rely on HAL, but the old, legacy mouse and keyboard modules still work, if properly configured in the conf file. Setting the option AutoAddDevices to off, prevents HAL from getting in the way. A minimal conf file like the following worked for me.

Section "InputDevice"
  Identifier  "My beloved keyboard"
  Driver      "kbd"
  Option      "CoreKeyboard"
Section "InputDevice"
  Identifier  "My beloved mouse"
  Driver      "mouse"
  Option      "CorePointer"
  Option      "Device"        "/dev/input/mice"
Section "ServerFlags"
  Option      "AutoAddDevices" "False"

Of course, disabling the AutoAddDevices also drops the possibility to hotplug input devices. This is only a workaround while waiting to understand what HAL does not like in my mouse and keyboard.


Posted by mcortese on Thu 23 Apr 2009 at 14:15
Tags: none.
A poll showed up on this site some time ago about how "Debian" is pronounced.

Now I've just noticed that this question is answered, at last, on the About page and the answered is /'ən/

Whether this is short-e, long-e, or what else, remains a mystery for us non English speakers (and is indeed the reason why IPA was defined in the first place).