Philippe F a écrit 2204 commentaires

Il ne me semble que SCO est plutôt sous contrôle judiciaire mais pas en liquidation.

Je suis loin d'être un expert mais voilà ce que j'avais compris :

La liquidation, c'est quand la boite est finie et qu'un contrôleur vient pour tout vendre pour payer les créanciers.

Le contrôle, c'est l'étape avant. La société n'a plus les moyens de faire face à ses créances donc elle se met sous un statut spécial, qui l'autorise à ne pas payer ses créances pendant quelques temps, qui lui laisse le temps de redresser la barre. Si la barre n'est pas redressée, on aboutit à la liquidation.

Mandrake avait été placé sous contrôle judiciaire pendant 6 mois si je me souviens bien.

C'est clair qu'il se passe des choses en coulisses. De là à dire que ce n'est pas très sain, j'en suis pas sûr. Souvent par exemple, les changements de travail se font dans la discrétion. Va-t-on voir l'arrivée d'un nouveau projet ou une nouvelle prise en charge de Thunderbird ? Je l'espère !

C'est le vrai Linus parce qu'il est identifié par ses commits sur le noyau et sur git. Les commits sur git étant signés, je pense que c'est bien lui.

Le but de ohloh n'est pas tant de créer des liens que de montrer ceux qui existent. Montrer qui contribue à quoi et depuis combien de temps. L'idée est plus ou moins d'avoir une cartographie des développeurs et utilisateurs open source.

Le business-model est encore un peu flou mais ils comptent gagner de l'argent en proposant des services aux sociétés qui ne connaissent pas bien l'open source, pour mieux explorer le concept, voir qui est qui.

Pour les gens qui connaissent l'open source, c'est sympa d'avoir une mesure publique des contributions. C'est aussi un moyen de faire une validation effective de tes contributions auprès d'un potentiel employeur : voyez; il programme depuis 5 ans en brainfuck [1]et il a écrit pour 100 000 euro de code. Tous les employeurs ne maîtrisent pas svn ou CVS.



[1] brainfuck : http://www.muppetlabs.com/~breadbox/bf/

J'ai déjà vu l'expression "Joe Six Packs" utilisée.

Je suis admiratif du travail effectué sur ce langage qui a l'air bien sympathique. Par contre, côté syntaxe, je souffre.

Je suppose qu'une partie de la syntaxe est héritée du SmallTalk ou de Eiffel, en tout cas d'un langage que je ne connais pas. J'ai vraiment du mal à comprendre la logique des exemples de code.

La page sur la simplicité vante le faible nombre de mot-clé, mais j'ai l'impression que cela se paie en "caractère-clé", ce qui rend le code plutôt pénible à déchiffrer. Comme Perl quoi...

Le passage de versions majeurs est un probleme récurrent de tout logiciel, libre ou pas libre.

A un moment, si tu veux évoluer, il faut casser la compatibilité pour introduire des nouvelles fonctionnalités. C'est le cas pour Qt, KDE1 -> KDE2 et KDE3 -> KDE4, Gnome 1 -> Gnome 2 , apache1 -> apache2.

Repousser le passage ne fait que compliquer la tâche.

Mais voila, un programmeur aime faire évoluer son logiciel. Python 2.6 ne va pas disparaitre par ailleurs, donc des milliers d'applications continueront a fonctionner correctement. Ca, c'est la bonne nouvelle.

C'est de l'humour foireux en jouant sur les anagrammes : EKD ? Nogem ? Guilem de Cazai ? Ca ne te dit rien ?

Dans d'autres news, ce serait le sujet de nombreux trolls...

Evidemment, tout ca n'a rien a voir avec le projet EKD. Mais bon, si dans linuxfr, les posts etaient en rapport avec les sujets de news, ca se saurait...

Nogem, c'est mieux, tout le monde le sait. C'est grace a Guilem de Cazai.

--> []

<< On peut comparer la transition xp->vista avec la transition windows 2000->XP dont l'utilité et la valeur ajoutée était déja moins évidente. >>

