Guillaume Knispel a écrit 2474 commentaires

Hm l'IDE utilisé en tant qu'outil ultime à tout faire, et qui fait tout.

Extrêmement performant pour tout ce qui est prévu.
Extrêmement lourd et contre productif pour tout ce qui de rentre pas dans le moule de l'IDE et du langage, et... c'est justement ce qu'explique ce journal!

Forcement quand on est expert dans un domaine, ça fait mal de voir qu'il y a un manière de le faire 25x plus vite en utilisant d'autres outils. Alors on se console comme on peut en se disant que sur ce point particulier on perd, mais que dans la majorité des autres cas on gagne.

A voir l'histoire des projets informatiques remplis de succès rapides dus aux gens qui utilisent un outil en rupture et bien adapté à un problème précis donné, j'ai énormément de mal à croire en l'outil ultime qui fait tout d'une manière en moyenne optimale. Et j'ai encore plus de mal à croire que cet outil est à tout instant le truc à la mode du moment (ou l'avant dernier truc à la mode).

Un outil n'est jamais adapté simultanément à tout. Les outils qui tentent de le devenir sont plus typiquement médiocre en tout que bon en tout... Il en va de même pour les compétences: si on se limite à des "experts langage XYZ" comment réagir quand les besoins fonctionnels vont changer vers un domaine encore inconnu pour eux? Le langage ne devrait être qu'un détail. Hors il est des secteurs où il est devenu un critère principal de détermination de compétence. C'est aussi ça que je critique.

Vu sous cet angle enfermer tout un projet dans une IDE et dans un langage, et ce surtout quand il est de grande envergure, me laisse sans voix.

Un projet de grande envergure ne peut pas se permettre de fixer des choix technologiques arbitraires restreints à ce point pour cause d'IDE manquant d'ouverture sur le monde surtout quand on considère la volatilité du marché informatique. On est dans un contexte ou quelque chose qui ne s'integre bien qu'avec les trucs du même type va forcement poser des problème à un point donné.

Java est peut être très adapté pour certains problèmes mais croire qu'il peut tout faire tout seul ou à grand coup d'outils magiques est une erreur monumentale. C'est tout aussi grave que de dire qu'on veut déployer une archi énorme entière sous Linux juste pcq'on aime Linux, sans même prendre la peine d'étudier les besoins multiples et divers de l'application considérée.

Bref tout ça pour dire d'un langage n'est qu'un outil et qu'une IDE aussi, et que s'enfermer dans un seul outil pour un gros projet n'a pas vraiment de sens en terme de productivité. Un projet bien géré saura être souple et garder une archi cohérente tout en s'autorisant d'utiliser les outils potentiellement différents les mieux adaptés aux fonctions à intégrer sous réserve de couplage suffisamment souple pour permettre ça.
Et sur un gros projet, un couplage technique tellement rigide qu'il ne permettrait ce genre de souplesse nul part est typiquement le signe d'une mauvaise archi et/ou de mauvaise directions techniques prises sans que le besoin ait été correctement qualifié.

Euh le contrôle de version ça existe... (depuis loooooooongtemps même)

Quand à prendre comme argument la puissance de la machine quand on parle de ce servir d'un éditeur (ou d'un IDE dont la fonction principale est tout de même ... éditeur)... ça illustre tout à fait la qualité déplorable de certains logiciels en terme de consommation idiote de ressources :P

Enfin bon quand je vois OOO, Firefox, Gnome et Eclipse, effectivement je ne m'étonne plus de rien quand à la tolérance des utilisateurs pour les logiciels bloatwares qui rament. (l'ironie est que je poste ce commentaire depuis Firefox :p )

Je suppose que tu fais allusion à mon commentaire.
gn?

<snip/>

