Christophe HENRY

Ce site ne comporte aucune information d’intérêt, sauf pour celui qui la cherche — Ĉi-retejo ne enhavas informon interesan, krom por iu kiu ĝin serĉas — This website doesn’t have any information of interest, except for who looks for it

Recover a broken crypt boot in Debian

05/04/2013 - Aucun commentaire

I've got encrypted disks that runs a Debian system. All things went fine until I remove /etc/crypttab. I thought it was useless because this file is in an encrypted volume. Why would the system need this file if it's not reachable at boot? Indeed, I was wrong.

It worked until the next kernel update. Since then, I had to manually mount the encrypted stuff before the kernel loads.
cryptsetup luksOpen /dev/xxx diskName luks none
lvm
vgchange -ay diskName
The fatal kernel update ran update-grub which rebuilds that initrd image. This image is loaded at the very start, before the kernel itself, to provide it with useful things like access to the encrypted data! The initrd must be told to handle the encryption: which disks, which way to encrypt, which logical volume, and so on. This configuration was precisely erased when the update-grub did not see any /etc/crypttab. Of course, I put it back again but nothing worked anymore.

The solution is to modify the initrd at /conf/conf.d/cryptroot with:
target=disk_crypt,source=/dev/disk,key=none,lvm=my-lvm
I installed a Debian inside a virtual machine (Virtual Box) with an approaching configuration to get clues.

Tags de l'article :

Fossil, a versionning system all-in-one: short review

24/02/2013 - Aucun commentaire

Git branching model Besides big players like Mercurial and git exists Fossil. It is a Decentralized Version Control System as the two others. It's main difference is that not only does it embed the versionning system, but also provides a wiki and a bugtracker. So when you clone such a repository you also get the wiki and the bugtracker. This has obvious advantages: you don't need to connect to any server to update documentation or to fill in a bug. Do your job as you would do for your source code, and voilà!

Wiki

I gave it a try. I don't like the wiki itself. It's not that the syntax or whatsoever is not relevant, but there's a cumbersome problem synchronizing a wiki with the source code. Say there is a development branch and a stable branch. You update the wiki of the development branch, write things about what you develop. Then it's fine. Say you rewrite something about what already exists in the stable branch. How do you propagate these changes from development to stable branch? You could try a copy/paste, if there's not many modifications. But, normally, you think of a merge. And it works. But, how can you explain a merge at this stage: the production branch merges a development branch. Developers may think that a hotfix was just picked up!

The problem is solved on Mercurial/Git by maintaining a wiki in a separate repository.

Indeed, that 's a common problem. The same problem occurs when you deal with external libraries. In Subversion, you create vendor branches, in Mercurial, you create sub-repositories or the like. The wiki is almost useless as its lifetime is not correlated to that of the program. Indeed, Fossil itself don't use its wiki! They say We find that embedded documentation works better than wiki for documenting Fossil itself since embedded documentation is versioned along with the source code, and so given a particular version of source code, it is a simple matter to find the corresponding documentation.

Bug tracking

I'd rather dream of a sort of replicated database to which I can plug my own front end. In most of projects, we may either deal with bugs by email, dedicated software or something else. There's many ways to do this, each of them with advantages and inconveniences. So, why would we be happy with the only way of handling bugs?

This problem is not totally solved by the two others repository providers BitBucket and GitHub, as they provide both such a tool but without a way to synchronize it out of their website. Contrary to the wiki, it's not easy to store the contents of the bug tracker in a repository. If one existed, it would be awesome.

Rebase

The last important thing I'm concerned about, is the rebase. About rebase and all history-modifying tools, Fossil says (3.8 Audit Trail) Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. The lack of a "rebase" function is considered a feature of Fossil, not a bug. (I highlighted some words)

It's just stupid. Everyone would like to be perfect. But we know, that, hidden in the heart of our local repositories, we all are pigs. We all need, at a time, to rewrite the history. Especially to rebase.

