Boa Treize a écrit 3449 commentaires

C'est quoi le prix ? J'en trouve pas sur le site d'ACME, et je ne trouve pas la FOX sur le site de Lextronic.

Alors devoir acheter une box 200 neurones et devoir la bidouiller derriere, c'est quoi l'interet?

Euh, je sais pas moi, faire toutes les chose que tu ne peux pas faire avec ton Netgear ? Par exemple, mettre un serveur DNS, mettre un serveur web, mettre un serveur SMTP, des p'tits trucs sympa qu'on laisse tourner en permanence sans pour autant se ruiner en électricité et en boules quiès.

J'ai acheté un lecteur multicartes chez Auchan pour 15 ¤. Il est pas beau, il est trop léger, le pastique est fragile, le cordon USB est minuscule, mais en dehors de ça, il marche super bien sous Linux, et vu qu'en gros il ne s'agit que de quelques connecteurs soudés sur une seule carte électronique, c'est pas près de tomber en panne.

Par ailleurs, j'ai épuré Slackware Linux pour ne conserver que l'indispensable, et j'ai obtenu ainsi un OS Linux utilsable (boot, support réseau, de quoi exécuter tous les programmes sans dépendance spéciale, plus serveur FTP, telnet, peut-être même SSH), le tout prenant... 20 Mo de disque. Vu que les cartes 128 Mo se trouvent à moins de 25 euros maintenant, et les 256 Mo probablement à 30 euros, tu ne devrais pas avoir de problèmes.

Donc :

* oublie ton imprimante, achète-toi un adaptateur USB pô cher
* n'importe quelle carte devrait suffire, plus c'est gros, moins tu te prendras la tête

C'est un très bref résumé. L'entrevue dans l'édition anglaise couvre quatre pages, et parle essentiellement de l'excellent approche qu'à la DGI du « passage au libre », et accessoirement à titre d'exemple, de son passage à OpenOffice.org.

C'est un peu dommage d'ailleurs de voir à quel point tout le monde se focalise sur l'utilisation d'OpenOffice.org à la DGI, car il ne s'agit que d'un seul logiciel, alors que la DGI est déjà « passée » à plein d'autres logiciels open-source (près de 150 !), notamment côté serveur : Linux sur 4000 serveurs, JBoss, Eclipse, CVS, trois tonnes de libs, etc., avec tous les contrats de support qui vont bien. Tout ceci génère un gros chiffre d'affaire pour les SSII et les SSLL qui décrochent ces marchés, et ne peut faire que du bien au Libre, tant d'un point de vue financier que d'un point de vue crédibilité.

Je trouve ça faible aussi. Peut-être ne s'agit-il que de la valeur d'un contrat de support passé pour l'occasion ?

Peut-être le coût global n'est-il pas calculé ou communiqué, peut-être le reste des dépenses est interne à la DGI et pas considéré comme une dépense dans le cadre d'un marché ?

Ceci dit, dans cette optique, les chiffre des 30 Mo ¤ de MsOffice ne tient peut-être pas compte non plus de ces dépenses internes et est purement le prix des licences, auquel cas la comparaison est valable, même si on peut regretter que les TCO ne soient pas comparés.

L'article de ZDNet UK (lien dans le journal) est très intéressant et assez détaillé à ce propos. La migration vers OpenOffice n'est qu'une information parmis plein d'autres données lors de cet entretien.

La DGI a un tel investissement dans l'open-source (probablement plus de cent milions d'euros investis dans des projets à base de technologie open-source ces quelques dernières années, et bien plus dans les années à venir) qu'il n'y a pratiquement aucune chance qu'il s'agisse d'un simple effet d'annonce en vue d'obtenir une réduction.

C'est darcs qui pousse le plus loin la logique des VCS décentralisés : toute copie de travail est un dépôt de plein droit.

C'est également le cas pour git et mercurial, qui ont repris cette excellente idée. Par ailleurs, comme Darcs, ils sont très légers à installer et à mettre en place, une autre évolution positive.

Pendant très longtemps, l'unique logiciel sérieux de gestion de versions était CVS.

... dans le monde open-source. L'article ne le dit pas tellement c'est évident, mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à longtemps fait pâle figure. Bien sûr, il faut payer et supporter toutes les irritations d'un monde clos.

Impossible de naviguer sur le net sans en entendre parler
(...)

Euh, si si, c'est possible.

