Bah, c'est pas nouveau, quand tu postes un truc pertinent, tu te fais moinsser, et quand tu râles après, c'est quite ou double. Souvent, tu te refait pertinenter.
Si on te le compile pour linux, en utilisant la winelib, c'est natif alors ?
Si je te donne un programme Java écrit sous Windows, ça veut dire quoi en faire un portage natif sous Linux ? Faut obligatoirement que ça soit un ELF ?
> Concernant le chantier en Inde, il y avait un projet de transfert de compétence
> dans le contrat, avec formation des équipes sur place...
Mouais, faut mal connaitre les normes de sécurité et usages en Inde pour croire que ça se serait passé sans danger pour la santé des ouvriers, tout ça ...
Avec Word 97, tu pouvais insérer un bout de feuille de calcul excel dedans, oui. Quand tu cliquais sur le morceau de feuille de calcul, la barre de menu et d'outils devenait celle d'excel, et tu pouvais éditer en ligne.
Ceci dit, à l'époque, ça marchait tellement mal que j'avais pris l'habitude de copier -> collage spécial -> coller et temps qu'image parce que sinon, tu pouvais être sur qu'il te foirait la mise en page à la prochaine modif. Je ne sais pas si ça a progressé depuis, il paraît que oui.
Si il n'y avait qu'un seul objectif dans « le mouvement du logiciel libre », ça se saurait ! Bien sûr que je carricature en disant que le but du libre est de péter la gueule à MS, mais si tu regardes un peu ce qui se fait ça et là, c'est quand même un objectif affiché de pas mal de monde :
Personne a compris la blague ou quoi ? Le dessin attribue à un dirigeant de Google une fameuse citation de Linus Torvalds, et il faut bien avouer que la citation va aussi bien à l'un qu'à l'autre !
« Plus proche du libre » => même objectif => peter la gueule à MS (mais faut pas le dire).
Euh, l'auteur de la news fait ça pour chaque sortie de distrib majeure, à ma connaissance bénévolement. On imagine que ça prend un certain temps ... Le but est juste d'avoir un apperçu de la distribution.
Maintenant, en effet, pour un « test », il aurait fallu tester ça sur au moins une dizaine de machines différentes, le faire utiliser par plusieurs personnes avec des habitudes différentes, ... si ça t'intéresse d'en faire un, ne te gènes pas.
Comme tout projet qui se respecte, la date de sortie, c'est invariablement « dans un mois », avec mise à jour de la page pour changer la date régulièrement. C'était « mai 2006 », c'est passé « entre mai et juillet 2006 », et je ne serais pas surpris qu'il n'y ai rien avant aout ;-).
C'est sans doute quelque chose comme ça qui se prépare avec Ultéo ( http://ulteo.com/ ). En tous cas, il y a des histoires de live-CD et c'est « a new concept which relies on broadband network access to ease the way people use computers. ».
On verra en Mai 2006, quand la première béta sera sortie ;-).
Damned, mais alors quelle est donc cette distribution qui fourni tous les logiciels du monde dans une seule et même distrib ?
Genre, une entreprise X développe un truc Y en interne, quand elle fait une upgrade de sa Debian, elle récupère la version suivante de Y directement dans la distrib ?
Ça m'a l'air cool le monde dans lequel tu vis, mais dans le mien, y'a plein d'applications tierces qui ne sont fournies par aucune distrib.
Ceci dit, aucun des deux ne sont vraiment « terminés », l'équipe de bzr ne s'est pas tellement concentrée sur les perfs pour l'instant, mais c'est plus une question d'implémentation qu'une question de modèle, donc, on peut s'attendre à des progrès importants dans les prochaines versions.
Par exemple, bzr n'a pas de serveur dédié. Gros avantage : on peut héberger une branch ou un repository bzr sur n'importe quel serveur, du moment qu'il y a du (s)ftp pour uploader et du HTTP statique pour downloader. L'inconvénient, c'est que du coup, le protocole n'est pas bien pipeliné, on n'exploite pas bien la bande passante. Le serveur dédié est sur la todolist de bzr.
Autre différence : bzr est 100% python. L'intérêt, c'est que ça s'installe plus facilement. Sur un bzr fraichement téléchargé, ./bzr va marcher direct, rien à compiler. Ça simplifie l'installation sur les machines n'ayant pas de compilo C (souvent le cas sous Windows). Bien sûr, on perds encore en perfs, mais évidemment, il y a des gens qui se penchent sur la question, et maintenant que les fonctionalités de bzr sont à peu près stabilisées, certains développeurs font du profiling et ont commencé à voir ce que ça donne de surcharger certaines méthodes python par une réimplémentation en C, et les gains en perfs sont immédiats.
Bref, aujourd'hui, hg est largement devant bzr niveau perfs, mais je ne vois pas de raisons pour que les deux ne deviennent pas à peu près équivalents d'ici quelques mois.
C'est pas tellement ma vision des choses, non. C'est plus une question d'organisation que de nombre de personnes. Subversion est utilisé par des très gros projets (KDE par exemple).
À l'inverse, j'utilise bzr sur un projet à 2 personnes, et c'est que du bonheur aussi. Pas de serveur à installer, on travaille chacun sur notre compte, sans avoir besoin de donner de droits à l'autre (avec subversion, la méthode typique quand on a la flème d'installer un serveur, c'est de donner un accès complet aux autres en mettant leur clé ssh dans ton ~/.ssh/autorized_keys, c'est un peu moyen quand même).
Bon, on passera sur le fait que c'est bien connu, les logiciels bien développés n'ont pas de bugs ... (t'es allé faire un tour sur les bugtrackers de tes logiciels préférés pour vérifier qu'il n'y en avait pas ?).
Pour ton exemple de TeX, regardes combien d'années il a fallu pour finir de le débugger, et regardes combien de lignes de code ils font (de mémoire, 30,000 lignes pour TeX), et devines si c'est applicable à une distribution Linux entière.
> Il faut lire le contexte de ce que je dis. Pour PBPG, les softs fonctionnent de maniere identique
> or ce n'est pas le but d'un upgrade majeur c'est un saut de version.
T'est sourd ou t'es con ?
On te parle des logiciels qui tournent sur ton système, pas du systéme. Bien sur que quand tu passe de Windows NT à Windows 2003, tu t'attends à ce que ton Windows 2003 ai des trucs en plus que NT 4. Mais n'empêche que le word 97 qui tu avait installé sur ton NT4, tu veux qu'il continue de fonctionner après l'upgrade. Tu veux aussi que ton application maison qui tourne depuis des années sans soucis majeurs continue à tourner, ...
C'est de ça que parle PBPG, c'est de ça que je parle, toi, tu parles juste d'autre chose. Tu n'as pas compris la notion d'application tierce.
Subversion est clairement meilleur sur la quantité et la qualité des front-ends. En fait, Subversion part avec le gros avantage qu'il est le successeur de CVS, qui avait quasiment le monopole il y a quelques années. Du coup, il y a une communauté d'utilisateurs, et de développeurs de « produits dérivés » énorme, que n'ont pas encore des projets jeunes comme hg et bzr (aucun des deux n'est encore en version 1.0 au passage). Mais il y a fort à parier que ça va se développer rapidement ! (il y a un projet Summer Of Code pour une GUI à bzr, et déjà des bouts d'interface graphique à gauche à droite)
Perso, je trouve qu'une GUI peut être pratique, mais qu'on apprend mieux avec la ligne de commande.
Sur la gestion des branches, bzr et hg sont tous les deux _loin_ devant subversion.
Première chose, ils conservent l'historique des "merge", donc, quand tu veux récupérer les modifications de la branche X que tu n'as pas encore, tu fais "bzr|hg branch X" et c'est tout, il se démerde.
Deuxième chose, ce sont des gestionnaires de version décentralisés, ce qui veut dire que tu peux créer des branches d'un même projet sur des machines différentes. Quand tu bosses à plusieurs, chacun a sa branche, sur sa machine, et pas besoin de prise de tête avec un serveur centralisé à installer et à maintenir. Ça fait un peu peur au début, mais en fait, c'est à la fois plus flexible et plutôt plus simple comme façon de travailler.
Après, il y a le fait de pouvoir stoquer les informations sur l'historique dans un sous-répertoire du projet, qui n'est pas toujours un avantage, mais bien pratique la plupart du temps. Par exemple, avec bzr ou hg, pour commencer un projet, tu fais "bzr|hg init": une commande et c'est tout (bien sûr, quand tu veux publier tes changements, il faut en faire un peu plus pour mettre ça sur le web).
> Rien à voir avec des crashes. On parle de fonctionnalités ici. Les
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.
- CVS (vieux, compliqué, pas puissant, ...)
- tla/baz : beaucoup trop compliqués par rapport à ce qu'ils font.
Parmis les stars du moment, il y a bzr (Bazaar-NG) et hg (Mercurial), qui sont tous deux très puissants, extensibles, mais quand même faciles d'utilisation (d'ailleurs, en passant : les équipes des deux sont en train de se rapprocher, il y a peu de chance que ça aboutisse à une fusion, mais il y aura sans doute des ponts entre les deux prochainement. Il y a déjà un plugin expérimental pour accéder à une archive hg depuis bzr).
Dans le genre simple et puissant, il y a Darcs. Le gros point noir de Darcs est qu'il ne passe pas très bien à l'échelle, donc il n'est pas tellement question de l'utiliser sur des très gros projets, et ça a peu de chance de changer.
# GNU Génération ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une association swisslinux.org. Évalué à 4.
C'est eux qui avaient lancé GNUWin, qui était une des première distribs de logiciel libres pour Windows.
[^] # Re: c'est pas libre.
Posté par Matthieu Moy (site web personnel) . En réponse au journal Google Earth pour Linux. Évalué à 2.
Allez comprendre ...
[^] # Re: warf
Posté par Matthieu Moy (site web personnel) . En réponse au journal Que penser de ça ? Stallman combien de division ?. Évalué à 0.
[^] # Re: Troll peut-être, mais en natif
Posté par Matthieu Moy (site web personnel) . En réponse au journal Google Earth pour Linux. Évalué à 2.
Si je te donne un programme Java écrit sous Windows, ça veut dire quoi en faire un portage natif sous Linux ? Faut obligatoirement que ça soit un ELF ?
[^] # Re: Euh
Posté par Matthieu Moy (site web personnel) . En réponse au journal Demain, la mort du BIO ?. Évalué à 3.
> dans le contrat, avec formation des équipes sur place...
Mouais, faut mal connaitre les normes de sécurité et usages en Inde pour croire que ça se serait passé sans danger pour la santé des ouvriers, tout ça ...
[^] # Re: intérêt
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un regard sur KOffice 2.0. Évalué à 2.
Ceci dit, à l'époque, ça marchait tellement mal que j'avais pris l'habitude de copier -> collage spécial -> coller et temps qu'image parce que sinon, tu pouvais être sur qu'il te foirait la mise en page à la prochaine modif. Je ne sais pas si ça a progressé depuis, il paraît que oui.
[^] # Re: Compatibilité OO
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Google de plus en plus proche du libre (?). Évalué à 6.
Bug #1: Microsoft has a majority market share
https://launchpad.net/distros/ubuntu/+bug/1
Mozilla cherche à forger des alliances avec GNOME et d'autres projets open source pour combattre Longhorn
http://mozillazine-fr.org/archive.phtml?article=4584
...
Ce qui fait qu'il y a quand même une part d'ironie dans la fameuse citation.
Mais oui, en effet, heureusement que ce n'est pas le seul et unique but derrière tout ça !!
[^] # Re: Google Spreadsheet est-il libre ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Google de plus en plus proche du libre (?). Évalué à 4.
http://google.com/trends?q=linuxfr
(ou j'apprends que la recherche sur le mot linuxfr est particulièrement populaire à Bezon et Toulouse par exemple)
on n'imagine même pas ce qu'ils peuvent avoir en interne, ou les données qu'ils peuvent vendre à d'autres boites.
[^] # Re: Compatibilité OO
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Google de plus en plus proche du libre (?). Évalué à 4.
Personne a compris la blague ou quoi ? Le dessin attribue à un dirigeant de Google une fameuse citation de Linus Torvalds, et il faut bien avouer que la citation va aussi bien à l'un qu'à l'autre !
« Plus proche du libre » => même objectif => peter la gueule à MS (mais faut pas le dire).
[^] # Re: Je suis toujours là !
Posté par Matthieu Moy (site web personnel) . En réponse au journal H+18. Évalué à 1.
[^] # Re: club de copains
Posté par Matthieu Moy (site web personnel) . En réponse au journal La parnanoia IE, c'est mal. Évalué à 4.
Il peut le faire, si.
[^] # Re: ortho :/
Posté par Matthieu Moy (site web personnel) . En réponse au journal LiveCD "over the network" :). Évalué à 3.
$ du -sh ~/.thumbnails/
58M /home/moy/.thumbnails/
J'me demande bien ce qu'il peut y avoir comme fichiers de configuration là dedans ;-).
[^] # Re: Ubuntu une alternative à Mandriva ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Test d'Ubuntu 6.06 LTS. Évalué à 10.
Maintenant, en effet, pour un « test », il aurait fallu tester ça sur au moins une dizaine de machines différentes, le faire utiliser par plusieurs personnes avec des habitudes différentes, ... si ça t'intéresse d'en faire un, ne te gènes pas.
[^] # Re: Non Respect
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 3.
Bah, l'entreprise de Largo Winch aussi, elle est sur un paradis fiscal, pourtant, c'est un gentil ^_^.
[^] # Re: ulteo
Posté par Matthieu Moy (site web personnel) . En réponse au journal LiveCD "over the network" :). Évalué à 3.
Comme tout projet qui se respecte, la date de sortie, c'est invariablement « dans un mois », avec mise à jour de la page pour changer la date régulièrement. C'était « mai 2006 », c'est passé « entre mai et juillet 2006 », et je ne serais pas surpris qu'il n'y ai rien avant aout ;-).
# ulteo
Posté par Matthieu Moy (site web personnel) . En réponse au journal LiveCD "over the network" :). Évalué à 2.
On verra en Mai 2006, quand la première béta sera sortie ;-).
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 3.
Genre, une entreprise X développe un truc Y en interne, quand elle fait une upgrade de sa Debian, elle récupère la version suivante de Y directement dans la distrib ?
Ça m'a l'air cool le monde dans lequel tu vis, mais dans le mien, y'a plein d'applications tierces qui ne sont fournies par aucune distrib.
[^] # Re: Mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 2.
Ceci dit, aucun des deux ne sont vraiment « terminés », l'équipe de bzr ne s'est pas tellement concentrée sur les perfs pour l'instant, mais c'est plus une question d'implémentation qu'une question de modèle, donc, on peut s'attendre à des progrès importants dans les prochaines versions.
Par exemple, bzr n'a pas de serveur dédié. Gros avantage : on peut héberger une branch ou un repository bzr sur n'importe quel serveur, du moment qu'il y a du (s)ftp pour uploader et du HTTP statique pour downloader. L'inconvénient, c'est que du coup, le protocole n'est pas bien pipeliné, on n'exploite pas bien la bande passante. Le serveur dédié est sur la todolist de bzr.
Autre différence : bzr est 100% python. L'intérêt, c'est que ça s'installe plus facilement. Sur un bzr fraichement téléchargé, ./bzr va marcher direct, rien à compiler. Ça simplifie l'installation sur les machines n'ayant pas de compilo C (souvent le cas sous Windows). Bien sûr, on perds encore en perfs, mais évidemment, il y a des gens qui se penchent sur la question, et maintenant que les fonctionalités de bzr sont à peu près stabilisées, certains développeurs font du profiling et ont commencé à voir ce que ça donne de surcharger certaines méthodes python par une réimplémentation en C, et les gains en perfs sont immédiats.
Bref, aujourd'hui, hg est largement devant bzr niveau perfs, mais je ne vois pas de raisons pour que les deux ne deviennent pas à peu près équivalents d'ici quelques mois.
[^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 2.
À l'inverse, j'utilise bzr sur un projet à 2 personnes, et c'est que du bonheur aussi. Pas de serveur à installer, on travaille chacun sur notre compte, sans avoir besoin de donner de droits à l'autre (avec subversion, la méthode typique quand on a la flème d'installer un serveur, c'est de donner un accès complet aux autres en mettant leur clé ssh dans ton ~/.ssh/autorized_keys, c'est un peu moyen quand même).
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 4.
Pour ton exemple de TeX, regardes combien d'années il a fallu pour finir de le débugger, et regardes combien de lignes de code ils font (de mémoire, 30,000 lignes pour TeX), et devines si c'est applicable à une distribution Linux entière.
> Il faut lire le contexte de ce que je dis. Pour PBPG, les softs fonctionnent de maniere identique
> or ce n'est pas le but d'un upgrade majeur c'est un saut de version.
T'est sourd ou t'es con ?
On te parle des logiciels qui tournent sur ton système, pas du systéme. Bien sur que quand tu passe de Windows NT à Windows 2003, tu t'attends à ce que ton Windows 2003 ai des trucs en plus que NT 4. Mais n'empêche que le word 97 qui tu avait installé sur ton NT4, tu veux qu'il continue de fonctionner après l'upgrade. Tu veux aussi que ton application maison qui tourne depuis des années sans soucis majeurs continue à tourner, ...
C'est de ça que parle PBPG, c'est de ça que je parle, toi, tu parles juste d'autre chose. Tu n'as pas compris la notion d'application tierce.
[^] # Re: Conseils
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 5.
Subversion est clairement meilleur sur la quantité et la qualité des front-ends. En fait, Subversion part avec le gros avantage qu'il est le successeur de CVS, qui avait quasiment le monopole il y a quelques années. Du coup, il y a une communauté d'utilisateurs, et de développeurs de « produits dérivés » énorme, que n'ont pas encore des projets jeunes comme hg et bzr (aucun des deux n'est encore en version 1.0 au passage). Mais il y a fort à parier que ça va se développer rapidement ! (il y a un projet Summer Of Code pour une GUI à bzr, et déjà des bouts d'interface graphique à gauche à droite)
Perso, je trouve qu'une GUI peut être pratique, mais qu'on apprend mieux avec la ligne de commande.
[^] # Re: Conseils
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 3.
Première chose, ils conservent l'historique des "merge", donc, quand tu veux récupérer les modifications de la branche X que tu n'as pas encore, tu fais "bzr|hg branch X" et c'est tout, il se démerde.
Deuxième chose, ce sont des gestionnaires de version décentralisés, ce qui veut dire que tu peux créer des branches d'un même projet sur des machines différentes. Quand tu bosses à plusieurs, chacun a sa branche, sur sa machine, et pas besoin de prise de tête avec un serveur centralisé à installer et à maintenir. Ça fait un peu peur au début, mais en fait, c'est à la fois plus flexible et plutôt plus simple comme façon de travailler.
Après, il y a le fait de pouvoir stoquer les informations sur l'historique dans un sous-répertoire du projet, qui n'est pas toujours un avantage, mais bien pratique la plupart du temps. Par exemple, avec bzr ou hg, pour commencer un projet, tu fais "bzr|hg init": une commande et c'est tout (bien sûr, quand tu veux publier tes changements, il faut en faire un peu plus pour mettre ça sur le web).
[^] # Re: Ubuntu sur un serveur
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 0.
Si un mec exploite une faille de sécurité dans mon firefox et que j'ai fait un sudo moins de 15 minutes avant, paf, il est root sur ma machine.
Mais bon, des failles dans firefox, y'en a jamais, hein ;-).
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 2.
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.
# Conseils
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 3.
- CVS (vieux, compliqué, pas puissant, ...)
- tla/baz : beaucoup trop compliqués par rapport à ce qu'ils font.
Parmis les stars du moment, il y a bzr (Bazaar-NG) et hg (Mercurial), qui sont tous deux très puissants, extensibles, mais quand même faciles d'utilisation (d'ailleurs, en passant : les équipes des deux sont en train de se rapprocher, il y a peu de chance que ça aboutisse à une fusion, mais il y aura sans doute des ponts entre les deux prochainement. Il y a déjà un plugin expérimental pour accéder à une archive hg depuis bzr).
Dans le genre simple et puissant, il y a Darcs. Le gros point noir de Darcs est qu'il ne passe pas très bien à l'échelle, donc il n'est pas tellement question de l'utiliser sur des très gros projets, et ça a peu de chance de changer.