Number of times each package was installed + upgraded in Arch Linux

I’ve made a Python script that (for now at least) plots the number of times each package on my system was installed + upgraded. That is, if the y-axis reads “2”, it means the package was installed and upgraded once. If the y-axis reads “1” it means the package was installed once and never upgraded.

As my system is rather new (about 2 months old), most packages were not upgraded. The package that was most upgraded was Linux (10 times), followed by youtube-dl and python-setuptools. I decided to only show the name of these 3 packages as they were the most upgraded and the x-axis would contain 531 package’s names if I were to show them all.

I seek to post the code soon on github so you can use it and modify it as you wish.


Entropy in /dev/random vs used RAM

This time I didn’t really know what to let my computer do. So I opted to let it calculate the correlation between used RAM and entropy pool level in /dev/random. At first I thought that there would be no correlation whatsoever since I thought that the two variables were almost totally unrelated. It turns out I was wrong but that makes sense now.

In order to fulfil this task, I decided to make a measurement of both values every 5 seconds, during a few hours where I’d use the computer and some minutes where I wasn’t.

The bash and R scripts that I used can be found on my github repository.

And the results there.

Here’s a plot of both the entropy and used RAM in function of time.

entropy-ram  Like one could guess from the plot, the correlation is negative. For the whole data (that goes outside the range of the graph), the correlation turns out to be worth about -0.20.

One explanation for such (surprising to me) result is that the more used RAM implies more programs running and programs seem to use /dev/random (though I wonder why they don’t use /dev/urandom instead since the latter is “ok” for more than 99% of purposes including random password generators).

One day later I decided to rerun the experiment, this time well after having rebooted my machine so that I don’t start with a low used RAM (and high entropy pool level). To my surprise the results were quite different: the correlation is worth only -0.02. A graph of the results an be found below:


It looks like long period of inactivity left both my used RAM and entropy pool level oscillating around a certain value, and as soon as activity went up in my computer both values started to be more chaotic.

Entropy of /dev/random in function of time

With a simple bash script, I’ve monitored the entropy in /dev/random, the entropy of the Linux kernel entropy pool. Note however that the way I’ve done it, it lowers the entropy’s pool level by a few bits at every entropy’s level check. So that I’ve limited the entropy checking at a frequency of 1 measurement every 2 seconds, during 6000 seconds (1 h 40 mins).

Here’s a quick summary of the data obtained:

Min.   : 728.0
1st Qu.: 929.0
Median : 986.0
Mean   : 982.3
3rd Qu.:1040.0
Max.   :1202.0


Here’s a histogram and a plot of the entropy pool level in function of time:



HP pavilion x360 and Linux, dual boot with Windows 8.1 (part 2)

The other problem I faced was reboot/shutdown not working and booting would get stuck approximately once out of three times. The fix is simple and involves disabling two kernel modules: “echo “blacklist dw_dmac” | sudo tee -a /etc/modprobe.d/blacklist.conf” and “echo “blacklist dw_dmac_core | sudo tee -a /etc/modprobe.d/blacklist.conf“. These problems should be gone. Source:

Hope it helps.

Invoke a command to generate a random password of length n

Here’s one way to generate a -good- random password of length n invoking a simple command in the terminal, like so for instance: psswd 30 , where 30 stands for a 30 characters long password.

In order to do so, you need to edit ~/.bashrc or ~/.zshrc depending whether your shell is bash or zsh, and append psswd() { LC_ALL=C tr -dc ‘a-zA-Z0-9-!”@/#$%^&*()_+~’ < /dev/urandom | head -c “$1”;echo ;} to the file, then save it and restart the terminal if you had any opened. Now typing psswd n where n stands for the password length will generate a random password that may contain alphanumerical characters as well as the special characters displayed between the 2 ‘ signs. You can of course modify the characters used to generate the passwords and the function “psswd()” to any of your like.

To finish this blog entry, here’s an example of a 100 characters long password generated by the above command: WTx@X#!O$q!b!IDu+M7gvMVTv-^QK8O-(Y”NMO&%)P1Z4)h2K03uwf(Yc^~h76yi2&CaFE$$R3L&c$XKvnBsojJ6MBgW/S$q-_&o.

Have fun.

Gentoo Linux, compilation of packages’s time

I had heard some complaints that in Gentoo Linux it takes way too much time to compile the packages that one would install in a “normal system”. I got curious and so I gathered this data on my own Gentoo system.

Note that :

  1. My cpu is an Intel Core i3-3217U CPU @ 1.80GHz. (laptop)
  2. As MAKEOPTS value, I have set to use 2 threads for compilation, having HT enabled and so 4 threads in total.
  3. I have 708 packages in total but only 608 of them have been compiled on my machine and so will be used in the data.

Visually the result can be summarized in the following histogram:

gentoo-data Some numbers about time of compilation in seconds (s):

Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
4.0    10.0    20.0   116.9    45.0 20580.0

So in average it took slightly less than 2 minutes to build a package on my system. Most packages take less than 50 s to build and only 3 took more than 1 hour to build (firefox/thunderbird and libreoffice).

Other numbers, about how many times I updated the packages:

Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
1.000   1.000   1.000   1.314   1.000   5.000

In other words most packages were built only once, the average number of times I’ve built a package is 1.314 and the most time I’ve built a package is 5 times.

Considering that I’ve a rather slow processor and “only” 4 GB of RAM, most people could achieve times of building packages up to 5 times lesser easily, I suppose.

Thus overall I’d say that keeping a system up to date in Gentoo doesn’t take too much time, especially on a modern hardware.

P.S.: The bash and R scripts I’ve used to gather and plot the data can be found at and respectively.