Sauf qu'il y a un tel paquet de pognon en jeu, tant d'investissement qui ont été faits, une telle pénétration dans des systèmes critiques, que Java ne peut pas disparaître comme ça.

Sun ne dira jamais « c'est fini », ou s'ils le font, c'est un soir où il seront bourrés, et après un coup de fil du reste des poids lourds de l'industrie, le lendemain ils diront « ha ha j'ai rien dit, efface ». Une telle technologie sera revendue vingt fois avant d'être finie, et les développeurs auront amplement le temps de migrer.

Je préfère et j'ai nettement plus confiance en une technologie soutenue par un grand nombre d'industriels et standardisée de facto qu'en une technologie partiellement standardisée mais dont l'unique vendeur peut du jour au lendemain demander des royalties « raisonnables », genre quelques dollars par utilisateur, ou une centaine de dollars par développeur. .Net n'est royaltee-free que parce que ça arrange Microsoft pour l'instant.

[Il dit] que d'un autre côté les outils adaptés ca sert à rien.

Non, je n'ai pas dit ça.

Qu'est-ce qui fait que d'autres industries ne livrent peu ou pas d'erreur, alors que tous les grands produits et projets informatique (ou presque) s'abîment dans un océan de problèmes ? Le pognon.

On le sait bien, tant qu'on peut rogner sur le budget, on rogne. Le problème, dans l'aviation, le génie civil, les médicaments, la mécanique, etc., c'est que quand on rogne, on tue, alors on dépense le pognon qu'il faut pour ne pas tuer. Et en général, ça signifie qu'on se débarasse au passage de tous les problèmes sérieux. (Et ces industries ne sont d'ailleurs pas parfaites, on a des exemples de rognages excessifs qui ont tué).

En informatique, quand on rogne, on plante, et en général, y'a pas mort d'homme. (Et bizarrement dans les cas où il peut y avoir mort d'homme, on sort le pognon et on a beaucoup moins de bugs.) Bon, on perd plein d'argent, mais les grands chefs sont rarement a quelques millions près, c'est le client, le contribuable ou l'employé qui paye, donc on s'en fout un peu.

Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs. Un langage qui induit moins de bugs, ça ne sert qu'à se lancer dans des projets plus grands, plus gros, plus chers qu'avant. La proportion de bugs a baissé, mais le projet est plus gros : il y a donc autant de bugs.

Non franchement, une seule solution pour faire baisser les bugs : cracher les thunes, prendre le temps qu'il faut. La NASA l'a fait pour ses navettes, par exemple, et leur programme de contrôle est bien la seule chose qui n'ait pas été critiquée au lendemain de l'explosion de Challenger ; les experts ont même souligné son exemplarité.

Mais attention, si on allonge le blé et les délais, on ralentit aussi l'évolution de l'informatique. Est-ce que finalement les bugs n'ont pas été un prix à payer pour vivre avec joie un tel foisonnement technologique ?

Le logiciel libre aurait-il pu naître sans les bugs, dans un monde où tous les systèmes informatiques sont spécifiés dans le détail et sans erreur par les services recherche et développement marketing de grandes corporations ? La force du logiciel libre n'est-elle pas justement d'avoir une réactivité face aux bugs et aux demandes d'évolution nettement meilleure que celle des gros industriels ?

mais le seul ???

étrange phrase

Très mauvaise traduction. Il a dit « le dernier », pas « le seul », et vu le contexte, c'est à prendre au même sens qu'Internet est aujourd'hui « le dernier » interréseau, alors qu'au début des années 90, AOL, CompuServe et autres avaient leurs propres réseaux... Tout comme les réseaux de chat actuels, qui devraient être amenés à se fondre dans un grand tout.

Il a aussi réitéré son intention de s'ouvrir aux autres réseaux Jabber, mais ils ne sont que trois à travailler sur Google Talk (plus cinq gars pour la prod), il faut leur laisser un peu de temps, bande d'impatients.

Il a enfin parlé de concepts assez excitants, par exemple l'édition de documents en collaboration, où l'éditeur est le client de chat et le client de chat est l'éditeur. Des idées plein la tête, pas étonnant chez Google. :-)

On me souffle dans mon oreillette « réécriture des impôts de la France » et Debian, Oracle, JBoss, Axis, Struts, Hibernate, Log4j, Internet Explorer, Rose, Eclipse, Ant, CVS, TortoiseCVS, PuTTY, SourceForge, Owl, Bugzilla, Notes. Cherchez les intrus. :-)

