case42 a écrit 610 commentaires

Mon avis c'est que si c'est vraiment vraiment libre, une des premières choses à sortir sera des "bindings" pour C, C++, Python, Ruby, Perl, C#... Et la réaction de Google face à ça sera aussi... significative.

A mon avis l'approche "il n'y a que 2% de femmes dans le logiciel libre, c'est une honte, il faut y remédier" est complètement à coté de la plaque car il entend faire disparaître un symptôme plutôt que le mal en lui même.

Il ne faut pas se voiler la face, quand on dit très pudiquement que le logiciel libre est basé sur la méritocratie, c'est une façon politiquement correcte de dire que la principale motivation de contribution, c'est d'abord et avant tout de montrer qu'on a la plus grosse ( intelligence, bien sur ). C'est typiquement, fondamentalement, ( je dirais presque biologiquement ) un truc de mec, et temps qu'on n'arrivera pas à changer cet état de fait, il n'y aura pas plus de femmes dans le logiciel libre.

Mettre des forums à la place des mailing listes et des wiki ne changera rien aux motivations profondes des contributeurs. C'est en fait un tout nouveau paradigme qu'il faut inventer ( et j'en serais bien incapable ) pour rendre l'écosystème libre universellement attractif, ou du moins, moins hostile aux femmes.

Je dis tout ça en ma qualité de phallocrate assumé.

Ca va, c'est cramé que tu bosse pour Novel :)

Dingue ça, on est pourtant pas vendredi...

Quand on dit a quelqu'un, je cite: "[qu'il devrait] se suicider maintenant, avant de se reproduire", est-on vraiment dans une relation d'estime? Et pour la confiance, on voit bien avec cette histoire de e1000e qui vraque le hardware qu'on ne peut pas vraiment avoir confiance :)