C'est quoi ce trip sur l'origine d'Ubuntu ? Le milliardaire en question il aurait mieux fait de garder ses tunes bien au chaud rien que pour lui au lieu de chercher à diffuser les logiciels libres avec ? Et il fausse tellement les règles du jeux qu'il faudrait filer des tunes comme ça à Canonical, pour le fun, alors qu'ils n'en réclament pas ? Enfin pourquoi plaindre Mandriva d'un coté sans se réjouir pour Linagora ? Ca n'a guère de sens. (et en plus de tout ça j'ai beaucoup de mal à voir ce que M.S. vient foutre dans cet histoire et chuis un peu attristé que ce genre de niaiserie s'étende au delà du cercle des journaleux)

Enfin à se rythme là certain vont réclamer le subventionnement des tous les développeurs upstream ou packageur français par l'état. Ca va être rigolo à voir :)

En plus dans ton commentaire du semble sous-entendre que Mandriva apporte plus à la fois au LL et à la France que Linagora. Ca reste à démontrer.

Pour finir j'ai du mal à suivre sur les pistes du soutient économique des pays étrangers dans le contexte d'Ubuntu à l'Assemblée... il me semble pas que ça soit le sujet principal malgré les fumisteries initiales du journaleux du point.

Cet attrait pour les "entreprises" d'un langage comme le Java aussi peu expressif et sommum de la POO poussé à l'extrême même (et surtout !) dans les cas où c'est le plus anti-productif m'étonnera toujours.

Quoi qu'il en soit, dans un tel contexte, mieux vaut effectivement compiler du code à partir de quelque chose ayant une expressivité correcte plutôt que de le pisser bêtement. Pourquoi perdre son temps à implémenter machinalement des spécifications au lieu de rendre les spécifications exécutables ? :) (quitte à le faire en douce si jamais le chef de projet voit ça comme une menace envers son emploi :P )

Ceci étant "l'éditeur de texte t'es imposé" me laisse sans voix. Ils fouettent les employés bruyants aussi ?

moi aussi j'en veux !

1/ C'est des pilotes binaires donc c'est nul

Oui.
Si tu t'en branle toi personnellement tu peux tout a fait l'installer, tu te fera pas poursuivre pour ça par les mechants vilains integristes.
Mais à la seconde ou tu pleurnicheras parce que ton systeme est instable ou parce que tu ne peux pas changer de noyau, ou parce que tu ne peux pas utiliser un autre OS à cause de l'absence de specs, evite de le faire trop près de nos oreilles.

2/ Faut interdire les pilotes binaires

Ben pas besoin, ils le sont déjà.

3/ Faut obliger les entreprises à donner leurs spécifications

Au nom de quoi ?
Il faut leur demander très fort et féliciter celles qui le font, c'est tout.
Et bien sûr ne pas acheter le matos de celles qui ne le font pas vu qu'il nous est inutilisable.


Quand à ta comparaison crétine avec le communisme qui fini de convaincre tout le monde de ton absurdité, doublé d'autre crétineries encore plus fortes à base de pétrole et d'eau, c'est un appel caractérisé à que toi en tant que troll soit combattu par d'autre trolls, et je ne tomberais pas dans ce piège.

PERSONNE ne te reprochera d'utiliser Windows.
Le libre n'est PAS gratuit! Son cout pour toi le plus élevé, renoncer au proprio dans le noyau, t'est trop élevé comparativement à cette possibilité que tu as dans un autre OS?

Linux te coute trop cher (et risque de te faire devenir un communiste qui mange les enfants, et de t'assoiffer)
Linux ne convient pas à tes besoins.
Change d'OS.

Mon ouverture d'esprit consitera à te laisser faire ce que tu veux, en silence, sans faire chier le monde, surtout quand les gens que tu saoule sont des développeurs qui veulent :

1) se conformer à la loi
2) partager du code libre
3) ne pas être géné par les "utilisateurs" qui ralent à longueur de temps parceque "Linux ne fonctionne pas sur leur matos" (ils ont cas essayer de faire tourner windows sur du Mips pour se rendre compte de l'absurdité de ce reproche)
4) ne pas être géné par les "utilisateurs" qui ralent à longueur de temps parceque leur config plante ou que le comportement du scheduler devient totalement pourri sur leur config alors qu'ils ont des merdes proprio qui tourne dans le noyau.