C'est carrément déplaisant ça.

En effet, ça sert pas souvent, mais quand ça sert, ça sauve la mise. En plus c'est seulement 6% de l'espace disque pris par ma distribution (Slackware), c'est pas bien gênant. En plus plus plus, quand t'es coincé dans une chambre d'hôtel, t'es bien content d'avoir de la doc sous la main, et pas sur un réseau inaccessible.

Arch Linux ne semble vraiment bien marcher que pour les gens qui ont une connectivité large bande permanente. (Elle ne s'en cache pas d'ailleurs.)

Tiens, au fait, j'ai vu que Arch Linux soulignait bien fort qu'elle était optimisée i686 et donc plus rapide que plein de gens... Je rappelle que Slackware est aussi optimisée i686, mais compatible i486. Ne pas confondre -march et -mcpu dans gcc...

Intéressant. Je me suis plongé dans le site d'Arch, ça me plait. Y'a juste un truc qui m'a fait tilter à propos du packaging des programmes :

http://wiki.archlinux.org/index.php/Arch_Packaging_Standards(...)

When you use makepkg to build a package for you, it does the following automatically:
(...)
6. Removes /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info from the package

Heu ? Elle va où la doc ? Dans un package à part ? Dans /dev/null ? On bidouille à la main ?

Ce que j'ai compris, c'est que l'histoire de l'émulation, c'est pour le pilote par défaut Microsoft OpenGL, qui est utilisé pour les cartes graphiques qui n'ont pas de pilote OpenGL. Ça permet d'avoir un support OpenGL correct même si pas ultra performant sur des cartes qui de toute façon n'en avaient pas, ou des tout pourris parce que les développeurs s'étaient concentrés sur DirectX. Donc, ce pilote par défaut Microsoft là, il fera appel à DirectX, mais bon c'est pas grave, c'est mieux que rien, et de toute façon je ne pense pas qu'il y ait un gros coût à faire la conversion d'API (par rapport au temps passé par la carte à faire les calculs, ou aux autres calculs qui s'exécutent sur le CPU).

Rien ne devrait empêcher nVidia & co d'installer leur propre pilote OpenGL natif, ce qu'il font déjà et continueront probablement à faire.

Ça n'a rien à voir avec la qualité, mais avec la taille des puces. Je me suis fait avoir aussi : j'ai acheté une barette de 256 Mo avec 8 puces dessus, donc 32 Mo dans chaque puce, or mon BIOS ne supporte manifestement que 16 Mo par puce. J'ai testé sur divers vieux PC, rien à faire, il faut du BIOS / chipset récent.

Bref, comme d'hab, les prix de la RAM baissent, les prix des vieilles RAM augmentent. Faut surveiller du coin de l'oeil, et investir au bon moment. Et en ce moment, faire très attention au nombre de puces des SDRAM.

Ceci dit, 128 Mo, c'est vraiment pas beaucoup de nos jours. C'était « normal » il y a *quatre* ans. Actuellement, je pense qu'il faut 256 Mo au minimum, 512 Mo pour être normalement à l'aise, 1 Go pour être bien à l'aise, et au delà ça fait encore un peu alien.

Une autre méthode qui marche bien : « Si tu apportes ton ordinateur chez moi, alors je jetterai un coup d'oeil. » Ça élimine beaucoup de demandes, surtout parmis la famille « moins proche » et les amis d'amis. En plus, pour peu que tu aies une activité à plein temps, c'est très facile à justifier.

Alors ça, c'est un troll de compétition !

Du vrai troll à l'ancienne comme on n'en fait plus assez, des affirmations fausses mais crédibles balancées avec aplomb, des attaques ad hominem, la mention de programmes concurrents... Tout y est, tout marche, la preuve le commentaire est à +6.

