Boa Treize a écrit 3449 commentaires

Ha ! Vous pouvez trouver mon commentaire inutile et celui du gars qui pense qu'il suffit de « cinq minutes pour tester », mais la réalité c'est que « tester », dans le cadre d'un gros site professionnel avec plein de grand public qui vient dessus, ça coûte cher -- un bon paquet de jours de salaire d'un paquet d'employés par combinaison de navigateur et d'OS testé.

Si le CA n'a pas testé des trucs alternatifs, c'est qu'ils ont considéré que ça coûte beaucoup trop cher, c'est tout.

Au mieux ce que vous auriez eu, c'est « testé avec Firefox 1.13 sous SuSE Linux v40.12 » (comme le sont le JDK de Sun, DB2 d'IBM, WebLogic de BEA, etc.)

(Et non, une grande entreprise ne peut pas se permettre de dire « vaguement testé » ou « ça devrait marcher » ou « ouais on y a fait gaffe mais rien n'est sûr » -- ça ne manque pas, les clients hargneux et teigneux prêts à faire des procès pour le préjudice moral (ou financier !) subi pour n'avoir pas réussi à se connecter avec un navigateur « mais le site disait que ça marchait avec et ça a planté ».)

Toujours autant de FUD.

Aucune source de citée pour les 7 000 dollars par mois, et de toute façon je ne vois pas en quoi faire de la pub pour son site serait « suspect » comme tu l'écris injustement.

Et puis Alexa témoigne de quoi ? J'ai parcouru les pages vers lesquelles tu pointes, et je n'y vois rien d'autre que des courbes de popularité bien connues et fort prévisibles au vu de l'historique de son site.

T'as vraiment l'air d'avoir pas digéré sa réussite.

C'est vraiment nul de se faire chier à faire une explication bidon alors qu'ils leur prendraient 5 minutes a tester...

Ah ouais ? Faut sélectionner les navigateurs à supporter, les systèmes d'exploitations à supporter (on prend quels distribs ?), les versions de tout ça, installer toutes les combinaisons de tous les navigateurs sur tous les OS, et demander à des équipes de dérouler tous les scénarios de test !

Et refaire le boulot à chaque version du soft qui sort...

Moi j'appelle pas ça un boulot de cinq minutes, et je dis pas que c'est pô cher, facile à faire, ou qu'il y a un intérêt à le faire vu la situation.

Le mieux est que les devs s'assurent que ça marche, et on ne garantit rien derrière. ;-)

A la rigueur un filtre sur la profondeur des commentaires réglable par l'utilisateur devrait suffir. Mais bon, faut une bonne âme pour le coder... pas gagné.

C'était déjà là à l'époque de daCode, ça a disparu quelques mois lors du passage à Templeet, mais c'est revenu depuis au moins... au moins.