Pour info j'utilise Linux depuis mon premier 486. J'ai jamais eu de driver de carte son de 8Mo. Ma musique n'a jamais saccadé (à partir d'un pentium) à cause de condition de charge, d'acces au HD, d'acces à la carte graphique. Et j'ai jamais utilisé de pilote proprio pour quoique ce soit.

Quand je vois à quoi en sont réduits les gens qui utilisent ce genre de merde sous Linux avec leur plantage, incompatibilité, etc (je dis pas que les driver proprio sont des merdes partout, juste que sous Linux, du fait de l'environnement, ils ont de très forte chance d'en etre une grosse et bien puante, parce que quand on fait du driver proprio sous Linux c'est entre autre qu'on veut pas se conformer aux règles de qualité et au process de développement en vigueur pour les pilotes libres), je leur laisse ce plaisir.
Et c'est pas en jetant un oeil 30s au bidule de Creative Lab que je changerais d'avis. Ce truc est bourré de Windowseries. Si ca marche sous Linux, ce sera uniquement par miracle et avec d'énormes bouts de scotch, quand la Lune est aligné avec Mars.

Jusqu'au prochain Linux, ou ca ne marchera plus du tout.

leur licence est (en plus d'être absurde en parlant de fichiers microsoft et autres truc débiles) totalement incompatible avec la GPLv2 et il n'ont en aucun cas le droit de distribuer ce driver. De toute manière personne ne veut de pilote proprio de 8MB pour une carte son...

notez pour vos calcul de rentabilité de conso électrique que si vous avez un chauffage tout électrique chez vous, vous devez quasiment soustraire la conso de tous vos équipements quand il est allumé.

Il dit au monde "Faites (presque) ce que vous voulez avec ce code" avec sa licence.

Il y a une contradiction evidente à venir pleurnicher par derrière en disant qu'il n'est pas souhaitable de faire XYZ, XYZ étant totalement autorisé. Il n'y a pas de légitimité à se plaindre d'une telle manière alors qu'il met son code volontairement sous cette licence. La seule action efficace est de changer de licence.

On ne convaint personne de plus que ceux qui ne le sont déjà en déclarant unilatéralement que la seule vrai liberté est celle qui consiste à autoriser tout le monde à faire presque n'importe quoi et d'en suite pleurnicher pour convaincre que ca serait en fait finallement bien que tout le monde soit d'accord pour faire toujours du code tel que tout le monde puisse le réutiliser n'importe comment. Il y a la une contradiction primordiale, une boucle de rétroaction fondamentalement instable.

Euh, pour faire du calcul intensif ?
N'importe qui compétant en ASM éclate n'importe quel compilo sur _presque_ n'importe quel algo non trivial :)
Ca risque pas de changer avant quelques décénies, du moins sur x86.

Passer du C à l'ASM implique pour la manière de penser du développeur bien plus que ce que peut fournir des optimisations automatiques. On se met par exemple à faire le même calcul parrallélisé en même temps sur plusieurs unitées différentes (MMX + x86 scalaire par exemple). On entrelace les passes voir des algos totalement différents bossant sur la meme zone de données pour augmenter le débit d'exécution des instructions. On remanie légèrement les calculs pour profiter de caractéristiques avantageuses de certaines instructions sur d'autres. Un compilateur ne peut embarquer, sauf à devenir monstrueux, des algorithmes pour faire du calcul formel vraiment avancé necessaire à l'automatisation de ce genre de choses.

Au mieux de l'optimisation automatique concernant le calcul va parrallélisé en vectoriel un code dans lequel le parrelisme est déjà clairement exposé au compilateur. Donc pour avoir autre chose que +10% de perf le developpeur est tout de même obligé hors cas triviaux de fournir un travail spécifique.

Oui, c'est connu, la terre entiere est remplis de développeurs compétents et en nombre suffisant pour forker, maintenir et faire évoluer GCC, en plus de coder en OS complet comme un petit projet quand ils s'ennuient ;))

Les développeurs BSD acceptent de voir leur travail repris et enrobés dans un programme doté d'une autre licence (y compris propriétaire)