Rebasing Here is an example. On the picture besides, you can see a typical use case:
* Someone made C0, C1, C2.
* Alice creates locally her commit C3.
* Bob push his commit C4.

If Alice pushes, she would create a new branch as her commit is linked to C2. What she can do is to pull the changes to her side, getting C4 and to rebase. Her commit C3 will be linked to C4. All the commits are now in a single line. Fossil wants the history to be fully visible. In this case, she would need to merge, leaving her dirty and unwanted branch at the sight of everyone.

Under Subversion, which is a centralized system, the problem is similar. Because people don't want to make dirty commits, they do late and risky commits. Please remind that in Subversion, any commit is equivalent to a push in the distributed systems. The very good point in distributed systems is that their permit such history manipulation before sending any commit. Personally, I sometimes used Mercurial in conjunction with Subversion to locally make some mercurial-commits, branching before making the subversion commit.

Is it used

Yes. Making a google query against a typical sentence visible in the web interface, I found some links:

So what?

I don't recommend the use of Fossil. The idea behind an embedded wiki and bugtracker is valuable, but not the lack of history management.

Tags de l'article :

Small birthday management

11/09/2012 - Aucun commentaire

Instead of using heavy software, one can prefer using very small tools to do one single action. I did this with the birthday program. As a command line program, it has no graphical interface. The user just have to make a text file containing the birthdays and to call the executable birthday.

For instance, say I made a ~/.birthdays as is:

Linus Torvalds=28/12/1969
Richard Stallman=16/03/1953

When I launch birthday, the program searches for birthdays within 21 days, which is the default behavior. If there's none, nothing appears. Otherwise, messages about birthdays appears. For instance, I typed birthday -W999 to make it search all birthdays (within 999 days...):

Linus Torvalds is 43 years old in 3 months, 2 weeks and 3 days' time.                                                                                                               
Richard Stallman is 60 years old in 6 months and 5 days' time.

Te best is to do something to automatically check the birthdays. Here comes the crontab -e. Just insert the command at the reboot and you will get a local message when something outputs. It's also possible to insert the command in your ~/.bashrc when you connect to the command line.

The project is hosted on SourceForge and is available in Debian Linux.

Tags de l'article :

For how many states, there's more than one Googolplex of turing machines?

27/09/2011 - Commentaires fermés

This is a great way to enter the world of great numbers, with a bit of theory and practical sort of innovation...

Main terms

What is a Turing Machine?

A Turing Machine is a very simple computer which was designed by Alain Turing in 1936. A Turing Machine is described by states, each states pointing to other states according to some conditions. You may read a bit more about Turing machines in order to fell all the taste of this article.

What are Googol and Googolplex ?

A Googol is a number represented by 1 followed by 100 zeroes. That is, 10^100. A Googolplex is 10 power Googol - that is, a number represented by 1 followed by a Googol of zeroes : 10^(10^100). Somewhat huge.

What is the Log function ?

The Log function approximatively gives the number of digits of a number. It's the reciprocal function of y = 10^x. So, x = Log(y). This function is important here because of one of its main properties. It turns multiplications into additions. So, the calculations will involve far less huge numbers.

So what?

A resolution

The question is: how many states do I need to be able to build one Googolplex Turing Machines? Winter's cold, brain's hot.

The Turing Machine considered here is the more simple one: two different values and two different directions. Two values and two directions make 4 possibilities. To this, let's add the number of possible jumps: k+1 if there's k states. The +1 is due to the terminal state. So, we've got 4*(k+1) possibilities for a given value. A state having two values (0 or 1), it's (4*(k+1))^2 each state. As there is k different states, we get: (4*(k+1))^(2*k).

The problem is that this expression is obviously over k^k and that the question becomes:

k | (4*(k+1))^(2*k) >= 10^(10^100)

I must admit that I didn't have any clue on how to cleanly solve this. Trying as many values of k as possible is hopeless. Here comes the Log. As a strickly growing function the order between the left part and right part is unchanged by the Log:

k | Log( (4*(k+1))^(2*k) ) >= Log ( 10^(10^100) )
So, k | 2*k * Log( 4*(k+1) ) >= 10^100
So, k | 2*k * (Log(4) + Log(k+1)) >= 10^100

Let's Log again:
k | Log(2) + Log(k) + Log(Log(4) + Log(k+1)) >= 100

Now, it's just about using Log(k) and Log(k+1) against 100. I'm sure that it's feasible, but let's do it by a program.

The program

The program, in the Python language, browse the values using an exponential scale. Once it gets over, then it turns back a try a 10th less scale. And so on until the Log of the Log of the number of possible Turing Machines reaches 100. The formatting disappears there, I replaced tabs by underscores.

# Python
# -*- coding: utf-8 -*-

# For how many states, there's more than one gogolplex of turing machines?

from math import log

def logLogNbTuring(k): return log(2.0*k,10)+log(log(4.0,10)+log(k+1.0,10),10)

# A value of 100 means that we're searching for a number of machines greater than 10^(10^100), more than a gogolplex.
nbTenPowerTen = 100

step = 1
while logLogNbTuring(step) step /= 10
print "log(step,10) set to %i" % log(step,10)

i = 1
belowValue = i
while (step>=1):
_if logLogNbTuring(i)>=nbTenPowerTen:
__i = belowValue
__step /= 10
_belowValue = i
_i+=step

# belowValue contains the last value before the limit, so add 1 to get over the limit
i = belowValue + 1
print "nbTenPowerTen=%i, solution=%i" % (nbTenPowerTen, i)
print "log(solution,10)=%f" % log(i,10)

The result

answer = 50 860 333 466 396 650 825 817 657 241 650 242 602 634 644 785 968 021 580 236 147 821 863 292 723 816 479 721 264 913 714 249 728
I think that because of rounds that this number is not strictly the exact solution. But that's not the point: Log(answer) = 97.70 means that answer almost equals 10^100, a Googol.

A Turing machine with almost one Googol states means one Googolplex possibility of Turing machines.

Tags de l'article :

Recover a broken crypt boot in Debian

05/04/2013 - Aucun commentaire

I've got encrypted disks that runs a Debian system. All things went fine until I remove /etc/crypttab. I thought it was useless because this file is in an encrypted volume. Why would the system need this file if it's not reachable at boot? Indeed, I was wrong.

It worked until the next kernel update. Since then, I had to manually mount the encrypted stuff before the kernel loads.
cryptsetup luksOpen /dev/xxx diskName luks none
lvm
vgchange -ay diskName
The fatal kernel update ran update-grub which rebuilds that initrd image. This image is loaded at the very start, before the kernel itself, to provide it with useful things like access to the encrypted data! The initrd must be told to handle the encryption: which disks, which way to encrypt, which logical volume, and so on. This configuration was precisely erased when the update-grub did not see any /etc/crypttab. Of course, I put it back again but nothing worked anymore.

The solution is to modify the initrd at /conf/conf.d/cryptroot with:
target=disk_crypt,source=/dev/disk,key=none,lvm=my-lvm
I installed a Debian inside a virtual machine (Virtual Box) with an approaching configuration to get clues.

Tags de l'article :

Fossil, a versionning system all-in-one: short review

24/02/2013 - Aucun commentaire

Git branching model Besides big players like Mercurial and git exists Fossil. It is a Decentralized Version Control System as the two others. It's main difference is that not only does it embed the versionning system, but also provides a wiki and a bugtracker. So when you clone such a repository you also get the wiki and the bugtracker. This has obvious advantages: you don't need to connect to any server to update documentation or to fill in a bug. Do your job as you would do for your source code, and voilà!

Wiki

