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 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

sd:78.52207

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

entropy-vs-timehistogram-entropy

 

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 https://github.com/arbolis/personalscripts/blob/master/script-gentoo-time-compilation.sh and https://github.com/arbolis/personalscripts/blob/master/gentoo-results.R respectively.

Average number of stones randomly placed on a 19×19 goban so that 2 are adjacent

This time what caught my attention was the average number of stones ramdomly placed on a 19×19 goban required such that 2 stones are adjacent.

So I’ve written a python program (https://github.com/arbolis/pythonstuff/blob/master/goproblem_random/gorandom_1.py) and a R script for the plotting part (https://github.com/arbolis/personalscripts/blob/master/goban_random.R) to solve the problem numerically. It turns out that the number is around 13.1 which, in my opinion, is counter intuitive in the sense that most go players expect that number to be much higher (scarce are the go players who predicted a number below 30).

Anyway here is a summary of the data after 1,000,000 simulations of placing stones on a 19×19 goban until 2 stones are adjacent:

Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
2.00    8.00   12.00   12.97   17.00   49.00

And there comes a bar plot:bar-plot-go-19x19

I find that plot interesting and the summary of the data interesting.

Now I could get similar data for the 8×8 chessboard. Out of my memory the number of pieces randomly placed on a chessboard until 2 are adjacent is around 6.1. I expect a similar histogram than the one for the game of go somehow, except that the width of the distribution should be much smaller.