Pourquoi les voyageurs préfèrent-ils prendre une voiture plutôt que le train ?
Dire que la SNCF fait des efforts pour rendre le voyage en train plus facile et moins coûteux, c'est simplement une vue de l'esprit, au mieux.
Aujourd'hui, dans le cadre d'un week-end de geeks au mois d'avril, nous nous sommes mis d'accord pour réserver 4 places dans un TGV, 2 mois à l'avance. 3 d'entre nous sont pères de famille nombreuse, donnant le droit à 30% ou 40% de réduction.
Prix unitaire du billet Paris/Grenoble ? 22€ à l'aller.
Prix pour 4 places ? 140 € ...
Prix unitaire pour le même billet mais en indiquant une remise Famille Nombreuse ? 35 € !!!
Alors je pose la question : de la gueule de qui se fout-on à la SNCF?
C'est bien la peine de passer à Drupal si c'est pour offrir des tarifs aussi totalement débiles !
vendredi, janvier 21, 2011
vendredi, décembre 10, 2010
Oracle, Javacle et l'ASF, ma vision du problème.
Donc The Apache Software Foundation a décidé de quitter l'Executive Community du JCP , conformément à sa position clairement exprimée en novembre.
La raison? Oracle a décidé unilatéralement de ne pas respecter les termes du contrat qui le lie à l'ASF (le fameux JSPA), et plus spécifiquement le paragraphe 5.C :
"Other than as set forth above, the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations."
En clair, ne pas fournir à l'ASF l'accès au TCK sans y ajouter une restriction d'usage (FOU) est une violation de ce contrat.
On peut bien évidemnt arguer que OpenJDK couvre le besoin d'un Java libre, puisque GPL et disposant d'un TCK sans FOU.
Sauf que si vous forkez OpenJDK, Oracle se réserve le droit de faire un procès pour violation de Patent (bien sûr, Oracle n'est pas assez stupide pour attaquer une fondation comme l'ASF, cela ne lui rapporterai rien, quand il suffit de pratiquer à grande échelle le FUD, en menaçant implictement les utilisateurs de ce fork).
Tout cela est bien résumé (en anglais) dans ce post : http://skife.org/java/jcp/2010/12/07/the-tck-trap.html.
Alors, OpenJDK, une issue de secours? Non. Un miroir aux alouettes, un cache-sexe. En tant que tel, OpenJDK est effectivement une solution temporaire pour ceux qui travaillent sur un Mac, par exemple. Le problème, c'est qu'il n'y a aucune garantie sur le long terme qu'Oracle et ses affidés ne laissent pas OpenJDK dépérir, au profit d'une version bien évidement plus puissante du langage, mais payante.
Procès en sorcellerie ? Certainement pas. Il faut ouvrir les yeux : Oracle n'est pas une entreprise philantropique, elle ne respcte aucune règle, elle les créés ! Pourquoi se priver d'exercer son pouvoir quand il n'y a pas de shérif ?
Cela touche du doigt l'origine du problème : la confusion entretenue par ces sociétés sur la signification de l'Open Source. Pour elles, Open Source = Source - IP. Vous pouvez regarder, utiliser, éventuellement contribuer, mais tous les bénéfices reviennent à la société qui gère le projet.
L'open source, c'est d'abord une question de gouvernance, et c'est ce pour quoi l'ASF se bat. Il n'y a pas de liberté sans une gouvernance partagée. En politique, ça s'appelle la démocratie, en opposition à la dictature, la ploutocratie, l'oligarchie ou tout autre système de captation de pouvoir. Ce n'est pas pour rien que la devise de l'ASF est :
Qu'est-ce que cela signifie pour Java ? Pour l'instant, pas grand chose. Tout un chacun peut l'utiliser, mais cela ne durera pas. Mais il est temps de penser la suite, et cette suite devra être totalement indépendante de sociétés comme Oracle.
L'ASF peut-elle être force de proposition ? Harmony peut-il devenir la base universelle et réellement open-source que Java aurait dû être? Sans aucun doute. Mais il y a du travail.
Alors, laissont agir la communauté :
La raison? Oracle a décidé unilatéralement de ne pas respecter les termes du contrat qui le lie à l'ASF (le fameux JSPA), et plus spécifiquement le paragraphe 5.C :
"Other than as set forth above, the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations."
En clair, ne pas fournir à l'ASF l'accès au TCK sans y ajouter une restriction d'usage (FOU) est une violation de ce contrat.
On peut bien évidemnt arguer que OpenJDK couvre le besoin d'un Java libre, puisque GPL et disposant d'un TCK sans FOU.
Sauf que si vous forkez OpenJDK, Oracle se réserve le droit de faire un procès pour violation de Patent (bien sûr, Oracle n'est pas assez stupide pour attaquer une fondation comme l'ASF, cela ne lui rapporterai rien, quand il suffit de pratiquer à grande échelle le FUD, en menaçant implictement les utilisateurs de ce fork).
Tout cela est bien résumé (en anglais) dans ce post : http://skife.org/java/jcp/2010/12/07/the-tck-trap.html.
Alors, OpenJDK, une issue de secours? Non. Un miroir aux alouettes, un cache-sexe. En tant que tel, OpenJDK est effectivement une solution temporaire pour ceux qui travaillent sur un Mac, par exemple. Le problème, c'est qu'il n'y a aucune garantie sur le long terme qu'Oracle et ses affidés ne laissent pas OpenJDK dépérir, au profit d'une version bien évidement plus puissante du langage, mais payante.
Procès en sorcellerie ? Certainement pas. Il faut ouvrir les yeux : Oracle n'est pas une entreprise philantropique, elle ne respcte aucune règle, elle les créés ! Pourquoi se priver d'exercer son pouvoir quand il n'y a pas de shérif ?
Cela touche du doigt l'origine du problème : la confusion entretenue par ces sociétés sur la signification de l'Open Source. Pour elles, Open Source = Source - IP. Vous pouvez regarder, utiliser, éventuellement contribuer, mais tous les bénéfices reviennent à la société qui gère le projet.
C'est la privatisation du profit et la mutualisation du travail.
L'open source, c'est d'abord une question de gouvernance, et c'est ce pour quoi l'ASF se bat. Il n'y a pas de liberté sans une gouvernance partagée. En politique, ça s'appelle la démocratie, en opposition à la dictature, la ploutocratie, l'oligarchie ou tout autre système de captation de pouvoir. Ce n'est pas pour rien que la devise de l'ASF est :
Community over code
Qu'est-ce que cela signifie pour Java ? Pour l'instant, pas grand chose. Tout un chacun peut l'utiliser, mais cela ne durera pas. Mais il est temps de penser la suite, et cette suite devra être totalement indépendante de sociétés comme Oracle.
L'ASF peut-elle être force de proposition ? Harmony peut-il devenir la base universelle et réellement open-source que Java aurait dû être? Sans aucun doute. Mais il y a du travail.
Alors, laissont agir la communauté :
3000 committers Apache ne peuvent pas se tromper !
dimanche, octobre 31, 2010
Bye bye summer time...
So we switched (in Europe) from summer time to winter time. At 3am, it's 2 am again. So what ?
Well, I was running some tests on my computer before crashing, and I was quite surprised to get an error in a part I didn't modified today and which was running fine this afternoon. What was wrong ?
We use some class to generate CSN (Change Sequence Number), and obviously we have some tests for this class. One of them failed for one hour...
Here is the test :
public class CsnTest
{
private SimpleDateFormat sdf = new SimpleDateFormat( "yyyyMMddHHmmss.123456'Z'" );
@Test
public void testCSN()
{
long ts = System.currentTimeMillis();
Csn csn = new Csn( sdf.format( new Date( ts ) ) + "#123456#abc#654321" );
assertEquals( ts/1000, csn.getTimestamp()/1000 ); <<---- This assert fails.
Why did I get an error ? Because the way we create the CSN is simply wrong : we don't take into account the fact that the computer is not necessarily always using the same time zone, and that some operation assumes that it got a GMT based time, when other uses the Locale.
Be extremely cautious when dealing with dates and time zones : you may get a very bad surprise in production, instead of experimenting those errors by chance, just because you are running tests at 2:30 am a Saturday before going to bed !
Well, I was running some tests on my computer before crashing, and I was quite surprised to get an error in a part I didn't modified today and which was running fine this afternoon. What was wrong ?
We use some class to generate CSN (Change Sequence Number), and obviously we have some tests for this class. One of them failed for one hour...
Here is the test :
public class CsnTest
{
private SimpleDateFormat sdf = new SimpleDateFormat( "yyyyMMddHHmmss.123456'Z'" );
@Test
public void testCSN()
{
long ts = System.currentTimeMillis();
Csn csn = new Csn( sdf.format( new Date( ts ) ) + "#123456#abc#654321" );
assertEquals( ts/1000, csn.getTimestamp()/1000 ); <<---- This assert fails.
Why did I get an error ? Because the way we create the CSN is simply wrong : we don't take into account the fact that the computer is not necessarily always using the same time zone, and that some operation assumes that it got a GMT based time, when other uses the Locale.
Be extremely cautious when dealing with dates and time zones : you may get a very bad surprise in production, instead of experimenting those errors by chance, just because you are running tests at 2:30 am a Saturday before going to bed !
lundi, septembre 20, 2010
Maven community is sometime a strange world ...
3 years ago, I submitted a patch for the Maven antlr plugin. Something quite simple that took me 1 hour to whip, test and to send as a JIRA [1]
It took 6 months for this patch to be applied, something I can understand.
However, 3 years after the code has been patched, I can't get the plugin from the Apache repository, where it was before. Why ? Because the project has been moved from Apache to Mojo. The reason ?
"A release could be done shortly but I would like to move the maven-antlr-plugin and maven-antlr3-plugin (in sandbox) to Mojoproject.
During the last year, I am the main committer on this project. Recently, David Holroyd provided a new plugin that supports Antlr v3, and submitted some patches. Unfornately, he is not an ASF committer. I could take care of David's patches but I think it should be good to give a new life of this project in the Mojo land. It would be more easy to give access to David, so he could maintain it as he wants. " [2]
What's wrong in the Maven community if they can't make someone who is obviously proposing patches and is a wanna-be committer if they have to move the project out of Apache to get this guy working on the project ? Voting process is too complex ?
Seriously, I don't get it ...
PS : of course, I can get the plugin from the Apache repo, but not at the same place. It's now available on [3].
[1] http://jira.codehaus.org/browse/MANTLR-14
[2] http://maven.40175.n5.nabble.com/vote-Move-the-maven-antlr-plugin-to-the-mojo-project-td204608.html#a204608
[3] http://repo1.maven.org/maven2/org/codehaus/mojo/antlr-maven-plugin/2.1/
It took 6 months for this patch to be applied, something I can understand.
However, 3 years after the code has been patched, I can't get the plugin from the Apache repository, where it was before. Why ? Because the project has been moved from Apache to Mojo. The reason ?
"A release could be done shortly but I would like to move the maven-antlr-plugin and maven-antlr3-plugin (in sandbox) to Mojoproject.
During the last year, I am the main committer on this project. Recently, David Holroyd provided a new plugin that supports Antlr v3, and submitted some patches. Unfornately, he is not an ASF committer. I could take care of David's patches but I think it should be good to give a new life of this project in the Mojo land. It would be more easy to give access to David, so he could maintain it as he wants. " [2]
What's wrong in the Maven community if they can't make someone who is obviously proposing patches and is a wanna-be committer if they have to move the project out of Apache to get this guy working on the project ? Voting process is too complex ?
Seriously, I don't get it ...
PS : of course, I can get the plugin from the Apache repo, but not at the same place. It's now available on [3].
[1] http://jira.codehaus.org/browse/MANTLR-14
[2] http://maven.40175.n5.nabble.com/vote-Move-the-maven-antlr-plugin-to-the-mojo-project-td204608.html#a204608
[3] http://repo1.maven.org/maven2/org/codehaus/mojo/antlr-maven-plugin/2.1/
mardi, juin 22, 2010
Twitter failures...
It seems that Twitter has reached is limits a few weeks ago, with daily failures since then.
I'm just wondering if Twitter's developpers are french, with a project manager named Domenech, and a top developper named Anelka.
Or maybe I'm mixing failures : in any case, if we use the french soccer team as a base to measure other teams failure, then Twitter is just experiencing small bumps on the road atm...
I'm just wondering if Twitter's developpers are french, with a project manager named Domenech, and a top developper named Anelka.
Or maybe I'm mixing failures : in any case, if we use the french soccer team as a base to measure other teams failure, then Twitter is just experiencing small bumps on the road atm...
mardi, juin 01, 2010
Microsoft is shooting itself in the foot
So today I received a phone call from the Microsoft 'client support' (so called) entity.
It's pretty clear that they are more into following a process, even if it's totally stupid, than helping customers. (remind me Dr Strangelove, when the guy can break a CocaCola machine to get the 10 cents he needed to give a phone call that would have saved the world ...).
Instead of solving my simple issue with a simple solution (namely, providing me the KEY that is associated with the installed product, which is different from the product we bought - a Windows 7 premium. Probably because the DVD was badly stamped before being put into the box), they keep going insisting that we install a new version, losing 2 more hours plus having to reinstall all the side products.
Seriously, it's time to think about switching to some more friendly system, people. Ubuntu is quite usable, so is Mac OSX (but you might face the exact same problem). In any case, making 25% margin is just a shame when the UQOS (unquality of service) provided is so high : basically, you are on your own.
Coupled to the fact that they have delegated the first level support to external companies in low cost countries (profits, it's all about profits), it makes it pretty obvious that Microsoft is equivalent to what IBM was back in the 1990.
The butterfly is now just an elephant, not a dancing one... Sea elephant on the shore.
lundi, mai 31, 2010
Maven release failures
So today I had to generate the MINA 2.0.0 packages in order to launch a vote. We have a full page on MINA web site explaining how to cut a release : http://mina.apache.org/developer-guide.html#DeveloperGuide-ReleasingaPointRelease%2528CommittersOnly%2529
1) Check that there are no uncommitted changes in the sources : OK
2) Check that there are no SNAPSHOT dependencies : OK
3) Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use) : OK
(here, we went from 2.0.0-RC2-SNAPSHOT to 2.0.0)
4) Transform the SCM information in the POM to include the final destination of the tag : OK
(the SCM info is nowscm:svn:http://svn.apache.org/repos/asf/mina/tags/2.0.0 , as expected)
5) Run the project tests against the modified POMs to confirm everything is in working order : OK
6) Commit the modified POMs : KO!!!
I must say that Maven Release plugin is either totally dumb, or that what it does is totally counter-intuitive, and broken, IMHO.
What is the problem ? The maven release:prepare follows the steps :
1) Check that there are no uncommitted changes in the sources : OK
2) Check that there are no SNAPSHOT dependencies : OK
3) Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use) : OK
(here, we went from 2.0.0-RC2-SNAPSHOT to 2.0.0)
4) Transform the SCM information in the POM to include the final destination of the tag : OK
(the SCM info is now
5) Run the project tests against the modified POMs to confirm everything is in working order : OK
6) Commit the modified POMs : KO!!!
What's wrong here ? Everything has been committed in the trunk instead of the expected mina/tags/2.0.0 !
Why is the maven release plugin modifying the SCM tag if it's to commit everything in a place which should store the next version, ie 2.0.1-SNAPSHOT ?
I could understand that this is done on purpose (don't see a single reason for that, but who knows...), but at least, can't it *ask* the user before messing with the trunk ?
Sometime, the Maven Way Of Doing Things (tm) is completely broken, and this explains the complaints found on the blogsphere...
Inscription à :
Articles (Atom)