Perso, je navigue à -1 (c'est plus facile pour moinsser les posts qui sont déjà en négatif... ;-).

Quand a la milliondollarhomepage, sa reussite est trop rapide, plutot suspecte, et plus ou moins foireuse. . .

Ah, ce gros FUD que tu nous sors. Jaloux, va.

Quand tu embauches quelqu'un, tu ne le lances pas tout de suite sur un gros projet vital, mais tu lui fais faire un galop d'essai (et une appli utilisée par la plupart des employés Google, c'est pas rien non plus).

Par ailleurs Google n'a rien à dire sur le travail que Guido fait pour Python, et de mémoire il y passera la moitié de son temps.

Enfin, malgré tout le respect que je dois à Guido, il y a de grandes chances qu'il ne soit qu'un employé "normal" chez Google, qui ne manque pas de grosses pointures.

Pour moi au temps pour moi s'écrit toujours autant pour moi.

(Et insane est actuellement beaucoup plus utilisé en langage courant que les dérivés de mad, mais je suis sûr que tu trouveras un normateur pour dire le contraire.)

Je n'ai pas dit qu'on ne devrais pas parler d'une information qui date de plus d'un jour. L'attente peut tout à fait être sage et appropriée.

Je n'ai pas dit non plus que l'approximation était mauvaise, et je suis sûr que dans la plupart des cas elle est voulue et parfois justifiée.

Je n'ai pas dit enfin que son émission était mauvaise. Par contre, non elle n'est pas "délicieuse", et "bonne", je ne sais pas et ça dépend de la sémantique, moi je dirais plutôt "normale".

(C'est marrant à quel point tu as lu mon commentaire de travers et tu es parti sur tes grands chevaux. Belle exemple de subjectivité.)

Moi quand je l'entends le matin, c'est plutôt :

* Qu'est-ce qu'il va encore nous approximer aujourd'hui ?
* Combien de jours (voire de semaines) de retard a-t-il ?

Attention, j'dis pas que c'est un mauvais journaliste hein, c'est juste qu'inévitablement, quand on connait bien un domaine, on grince des dents quand on entend des trucs grand public à son propos. Moi l'Jérôme j'l'écoute surtout pour avoir une idée de ce que les autres gens apprenent par son intermédiaire, pour connaître la version « officielle » de certains faits, et puis même parfois j'apprends un truc ou deux.

Mais bon, délicieux n'est pas l'adjectif que j'emploierais spontanément à son propos. ;)

Le fait que qu'au moins une personne travaille a plein temps sur IronPython alors que Jython n'a pratiquement pas évolué en cinq ans y est peut-être aussi pour quelque chose...

Pour Python, c'est un peu particulier, tout comme Jython d'ailleurs. Le but n'est pas de porter ses programmes mais de scripter rapidement des classes existantes. Dans les deux cas c'est super agréable.

Mais effectivement, pour les autres langages, c'est plus du pipo mercatique qu'une réelle solution : les langages sont adaptés à la sauce .Net, il faut donc par exemple porter son appli COBOL vers COBOL.Net.

Je ne crois pas que beaucoup de boîtes s'amusent à ça. Soit elles réécrivent l'existant en C#, soit elles font une surcouche C# et conservent leur coeur de métier en COBOL.

Plus précisément, le juge a le pouvoir d'agir sur l'entrée DNS wikipedia.de (qui est sous la responsabilité d'un organisme allemand) mais pas sur l'entrée wikipedia.org (qui est sous la responsabilité d'un organisme étatsunien).

Pourtant ta bibliothèque libre, à un certain point, elle va finir par s'interfacer avec les bibliothèques de base Windows, voire celles d'ultra-base, voire le noyau Windows directement, tout celà n'étant pas libre.

Mais ce n'est pas parce qu'il existe des contrats pour les licences que l'on ne peut pas avoir de licence sans contrat.

Par ailleurs, ce n'est pas un contrat, car tu n'as pas besoin (et normalement, tu ne peux pas) indiquer explicitement ton acceptation des conditions de la licence : pas de signature, pas de clic, pas de paiement, etc. La licence fonctionne implicitement, parce que sans elle tu n'as aucun droit, si tu fais exercice des droits, c'est donc que tu l'acceptes.

(Ce qui précède est à prendre avec de grosses pincettes. Y'a pas marqué « juriste » sur ma carte de visite.)

Ah mince, je peux pas monter le plussage jusqu'à 11 ! ;-)

Et surtout, ça donne l'impression que l'on a affaire à un contrat, alors que ce n'est pas le cas.

C'est donc inutile et trompeur.

Il me semble que oui, si les deux parties comprennent le langage utilisé.

Celà veut-il dire qu'il est possible de créer un logiciel GPL au dessus d'une bibliothèque / framework / systeme / n'importe quoi propriétaire ?

Pas tout à fait n'importe quoi : seulement si le composant auquel on s'interface est standardisé ou très largement utilisé, et, dans le cas où ce composant est soumis à brevet, seulement si une licence de brevet a été attribuée à tous les programmes sous licence GPL.

Le sous-entendu, à mon sens, c'est qu'on peut s'interfacer avec du propriétaire seulement si celui-ci est remplaçable (un jour) par du GPL équivalent.

Le problème de KDE qui était basé sur un Qt propriétaire (à l'époque) ne serait plus un probleme ?

Il me semble qu'avec cette nouvelle version, oui.

Ben j'ai un noir là, du boulot, mais je pense que je le préférerais en alliage de titane.

J'espère que Lenovo va conserver les spécificités IBM niveau portable, i.e. un vrai portable, qui chauffe peu et évacue bien sa chaleur sans la concentrer en un seul point, économe en énergie (trois vraies heures d'autonomie en travaillant avec Eclipse), avec un super utilitaire de gestion de la batterie, un clavier avec des touches qui font plaisir, la petite lampe/diode pour éclairer le clavier dans l'obscurité (con mais pratique), des utilitaires plus que corrects de mobilité réseau (profils, etc.)... Y'a que l'absence de touche Fenêtres qui fait mal, j'aime pas qu'on me prive de touches de combinaison. ;)

Mon pôpa s'est acheté un HP, ben il est beau et tout, mais le clavier fait nettement plus cheap (touches plastoque pas très dure qui s'enfoncent pas, on a peur pour l'écran, etc.), et niveau utilitaires c'est très léger.

Et puis on ne peut voter que dans une catégorie, je vais donc répondre au sondage ici :

[x] CPython
[x] Jython

Et clairement, je n'hésiterai pas à utiliser IronPython le jour où on me demandera de bosser sur .Net, et PyPy m'intéresse beaucoup (certainement plus que Parrot).

Comme on le découvre plus bas, en fait Ketchup ne se charge que de récupérer les sources du noyau, à toi de te démerder ensuite pour compiler et installer. Peut-être que Debian a des outils pour t'y aider, sinon c'est à la main qu'il faut le faire. Et dans ce cas, si tu ne connais pas bien et Linux (le noyau) et ta distribution, laisse tomber, tu risques de tout casser. (M'enfin, ça ne t'interdit pas d'apprendre et d'essayer, hein, mais de préférence sur un autre ordi, ou une autre partition, afin d'avoir toujours un poste de travail bien stable.)

Ketchup ne gère pas du tout l'aspect compilation, juste l'aspect récupération des sources.

C'est tout ?! J'avais pas compris ça, je croyais qu'il faisait plus de choses. Enfin bon, s'il y a un public pour ça, pourquoi pas.

C'est moi ou en haut à gauche de la liste des journaux il y a marqué Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre avis. ?

Pour l'instant je n'en fais pas une utilisation intensive, essentiellement ce que propose Ketchup, mais au lieu de faire joujou avec des versions du noyau, je fais joujou avec des versions de Git. Mais je me sens suffisamment à l'aise avec Git pour l'utiliser la prochaine fois que je voudrai tester des trucs dans le noyau.

Clairement, ce n'est pas simple à utiliser, même si pour une utilisation de base (initialiser ou télécharger, ajouter, valider, mettre à jour, visualiser), il n'y a rien de bien méchant. Le plus difficile, c'est de trouver la bonne commande et d'éviter les faux amis (git fetch contre git pull), et de se farcir quelques syntaxes, euh on va dire puissantes (celle de sélection d'un commit, que je suis loin de maîtriser (on peut parler du troisième père du frère de tel commit, il me semble)).

Ce n'est pas la documentation qui manque (plus de cent manpages, un howto imparfait, un lexique, quelques autres miettes éparses), mais il manque un bon Git Book, avec un gars qui maîtrise Git et qui sait s'expliquer clairement.

Quelqu'un s'est fait son propre guide, une sorte de « Git pour les nuls », il faut que je me replonge dedans, mais ça m'a semblé être le meilleur guide de Git à ce jour, qui explique bien les concepts et liste bien les commandes (même si les développeurs ont fait pas mal de corrections quand il l'a posté).

Le guide se trouve là :
http://www.gelato.unsw.edu.au/archives/git/0512/13748.html

Il me semble que l'on peut faire tout ça avec Git, pour un coût pas si élevé en espace disque. Bien sûr, ce n'est pas aussi user-friendly, mais on peut faire des choses en plus (genre corriger un truc trivial et envoyer un patch propre, ou faire des recherches puissantes dans l'historique du développement du noyau, ou faire du git bisect qui permet de faire la chasse aux bugs de manière super efficace).