Zakath, je te tire mon chapeau ! (Et regrette de ne pouvoir dépertinenter ton commentaire qu'une seule fois.)

Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.

Grossière erreur de logique.

Ceci dit, par ailleurs, git n'a jamais prétendu être pour tout le monde. Il ne prétend pas non plus être pour Linus et/ou Linux uniquement.

git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte.

C'est faux. Git stocke une version compressée des fichier (compression zlib maximum).

CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.

C'est faux. Git peut stocker les objets sous forme compactée, et dans ce cas il est assez efficace en termes de stockage et encore tout à fait performant. Par exemple, Linux 2.6.11 avec son historique prend 191 Mo sous forme classique (chaque fichier étant compressé) et 62 Mo sous forme compactée. À comparer avec les 250 Mo des sources décompressées.

- versionnement des fichiers

Que veux-tu dire précisément ? Bien sûr que Git permet de retrouver les anciennes versions d'un fichier, même si techniquement ce n'est pas immédiat. Je ne sais pas si une commande existe déjà, mais conceptuellement je vois bien comment le faire : il faut remonter la hiérarchie des commits (donnée par git-rev-list), voir dans chaque arbre associé au commit si le fichier de même nom a la même signature SHA1. Si ce n'est pas le cas, tu as trouvé une ancienne version du fichier.

- remonter dans le temps sur les versions passees

Un petit coup de git-checkout permet de récupérer ultra-rapidement l'arborescence des fichiers telle qu'elle était à n'importe quel commit donné.

- notion de branche

Bien sûr. Git, comme tu le reconnais toi-même, c'est le royaume de la branche.

- notion de marquage (tag)

Bien sûr. En fait, n'importe quel objet peut être tagué. En général ce sont des commits qui sont tagués (pour marquer une version, typiquement), mais un arbre ou un fichier peuvent également l'être.

- commit atomiques

Je crois bien. De toute façon, vu que chacun bosse dans sa copie locale...

- renommage

Un point faible de Git, je pense. Pas facile de suivre à rebours l'évolution d'un fichier qui a changé de nom et de contenu. Trivial par contre de suivre l'évolution d'un fichier qui a changé de nom mais pas de contenu (merci SHA1).

- utilisation en mode completement decentralise facon arch

Bien sûr. C'est un des points forts de Git.

- interface conviviale

Le coeur de Git n'est pas convivial, et n'a pas à l'être. C'est de la plomberie. Pour la porcelaine, j'ai pas encore trop testé, mais gitk (explorateur de l'historique d'un projet) déchire grave, et git-web (même genre version html) déchire grave aussi. Cf. http://www.kernel.org/git/(...)

- compacite du stockage

Déjà traité, Git n'a pas à rougir.

- facilite de deploiement

Git est très simple et très léger, et ne requiert rien de bien méchant.

- portabilite

Git ne fonctionne effectivement pas (encore ?) sous Windows. Dommage. Il marche sous beaucoup d'Unix, y compris les versions récentes de Mac OS X.

- nombre d'outils et frontend associes

Ça évolue très vite. Cf. http://git.or.cz/(...)

- stabilite

Le projet n'a pas encore six mois, c'est clair qu'il bouge encore beaucoup. Mais qu'attendre d'autre au bout de seulement six mois ?

- dispoinbilite d'un frontend sous windows

Ah ben non, pas encore.

qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS

Aucun des programmes que tu cites ne répondent à tous tes critères. Donc, égalité avec Git ! :-) Par ailleurs, tu as oublié le critère de performance. Git déchire grave et vite à ce niveau, plus que ceux que tu cites je pense.

La Livebox SAGEM utilise Linux depuis juin. (Ce qui a été l'occasion d'une mise à jour particulièrement énervante, d'ailleurs.)

Ça m'étonnerait : tu as signé un contrat, point final. Tout ce que tu peux faire, c'est signer un avenant à ce contrat, ou résilier ce contrat (dans les conditions prévues par celui-ci, donc en payant un max) et en établir un autre. Mais bon, je ne suis pas avocat, hein, juste quelqu'un qui a récemment signé pour douze mois...

Bon, ça fait dix jours que j'ai été invité par un ami à m'inscrire à GMail (et donc Google Talk), et j'ai maintenant 100 invitations à distribuer. Ça va vite...

google a l'air de permettre de s'inscrire à talk.google.com avec n'importe quel email

Ce n'est pas le cas : il faut un compte GMail pour pouvoir utiliser talk.google.com. De plus, la page que tu indiques ne permet pas de créer un compte GMail, mais juste un compte Google.

Pour créer un compte GMail, ou transformer un compte Google en compte GMail, il faut soit que tu sois invité, soit que tu demandes à Google de t'envoyer un SMS de vérification (ce qui ne fonctionne qu'aux USA pour l'instant).

Il y a peut-être quelques « failles » (pages plus ou moins secretes dans des recoins) (j'ai pas tout suivi), mais les deux seuls moyens officiels sont indiqués ci-dessus.