I gave it a try. I don't like the wiki itself. It's not that the syntax or whatsoever is not relevant, but there's a cumbersome problem synchronizing a wiki with the source code. Say there is a development branch and a stable branch. You update the wiki of the development branch, write things about what you develop. Then it's fine. Say you rewrite something about what already exists in the stable branch. How do you propagate these changes from development to stable branch? You could try a copy/paste, if there's not many modifications. But, normally, you think of a merge. And it works. But, how can you explain a merge at this stage: the production branch merges a development branch. Developers may think that a hotfix was just picked up!

The problem is solved on Mercurial/Git by maintaining a wiki in a separate repository.

Indeed, that 's a common problem. The same problem occurs when you deal with external libraries. In Subversion, you create vendor branches, in Mercurial, you create sub-repositories or the like. The wiki is almost useless as its lifetime is not correlated to that of the program. Indeed, Fossil itself don't use its wiki! They say We find that embedded documentation works better than wiki for documenting Fossil itself since embedded documentation is versioned along with the source code, and so given a particular version of source code, it is a simple matter to find the corresponding documentation.

Bug tracking

I'd rather dream of a sort of replicated database to which I can plug my own front end. In most of projects, we may either deal with bugs by email, dedicated software or something else. There's many ways to do this, each of them with advantages and inconveniences. So, why would we be happy with the only way of handling bugs?

This problem is not totally solved by the two others repository providers BitBucket and GitHub, as they provide both such a tool but without a way to synchronize it out of their website. Contrary to the wiki, it's not easy to store the contents of the bug tracker in a repository. If one existed, it would be awesome.

Rebase

The last important thing I'm concerned about, is the rebase. About rebase and all history-modifying tools, Fossil says (3.8 Audit Trail) Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. The lack of a "rebase" function is considered a feature of Fossil, not a bug. (I highlighted some words)

It's just stupid. Everyone would like to be perfect. But we know, that, hidden in the heart of our local repositories, we all are pigs. We all need, at a time, to rewrite the history. Especially to rebase.

Rebasing Here is an example. On the picture besides, you can see a typical use case:
* Someone made C0, C1, C2.
* Alice creates locally her commit C3.
* Bob push his commit C4.

If Alice pushes, she would create a new branch as her commit is linked to C2. What she can do is to pull the changes to her side, getting C4 and to rebase. Her commit C3 will be linked to C4. All the commits are now in a single line. Fossil wants the history to be fully visible. In this case, she would need to merge, leaving her dirty and unwanted branch at the sight of everyone.

Under Subversion, which is a centralized system, the problem is similar. Because people don't want to make dirty commits, they do late and risky commits. Please remind that in Subversion, any commit is equivalent to a push in the distributed systems. The very good point in distributed systems is that their permit such history manipulation before sending any commit. Personally, I sometimes used Mercurial in conjunction with Subversion to locally make some mercurial-commits, branching before making the subversion commit.

Is it used

Yes. Making a google query against a typical sentence visible in the web interface, I found some links:

So what?

I don't recommend the use of Fossil. The idea behind an embedded wiki and bugtracker is valuable, but not the lack of history management.

Tags de l'article :

Small birthday management

11/09/2012 - Aucun commentaire

Instead of using heavy software, one can prefer using very small tools to do one single action. I did this with the birthday program. As a command line program, it has no graphical interface. The user just have to make a text file containing the birthdays and to call the executable birthday.

For instance, say I made a ~/.birthdays as is:

Linus Torvalds=28/12/1969
Richard Stallman=16/03/1953

When I launch birthday, the program searches for birthdays within 21 days, which is the default behavior. If there's none, nothing appears. Otherwise, messages about birthdays appears. For instance, I typed birthday -W999 to make it search all birthdays (within 999 days...):

Linus Torvalds is 43 years old in 3 months, 2 weeks and 3 days' time.                                                                                                               
Richard Stallman is 60 years old in 6 months and 5 days' time.

Te best is to do something to automatically check the birthdays. Here comes the crontab -e. Just insert the command at the reboot and you will get a local message when something outputs. It's also possible to insert the command in your ~/.bashrc when you connect to the command line.