Le fait que ca n'apporte que peu de valeur ajoutee n'a pas empeche les particuliers puis les entreprises de migrer peu a peu, jusqu'a completement.

Vista s'imposera sans difficulte, comme ses predecesseurs. Rien que par le marche des portables pre-installes, vista a deja gagne. Essaye d'acheter un portable avec windows 2000 ou windows XP pour voir ...

Tu as bien résumé la situation.

Je me réjouis de constater que c'est la deuxième technologie KDE qui démarre dans KDE et prend ensuite son propre envol. Je prends ça comme un gage de la qualité technique de ce que fait KDE.

Et au final, KDE adopte la nouvelle version de la technologie, laissant tomber sa propre version. Je ne pense pas qu'on puisse les taxer de Not Invented Here !

Ce qui est impressionnant, c'est que khtml a été développé par deux développeurs et demi, durant leur temps libre (David Faure et Lard Knoll principalement).

Un brevet doit aussi repondre a des criteres d'inventivite.

Ce n'est pas parce qu'il n'y a pas d'anteriorite qu'on obtient un brevet.

De plus la recherche n'est pas une preuve de l'absence d'anteriorite. C'est plutot pour l'inventeur, pour qu'il verifie qu'il n'est pas en train de depenser de l'argent pour deposer un brevet sur qqch qui existe deja.

N'importe quelle entreprise peut s'inscrire a l'AFNOR, il suffit de payer la cotisation annuelle qui est de l'ordre de 1000 euro par groupe de travail si je me souviens bien.

Le principe de l'AFNOR, c'est de reunir les acteurs interesses par un sujet pour arriver a une position sur la normalisation de tel ou tel aspects. Il n'est donc pas choquant d'y retrouver microsoft. Il faudrait juste que d'autres acteurs du libre y soit representes, comme l'association OpenOffice, des SSLL, pour faire contrepoid aux autres participants.

En pratique, les representants de chaque societe se battent pour faire sortir une norme compatible avec ses pratiques, ses outils et ses produits. Il y a des alliances de toute sorte entre participant pour lutter contre telle ou telle partie de la norme, favorable ou defavorable a telle societe (tu votes contre a l'article 54 et je vote pour a l'article 37, ok ?).

Je suis en train de découvrir.

Je suis extrêmement impressionné par la qualité de TinyERP:

1. Le site web limpide. Les démonstrations flash sont très claires et permettent de voir facilement ce qu'on peut faire avec le client.

2. Un client web très facile à manier. C'est extrêmement rare, la plupart des projets estiment que le à partir du moment où on a quelques boutons et formulaires html, on a un client web. La qualité de l'interaction va rendre l'outil agréable à utiliser ou pénible. Visiblement, tinyErp a fait très attention à cet aspect. Les pages sont agréables, claires et ont l'air riches en fonctionnalités.

3. Un client lourd pour ceux qui n'aiment pas les clients web. Bien, les clients lourds permettent d'avoir des interactions plus complexes donc d'être plus efficace.

4. Une large offre de modules.

5. Très peu de dépendances à l'installation. Ca veut dire qu'il n'y aura qu'un petit nombre limité de problèmes.

J'ai hâte de voir ce que ça donne dans la pratique. Je vais en installer un en démo dans ma boite.

J'ai l'imression d'être complètement à la rue. C'est quoi un UMPC ?

Pour les gens qui ne connaissent rien a la programmation à base de modèle (comme moi), et qui ont toujours été effrayé ou ennuyé par UML, tu as quelques recommandations ? Du genre digeste et on a l'impression qu'on pourra s'en servir un jour ?

Mon apriori très fort est que de toute façon, tu peux mettre tous les générateurs que tu veux, il bien un moment où tu dois écrire le code.

Tu parles de EMF, c'est quoi ?