J'en sais sans doute pas beaucoup plus que toi, mais il me semble que monolithique n'a rien a voir avec mono-thread (j'en suis même certain, vu les multiples kernel-threads qui tournent sur ma machine...). Et j'en suis un peu moins sur, mais il ne me semble-pas que micro-noyaux soit forcement synonyme de moins de verrous...

Si il y a un kernel hacker dans la salle pour nous donner quelques certitudes à ce propos...

Je suis toujours amusé de lire les piques de Torvalds envers Intel (déjà ses mots sur ACPI [ http://en.wikiquote.org/wiki/Linus_Torvalds | grep acpi ] ). Et je suis autant surpris de voir qu'Intel supporte tout ça sans broncher et en restant un des bons élèves dans leur relation avec Linux...

Il ne peut pas y a voir de 12.10 (et pas .1) en 2009 pour Ubuntu car le versionning ce celle-ci est strict: . . la 12.10 sera donc la Ubuntu d'octobre 2012 (si elle existe).

my 2cents.

Le lien dur est mal-aimé parce qu'il casse la métaphore du dossier/répertoire.

J'explique:

Pour les gens, "rm fichier" signifie "effacer le fichier". D'ailleurs on utilise souvant rm pour faire de la place. La blague, c'est que ce n'est pas du tout ce que signifie rm. rm signifie: supprimé l'enregistrement de ce fichier dans ce repertoire, et si le fichier a zéro enregistrement, supprimer le fichier.

Tu vois donc venir le problème. Pour les gens, un repertoire/dossier, c'est un casier dans lequel ils rangent leurs fichiers. Dans la métaphore du bureau, comme dans la réalité, un fichier ne peux pas être dans deux dossiers en même temps. C'est en ça que le lien dur "casse" la métaphore du bureau, parce qu'a partir du moment ou un fichier a plusieurs liens durs, il cesse de se comporter comme son alter-égo de la vrai vie.

D'ou le succès du liens symbolique, qui ne pose pas ces tracasseries

( ça ne veut pas dire qu'on ne peut pas jouer et faire des trucs très sympa avec les liens durs... )

Même perplexité que toi devant cet exemple en C#3... On dirait un gloubiboulga de Javascript et de (Visual)Basic, avec des morceaux de fonctionnel dedans... Beurk!

Je ne vois pas l'intérêt de faire quelque chose de totalement différent de la version précédente... Si le codeur C#2 ne retrouve plus ses petits en C#3, n'aurait-il pas mieux valu changer de nom?

Merci pour ce message qui laisse a penser que tu préfère une dictature pro-FLOSS qu'une démocratie anti-FLOSS. Il faudrait voir a ne pas se laisser aveugler par son petit combat de niche et qu'il y a beaucoup plus important que la liberté du code: la liberté des gens. Même si la liberté du code peut et doit servir à rendre les gens plus libres, le code libre ne sert à rien si l'on n'est pas libre d'en jouir ( ce point rejoint le débat des brevets logiciels: le code peut être libre, mais tu n'as pas le droit de t'en servir à cause des brevets qui pèsent dessus ).

Mais non te tais pas, pour une fois qu'on a un troll^W^W une discutions intéressante :D

Bon plusieurs choses...

Sur le discours "mauvais algo, changer algo, pas changer matos", c'est pas faux mais c'est pas voir très loins non plus. Qu'il ne faille pas prendre les avancés du matos comme alibi pour ne pas travailler sur les algos, je suis tout a fait d'accord. Mais une chose est certaines: a qualité d'algo de traitement égal, avec 12bits on a un meilleur image qu'avec 8, c'est juste certain. Après, que l'oeil fasse pas la différence, c'est pas la question, parce qu'on a tout de même démontré que suite à manipulation, on pouvait rapidement manger la marge qu'on a avec les 12 ou 14 bits.

Bon algo ou pas bon algo, si le constructeur arrive a nous sortir des capteurs en 14, 16 ou soyons fou un jour 24 ou 32 bits, moi je prends, je crache pas dans la soupe.
C'est comme les "megapixels". On lit parfois que ça sert a rien d'en avoir moult, le fait est que plus j'en ais, plus je suis heureux, parce que ça veut dire qu'en moment du traitement, j'aurais beaucoup plus de latitude pour recarder mon image.

Enfin, il y a un détail qui n'a pas été souligné assez fortement depuis le début je trouve, c'est qu'en l'occurrence on compare du 12bits entier (RAW) avec du 32bits flottant (GEGL) (gegl sait faire autre choses, mais ça à l'air d'être le mode le plus convenu).
Or voila, on ne peut pas comparer de la sorte entier et flotant. Et donc, si tu pouvais avoir raison en parlant d'entier (32bits entier c'est trop pour traiter des RAW en 12 ou 14 bits entier), en flottant c'est plus vrai du tout! Un flottant sur moins de 32 bits est pratiquement inutilisable; et pour le coup, je cracherais pas sur du flottant en 64bits.

Toujours aussi catégorique?

/me relis le sujet de la news...

Dans la mesure ou on parle de GIMP depuis le début, qui est tout de même, rappelons-le, un logiciel de TRAITEMENT d'image, ta distinction entre traitement et représentation, si elle a sans doute un peu de pertinence quelque part, tombe un peu hors sujet. On parle depuis le début de TRAITEMENT de l'image, et donc dire "ha mais moi je parlais juste de REPRÉSENTATION" à la fin du troll, ça fait vraiment rattrapage aux branches en catastrophe.

Mise à part ça, moi les discours du genre "X c'est largement suffisant" ( avec X comme "8 bits par canal", ou "640K de RAM" ) me laissent toujours sceptique... Je pense que ça dépend énormément de plein de choses, en particulier le périphérique final (déjà entre écran CRT ou TFT, y a un monde, dans l'impression, c'est encore une autre histoire, etc... ). Quand demain on aura jeté nos écrans à la poubelle et qu'on branchera directement nos cartes vidéo sur nos nerfs optiques, y à de fortes chances qu'on trouve ces affreuses images 8bits du début du siècles hideuses.

Sur le postula précis "l'œil ne peut pas distingué un dégradé sur plus de 7bits", moi ça me hérisse le poil de parler d'une valeur digitale avec un organe tout ce qu'il y a de plus analogique (et même pire que ça, biologique).

C'est un peu comme les 24 images par secondes du cinéma. Moi, je déteste aller au cinéma, parce que 24FPS, c'est définitivement insuffisant. Parfois, ça suffit, mais dès que ça bouge un peu, ça se voit, et c'est laid. En plus, immanquablement je ressorts avec mal à la tête ( ça fait cher le mal de tête ).

Tout a fait d'accord.

Exemple bête : pour l' [[Imagerie_à_grande_gamme_dynamique]] (c'est un nom qui fait très sérieux mais c'est à la porté de tout amateur de photo)
Si tu prends 2 photos raw en 14bits, t'est déjà à 28bits... Si t'en prends 3, t'es au delà des 32 bits... Donc 32 bits, c'est pas superflu, suivant l'usage...

Sur un histogramme, tu as en X la "valeur" (luminosité ou couleur... donc Xmin tu as "sombre", et en Xmax "clair") et en Y le nombre de pixel qui ont cette valeur (Ymin: peu de pixels ont cette valeur, Ymax: beaucoup de pixels ont cette valeur)

Dans mon exemple, l'histogramme me permet de voir comment je peux optimiser le contraste de ma photo.

Si tu prends toujours l'illustration suivante: http://www.xwing.info/digikam/images/histogramme_correction.(...)

typiquement, une photo avant retouche a un histogramme semblable à celui du bas: avec du vide à droite ou à gauche. Si elle à une bosse à gauche, c'est qu'elle est sous-exposée (tous les pixels ont des valeurs faibles), si elle a une bosse à droite, c'est qu'elle est sur-exposée (tous les pixels ont des valeurs fortes).

Grâce à l'outil "courbe", on peut corriger cela et s'approcher de l'histogramme présenté en haut sur l'image: une répartition optimal des pixels sur toute la plage de valeur.

Bon, je suis un photographe amateur, et clairement oui, j'ai besoin de plus de 8bits par canal pour faire de la retouche.

La modification principale que j'apporte sur mes photos, c'est de d'étendre le contraste avec l'outil "courbe" . Souvant il y a des zones "vide" aux extrèmes de l'histogramme (dans les fortes ou faibles lumières donc).

( ex flagrant ici : http://www.xwing.info/digikam/images/histogramme_correction.(...) )

En ajustant cela sur une image 8bits (genre jpeg) , tu te retrouve immencablement avec des
"franges", car forcement, tu as étendu sur 8bits une zone qui couvrait en fait 5 ou 6 bits.

Si tu parts d'une image "RAW", qui tu traite dans un outils qui sait gérer sa profondeur de 16 ou 24 bits, forcement ça change tout! avec le même exemple, tu étends sur 32 bits une zone qui en couvrait 24. Tous as toujours ces "trous" dans ton histogramme, mais ils disparaissent quand tu fais un export vers le format final (en 8bit).

Je pense que je vais prochainement craqué et investir dans un outil plus adapté au traitement photo que Gimp, mais payant: http://bibblelabs.com/fr/

Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10

heu... c'est pas plutôt huit=0o10 , ou j'ai rien compris?

$ dd bs=1M count=640 if=/dev/zero of=LinuxConsole.iso ?

oui, je -> []

Il serait suffisamment anti-américain pour boycoter Microsoft, mais pas suffisamment pour boycoter Intel ?

Du point de vue d'un libriste occidental, la nuance entre MS et Intel est flagrante ( quoique ;p ) , mais de celui d'un chef d'état sud-américain, je ne sais pas ( non, vraiment, littéralement, je ne sais pas... ) .

Tu gère ce cas comme tu gère les oeuvres à auteurs multiple en droit d'auteur: le brevet a plusieurs auteurs qui doivent s'entendre en ce qui concerne l'usage à faire de la propriété intellectuelle concernée. Je ne vois pas pourquoi ce qui marche en droit d'auteur ne marcherait pas en brevet. Ils ne se constituent pas en personne morale, ils sont tous co-inventeurs.

Un documentaire très intéressant sur l'entreprise ( The Corporation [1] ) donne une piste (qui ne plaira pas a tout le monde vu son orientation idéologique) :
l'entreprise est une personne morale, et de par cette appellation, elle a au fil du temps réclamer une grande partie des droits octroyés aux personnes physiques, jusqu'à l'excès.

Mon avis est qu'une personne morale n'est pas une personne physique, elle n'a pas à avoir les même droits. Et je pense en l'occurrence qu'une personne morale ne devrait pas avoir le droit de posséder des brevets ni même des copyrights, ni aucune forme de propriété intellectuelle. Forcement, j'entends les cheveux qui se hérissent, mais une telle mesure remettrait le brevet dans sa fonction originel : pousser les inventeurs ( de chair et de sang ) a inventer, et les protéger de ceux qui ne font qu'exploiter leurs inventions.

Forcement, une telle mesure est anti-capitaliste par nature. Si le mot existait, il faudrait dire qu'elle est travailliste, car elle récompense le travail (celui qui invente) plutôt que le capital (celui qui rémunère l'inventeur).

[1] http://www.thecorporation.com/

L'argument comme quoi elle freine les affaires est peut être vrai mais totalement contre intuitif pour le quidam. Les brevets, c'est un pillié du système capitalise, ça protège le petit inventeur du méchant patron (enfin, ça avait été fait pour ça au départ...), si tu es contre les brevets, c'est que t'es un sale rouge, etc...

Pour le multi-plateforme, Gnome a déjà Python. Python et Mono font doublon, ils jouent le même rôle (langue convi de haut niveau objet).

Moi aussi je préférerais que le Gnome de base soit livré sans bout de Mono dedans, avec juste du C et du Python. Mais bon.

Ca fait belle lurette que les "zartistes" ne s'adressent plus a un large public mais a un groupuscule de très pointu spécialistes. Tu dois confondre "zartiste" et "people".

Je dirais que le succès du commerce en ligne que l'on observe va a l'encontre de ton argumentation. Surtout qu'avec les mentalité actuelles (en occident du moins...), les gens sont limites plus scrupuleux avec leur argent qu'avec leurs droits...

Bref, l'ordianteur, "c'est pas fiable" pour le quidam, mais quand j'achete sur internet, ça arrive la plupart du temps, donc je veux bien lui confier mon numéro de CB... Alors pourquoi pas mon vote?

A mon humble avis la confiance en un système de vote sera surtout dépendant de l'attidue de la presse et des "leaders d'opinion" (quel vilain mot...)

HS aussi: je pense pas être tant que ça à contre courant, c'est juste que je repars de loins (-1) parce que j'ai salement trollé la semaine dernière :)
Merci le nouveau système :)