The project is hosted on SourceForge and is available in Debian Linux.

Tags de l'article :

For how many states, there's more than one Googolplex of turing machines?

27/09/2011 - Commentaires fermés

This is a great way to enter the world of great numbers, with a bit of theory and practical sort of innovation...

Main terms

What is a Turing Machine?

A Turing Machine is a very simple computer which was designed by Alain Turing in 1936. A Turing Machine is described by states, each states pointing to other states according to some conditions. You may read a bit more about Turing machines in order to fell all the taste of this article.

What are Googol and Googolplex ?

A Googol is a number represented by 1 followed by 100 zeroes. That is, 10^100. A Googolplex is 10 power Googol - that is, a number represented by 1 followed by a Googol of zeroes : 10^(10^100). Somewhat huge.

What is the Log function ?

The Log function approximatively gives the number of digits of a number. It's the reciprocal function of y = 10^x. So, x = Log(y). This function is important here because of one of its main properties. It turns multiplications into additions. So, the calculations will involve far less huge numbers.

So what?

A resolution

The question is: how many states do I need to be able to build one Googolplex Turing Machines? Winter's cold, brain's hot.

The Turing Machine considered here is the more simple one: two different values and two different directions. Two values and two directions make 4 possibilities. To this, let's add the number of possible jumps: k+1 if there's k states. The +1 is due to the terminal state. So, we've got 4*(k+1) possibilities for a given value. A state having two values (0 or 1), it's (4*(k+1))^2 each state. As there is k different states, we get: (4*(k+1))^(2*k).

The problem is that this expression is obviously over k^k and that the question becomes:

k | (4*(k+1))^(2*k) >= 10^(10^100)

I must admit that I didn't have any clue on how to cleanly solve this. Trying as many values of k as possible is hopeless. Here comes the Log. As a strickly growing function the order between the left part and right part is unchanged by the Log:

k | Log( (4*(k+1))^(2*k) ) >= Log ( 10^(10^100) )
So, k | 2*k * Log( 4*(k+1) ) >= 10^100
So, k | 2*k * (Log(4) + Log(k+1)) >= 10^100

Let's Log again:
k | Log(2) + Log(k) + Log(Log(4) + Log(k+1)) >= 100

Now, it's just about using Log(k) and Log(k+1) against 100. I'm sure that it's feasible, but let's do it by a program.

The program

The program, in the Python language, browse the values using an exponential scale. Once it gets over, then it turns back a try a 10th less scale. And so on until the Log of the Log of the number of possible Turing Machines reaches 100. The formatting disappears there, I replaced tabs by underscores.

# Python
# -*- coding: utf-8 -*-

# For how many states, there's more than one gogolplex of turing machines?

from math import log

def logLogNbTuring(k): return log(2.0*k,10)+log(log(4.0,10)+log(k+1.0,10),10)

# A value of 100 means that we're searching for a number of machines greater than 10^(10^100), more than a gogolplex.
nbTenPowerTen = 100

step = 1
while logLogNbTuring(step) step /= 10
print "log(step,10) set to %i" % log(step,10)

i = 1
belowValue = i
while (step>=1):
_if logLogNbTuring(i)>=nbTenPowerTen:
__i = belowValue
__step /= 10
_belowValue = i
_i+=step

# belowValue contains the last value before the limit, so add 1 to get over the limit
i = belowValue + 1
print "nbTenPowerTen=%i, solution=%i" % (nbTenPowerTen, i)
print "log(solution,10)=%f" % log(i,10)

The result

answer = 50 860 333 466 396 650 825 817 657 241 650 242 602 634 644 785 968 021 580 236 147 821 863 292 723 816 479 721 264 913 714 249 728
I think that because of rounds that this number is not strictly the exact solution. But that's not the point: Log(answer) = 97.70 means that answer almost equals 10^100, a Googol.

A Turing machine with almost one Googol states means one Googolplex possibility of Turing machines.

Tags de l'article :