Ils n'ont pas de légitimité pour critiquer le fait que les développeurs GPL n'acceptent pas de voir leur contribution reprise dans un programme doté d'une licence propriétaire. Les développeurs GPL, en rajoutant des fonctionnalités sous cette licence, n'otent pas aux développeurs originaux leur parenté et leurs droits sur les fonctionnalités qu'ils ont eux-même implémentés.

Et si on veut aller super loin on peut considérer qu'il a publié un patch donc un texte dans lequel la licence est belle et bien présente, mais dont chaque ligne est simplement préfixé du caractère '-', ce qui n'étant pas expressement interdit par la licence ne constitue pas en soit une violation ;)

Tu cites un paragraphe d'example du préambule de la GPLv2, paragraphe qui ne fait pas partie des terms and conditions.

La GPLv2 n'impose pas de conserver toutes les licences d'un soft multi licensié lorsqu'on le redistribue.

MSVC et ICC pondent tous les deux du code plus performant.

gn ? concernant MSVC j'en ai aucune idée réelement précise aujourd'hui, je sais juste qu'il y a assez longtemps il produisait du code vraiment abject et que recemment lors d'un reverse j'ai vu des trucs completement débile dans du code produit par MSVC (ptet qu'en moyenne yen a peu et c'est pas si mal que ca, mais j'ai un doute)

Par contre à mon avis aujourd'hui GCC soutient tres largement la comparaison face à ICC. Un pote qui fait du calcul biomedical m'a même annoncé ya pas plus longtemps que 2 semaines que sur ses codes GCC produisait des objets plus performants,

Programme en QT tu comprendra :p

Linus met des conditions minimales assez claires et très contraignantes en ce qui concerne les modules prioprio:

- un module prorio ne peut (logiquement!) pas utiliser d'API taggué comme étant destiné uniquement à du code sous licence GPLv2 et compatible (EXPORT_SYMBOL_GPL si mes souvenirs sont bons)