Est-ce que ce type d'approche de la programmation marche réellement en pratique ? Je prends un exemple concret : je travaille sur un moteur d'édition vi ( http://www.yzis.org ). Que pourrai m'apporter la programmation à base de modèle et de code généré ?

En gros, l'indépendant qui va prendre sur son temps libre pr éventuellement améliorer une ligne de code de la NASA, c'est pas que ce sera un pauvre exploité, c'est qu'il aura sûrement trouvé une super utilité du code de la NASA pour une utilisation perso (par exemple)

On peut meme imaginer qu'il essaye de rentrer a la NASA en se faisant remarquer par ce biais :-)

Je gere 4 annees de mail pro et prive avec thunderbird, et force est de constater qu'il pedale grave. Au bout d'une quantite importante de mail, il n'arrive plus a compacter des boites mails. Des messages effaces depuis longtemp se mettre a re-apparaitre. Mon associe garde 4 annees de mail dans le meme repertoire (y compris 4 annes de commits CVS sur notre produit logiciel). Impossible de compacter sa boite ou de faire une recherche dessus dans y passer 20 minutes.

Autre probleme (vu sur un autre ordinateur), si le disque dur est endommage et qu'un secteur contenant un message n'est plus lisible, c'est toute le repertoire qui part en couille alors que avec maildir, seul un message est corrompu.

Maildir a le gros avantage de laisser la problematique de fragmentation et compaction a une technologie qui a fait ses preuves depuis des annees : le systeme de fichier.

Concernant les recherches, je ne sais pas si c'est le format mbox mais thunderbird est particulierement lent dans ce domaine.

Toujours pas de support pour maildir, ce qui fait que la recherche de message est longue et leur gestion penible.

Toujours pas de support des fichiers tnef :
https://bugzilla.mozilla.org/show_bug.cgi?id=77811

Globalement, meme si j'aime bien thunderbird, il y a pas mal de choses qui sont lourdingue (comme celles que je viens de citer).

J'espere que je trouverai des choses qui me plaisent dans cette version nouvelle.

Reste quand meme la question principale du deplacement. Avec mon portable, je travaille dans le TGV, dans l'avion, dans le RER et parfois meme dans le metro.

J'imagine mal comment un bureau tout connecte a l'heure actuel peut repondre a cette problematique.

Cela dit, si les serveurs web ont resolu tous les problemes, et que la connectivite reste le dernier, cela ne restera pas un probleme tres longtemp. On peut imaginer une technologie qui exporte une application en ligne sur un serveur web local a la machine permettant a l'utilisateur de travailler en local et de se re-synchroniser derriere.

On deplacerait le poids de la synchronisation non plus sur les applications mais sur un backend de syncrhonisation. Au final, on arrivera pas tellement loin en terme de difficulte du client lourd.

- RedHat a une notoriété dans le monde Linux que Oracle n'a pas.

Certe, mais Oracle a une très grande notoriété par ailleurs. Ils vont à mon avis capter des clients un peu hésitant sur Linux, qui seront rassurés par un nom comme Oracle. Et puis, les prix moins cher, c'est un argument de poids.

- RedHat a des certifications que la copie oracle n'a pas non-plus (très important pour les grandes entreprises)

Oracle distribue une version identique à Redhat. Au mieux, les certifications sont transférées directement. Au pire, il faut les repasser, ça va pas être un gros trous dans le budget de Oracle.

- Tant que le linux d'oracle est basé sur redhat, le linux d'oracle ne peut pas faire mieux que celui de redhat question patches, sous peine de s'engager dans des directions nécessitant de faire marche arrière par la suite sous peine de ne plus être compatible, ...

Non, ils ne pourront pas faire mieux. Mais ils pourront faire exactement pareil, et pour moins cher.

- RedHat est un gigantesque contributeur dans le monde linux, c'est un très gros avantage question maîtrise technologique.

C'est leur plus gros avantage. Ils peuvent sans problème sortir un kernel aux petits oignons pour un client specifique, ou patcher Gnome à tour de bras. Ca leur donne un avantage compétitif sur Oracle pour ce qui est de la customisation. Mais pour le standard, Oracle et Redhat seront à égalité. Oracle peut aussi engager des développeurs kernel, Gnome ou même KDE ...

Redhat a beau connaitre sa distribution mieux que quiconque, n'importe qui peut finir par acquérir ce savoir. Pour faire du support à un client, il n'est pas nécessaire d'être le méga expert de toute la distribution. Il suffit de maitriser les parties qui intéressent le client. Et de savoir lire du code source (shell principalement).

<<
Parce qu'un client, c'est frileux et pressé: quand il y a un problème un jour, il faut que la réponse tombe la veille, tellement ils sont pressés de tout remettre en production (ce que je comprends parfaitement)
>>

Penses-tu vraiment que Oracle ne comprend pas cela ? Qu'il ne sont pas capables d'aligner les mecs qui vont bien pour satisfaire le client ?

Ce qui se passe ici, c'est très grave. J'avais déjà évoqué ce risque lié au modèle économique du logiciel libre. Mais le voir arriver à la taille de Oracle et à la plus grosse distribution linux, ça fait froid dans le dos.

Pour Oracle, c'est simple. Redhat produit une distribution et dépense de l'argent pour cela. Oracle récupère tout le travail fournit par Redhat gratuitement et propose du support dessus. Oracle peut faire des prix de support beaucoup plus faibles que ceux de Redhat, puisqu'ils n'ont pas besoin de produire la distribution.

Pour Oracle, à court terme, c'est tout bon. Le support rapporte beaucoup d'argent, alors que vendre une distribution n'en rapporte que peu. Ils piquent à Redhat leur secteur le plus rentable.

A long terme, si Oracle est vraiment agressif, on peut imaginer qu'ils poussent tout simplement Redhat à la banqueroute. A ce moment-là, ils peuvent soit racheter Redhat pour pas cher, soit simplement embaucher des employés clés pour renforcer leurs équipes. On peut même imaginer qu'ils n'ont besoin ni de Redhat ni de ses employés et qu'ils mettent en place leur fork commercial et logiciel tranquillement.

En fait, les efforts de portage se font en parallele. KDE 4.0 ne sortira probablement pas pour windows et pour MacOs X. Mais une version MacOs devrait suivre tres rapidement, et la version windows mettra elle plus de temps compte-tenu des difficultes a adapter des logiciels unix bases sur des services unix dans un environnement windows.

Le site web de pypy est out en ce moment, mais dans mon souvenir, le principal intérêt de pypy est d'avoir une espèce de générateur d'interpréteur python.

Au lieu d'avoir un interpreteur python avec des fonctionnalités édictées une fois pour toute dans la spec, on pourrait "faire ses courses" en terme de fonctionnaliteset générer un interpréteur sur mesure.

Cela permet de modifier la grammaire de python pour des projets dédiés (programmation oriente aspect, programmation par contrat sont les exemples cités, mais on peut en trouver d'autres). On garde donc les principes de base du langage python, mais les fonctionnalités sont extensibles à merci.

J'avais posé une question à l'époque sur la faisabilité d'une inférence de type à la ocaml. C'est là qu'on m'a renvoyé vers pypy où ce genre de chose est envisageable (meme si je ne crois pas que ce soit au programme pour l'instant).

En ce qui me concerne, ce qui m'intéresserait à l'heure actuelle, ce serait une réduction de fonctionnalité : dans la façon dont j'utilise python, le typage dynamique me crée plus de problèmes qu'il n'en résoud. Je préfererai avoir un typage statique, ou en tout cas, l'interdiction a une variable de changer de type au cours de son existence. C'est possible grâce à pypy.

Maintenant, les inconvénients : d'une part, c'est quand même beaucoup plus lent, alors que python n'est déjà pas renommé pour sa vitesse. Ensuite, ça veut dire qu'on va peut-être récuperer des softs qui ne marchent qu'avec un certain jeu de fonctionnalité de l'interpréteur python, et qu'ils seront incompatibles avec d'autres softs utilisant un jeu de fonctionnalité différent.