- un module proprio à l'interdiction absolue d'inclure du code de Linux sous GPL, et cela inclus tout ce qui est en provenance des headers dont les fonctions inlines et les macros. Étant donné qu'il y a des tonnes de trucs essentiels à un OS là dedans comme le locking et que tout module non trivial en aura besoin, la seule solution est de réimplémenter et c'est un travail... grand :p (voir gigantesque pour le faire correctement, sans bug, et en prenant en compte les errata des processeurs ciblé, et si possible sans lire l'implémentation originale histoire de réussir à imaginer quelque chose d'original; le tout bien sûr en restant compatible avec l'implémentation de Linux... ça relève de l'exploit et si jamais ça réussi ca va à coup sûr défoncer horriblement les performances et la réactivité du système...

La distribution d'un système complet mettant d'origine en oeuvre un module proprio dans Linux est aussi un énorme casse tête. Si l'utilisateur ne fait pas lui même un travail volontariste d'intégration j'ai du mal à voir comment ça pourrait être légalement possible.

prend n'importe qui ayant utilisé Vista et XP, il te confirmera que Vista c'est de la merde en boite a peu pres du niveau de win ME (faut qu'il connaisse win me aussi ;)

"parler" le PS2 est trivial et meme si ta CM n'a plus de connecteur, il a toujours un bout de circuit non branché dans un des puces de ta CM qui est capable de "parler" le PS2.

Pas besoins de "pile" logicielle. Il suffit d'envoyer des octets sur un port et de faire 2/3 configs sur un autre.

"parler" l'usb est beaucoup, beaucoup plus compliqué.
Maintenant qu'il est si répandu, c'est pas trop un problème. Mais devans la simplicité du PS2 ca ne me choque pas du tout d'en voir persister.

C'est effectivement trés sympas de leur part, mais il manque certaines choses :
- Les patchs exacts des programmes utilisés

hm ? une identification des fichiers modifiés suffit.

- La licence/auteurs de ces patchs (notamment celle du kernel)

Ben si le soft est sous GPL, je laisse deviner la licence du patch s'il n'y a pas de précision supplémentaire. C'est clair que si les dates de modif, les modifs et une identification de lorigine de la modif avec une granularité du fichier n'est pas disponible c'est une violation et ca laisse donc un peu à désirer :p. Mais si c'est la seule, ... on est à des années lumières de ce que certaines boites font!

- La licence des Blobs de Broadcom
La c'est carrement un plus grave problème. C'est extremement "difficile" de faire des modules noyaux non GPL (certains contributeurs et pas des moindres disent que c'est tout simplement impossible) alors si y a pas de licence du tout de donnée ca risque peu d'être distribuable légalement.

> tiens c'est bizarre, à fréquence moindre et cache égale... il va plus vite quand meme...

Rien de plus normal. Si certaines parties des proc d'Intel et d'AMD se ressemble probablement un peu au niveau conceptuel, globalement ils restent très différents surtout en matière de dimensionnement et métriques internes de performances. Notamment ils n'ont pas les mêmes profondeurs de pipelines, µops, algos de réordonnancement, éventuellement macro ops, fusion des micro et macro ops, et nombre d'unités des elements du pipeline en particulier ALU (+ éventuellement cadencement différent des ALU et du reste du proc et support plus ou moins étendu du jeux d'instruction dans les differentes ALU) et latences des différentes unités, etc.. etc..

Au final comparer uniquement la fréquence et/ou la taille du cache n'apporte qu'une vague indication en moyenne, un ordre de grandeur, mais ne permettra jamais d'anticiper sur les perf relatives pour un travail donné (et encore les AMD et les Intels ont le bon gout d'avoir la même ISA, avec une ISA différentes ca serait encore plus flou une telle comparaison)

Nan faut prendre les choses dans lautre sens: si ca reste un truc de geek, on arretera de voir apparaitre de l'extase sur de telles babiolles :p (mais dans le même temps on utilisera évidemment les babiolles en question, on est pas maso non plus ;)

Compare Ubuntu et Vista (de préférence avec pleins d'appli hérités + des applis dans divers langages et de divers vendeurs pour obtenir le même niveau de service qu'une Ubuntu de base), ça te démontrera que le journal est susceptible d'avoir été écrit dans le présent :)

Quand aux logiciels de l'OS d'Apple, l'évolution me laisse penser que leur cohérence baisse elle aussi, et je commence donc à avoir l'impression que la tendance s'inverse en la matière entre Gnome/Kde/Autres-applis-non-alignés et Win/MacOS :p

La prédominance de GTK/QT sur les bureaux libres, quand dans le même temps c'est la diaspora coté langages, bibliotheques et héritages des autres OS (en réinventant la roue jusqu'aux pixels de l'écran dans certains cas) y est surement pour quelque chose -- il faut dire que quand Windows n'avait que quelques API et implémentations pour créer des fenêtres et que l'industrie ne passait pas son temps à skinner avec des truc affreux tous les logiciels qu'elle produisait, ça limitait les risques de patchwork graphique susceptible de bruler des rétines quand au résultat obtenu à l'écran... (et à l'époque coté Unix les divers TCL/TK / Motif / vieux Gtk / vieux Qt avec des thèmes assez brut détonnaient les uns avec les autres...)

depuis quand reproduire == distribuer ????

Arrête de mélanger les mots et les concepts qu'il y a derrière.

D'autre part ils ne publient quasiment rien (sauf contrat spécifique par exemple pour les gouvernement où ils leur fournissent plein de chose dont le code source de Windows en read only ou en write for debugging only, mais c'est pas public) et certaines license "opensource selon MS" ne sont pas du tout open source selon le sens communément admis.

Bref c'est trop tôt pour les traiter d'Evil sur le sujet, vu qu'il n'ont pas vraiment encore agi, mais s'agissant de MS je vois mal pourquoi les partisants du libre ne pourraient pas avoir un petit à priori non plus...

Pourquoi perdre du temps humain à redevelopper toutes les applications existant en mode web qui n'est absolument pas concu pour ce genre d'usage interactif alors qu'on peut utiliser VLC ? ;))