oliv a écrit 1442 commentaires

Quand je lis ton message ...

Sérieusement, le problème a été découvert par Coverity
http://www.internetnews.com/dev-news/article.php/3831716
et corrigé.

Et Brad Spengler fait semblant d'avoir découvert la faille pour récolter les lauriers, alors que sa contribution se limite à regarder les changelogs. Ingo Molnar souligne ce point.

Cela fait des années que l'on essaye d'expliquer que le Logiciel Libre, ce n'est pas du domaine public, mais que la GPL s'appuie au contraire sur le droit d'auteur, tout comme toutes ses soeurs (CC, BSD, ...).
Mais si maintenant même sur linuxfr on voit des raccourcis comme "illégal = contenu soumis au droit d'auteur", cela signifie qu'on a tellement perdu qu'ils ont pollué nos esprits avec leurs mensonges.

Le noyau est soumis à droit d'auteur et je le télécharge légalement !

Même quand je vais sur le site de la SNCF, mon navigateur télécharge légalement leur logo, bien que soumis à droit d'auteur. Quand je vais chez canal- pour regarder Groland, je télécharge bien ~100 MB de vidéo flash soumise aux droit d'auteur, mais c'est légal.

C'est Christine Albanel qui écrit les sondages ? Le PDG de TF1 ?

Les portraits dessinés par kitty, LordBob et autres sont superbes. Ils ont en plus bien progressé: les Elfes sont moins beaux que les mages, moins beaux à leur tour que les tout récents hors-la-loi: On voit bien comment kitty a amélioré son style (les visages surtout). Les armures des loyalistes de LordBob sont un pur régal!

Et surtout, quel plaisir de voir qu'ils n'ont pas cédé au style affreux des WoW et compagnie (tous les mecs sont des Schwarzenegger, toutes les gonzesses se battent en armure-bikini-bonnet-E...).

La dépêche annonce: "Mais on peut désormais intégrer Scilab dans les distributions de logiciels libres sans états-d'âme."
Mais quand on regarde les "release-notes", on tombe sur le bémol suivant.
"Some license issues have not been fixed."
http://www.scilab.org/download/index_download.php?page=RELEA(...)

Mais c'est super de voir un langage de la famille de Matlab devenir libre. J'ai toujours trouvé plus de potentiel à Scilab qu'à Octave, mais le dernier Octave commençait à rattraper son retard...
En plus, Scilab et Octave contiennent de nombreux ajouts (toolboxes) qui coûtent une fortune chez Matlab.

Je croyais que Gnome avait les droits de propriété intellectuelle (brevets, marques déposées et droit d'auteur) sur cette technique ? :-P

Qui a dit "trop gros, passera pas" ?

Euh... avec le niveau de français des collégiens actuels, de toute façon, même écrit en français, ce n'est pas simple non plus ;-)

Il faudrait qu'il appelle ses potes Hannibal, Futé et Looping et ils pourraient bricoler ensemble un char anti-brevets avec des vielles cartes-mères et de vieux ventilateurs trouvés au fond d'une remise. Ensuite, ils explosent la voiture des gars de Trend Micro, et avant que le Colonel Decker n'arrive, ils leur foutent une grosse trempe avec vols planés et atterrissage sur capot de voiture et mini-tower à la clef.

L'oeil est beaucoup plus performant que l'on ne croit. Il suffit de se rendre compte de la dynamique de la luminosité des objets naturels. Un simple test peut par ailleurs montrer à quel point 8 bits est bien trop limité pour l'oeil humain: Un gradient noir->blanc (R=G=B donc il n' y a que 256 niveaux de gris disponibles). Selon la qualité de l'écran, en zoomant, on peut facilement voir la différence entre deux bandes voisines (les écrans LCD ne sont pas top pour ce test, mieux vaut un CRT).
En outre, Gimp est un logiciel pour retoucher/traiter l'image, donc il faut tenir compte que les modifications de la couleur vont faire perdre beaucoup d'information. Tu commences avec une image 8 bits, tu changes le gamma, refais la balance des blancs, augmentes le contraste, et tu as vite fait de te retrouver avec une image 6 bits ou détériorée par des arrondis successifs des valeurs :-(

16 bits ou bien virgule flottante, c'est essentiel. D'ailleurs, tous les logiciels le font (PS, PSP, Pixel, Krita, Cinepaint...). Tous sauf un.

Gimp 2.4 (à venir, il en est au stade des RC) supporte les profils ICC. Par contre, comme précisé dans d'autres commentaires, Gimp reste limité aux 8bits par canal, donc mieux vaut Krita dans ce domaine.

ça ne va pas votre sondage à mélanger des années et des versions: J'utilise Linux depuis Debian Slink(2.1), sortie en Mars 1999 [1] avec un kernel 2.0.36 [2].
Ouais, c'est bien la faute de Debian, toujours avec des versions obsolètes :-P

[1] http://www.br.debian.org/News/1999/19990309
[2] http://www.br.debian.org/releases/slink/i386/release-notes/c(...)

Je trouve que tu présentes ce problème sous un aspect partial très favorable à Con Kolivas. En tant que lecteur quotidien de la LKML depuis 7-8 ans, mon opinion est très différente. Elle est sans doute partiale elle aussi. CFS a eu les faveurs de la communauté pour plusieurs raisons:
1- Il est jugé techniquement supérieur
2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X). De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.

Bref, Con a fait du bon boulot techniquement, et le patch "swap-prefetch" a toutes les chances d'être intégré au noyau, mais il n' a pas su gérer l'aspect humain de la contribution: accepter les critiques, accepter des devoir adapter son code au noyau, et non pas l'inverse.

Mais c'est mon opinion sur cette triste histoire, je le reconnais.

Bravo à l'équipe pour avoir engagé Nono malgré son échec au deuxième tour face au Président Salengro. ;-)

Cet article a quelques mois, et décrit l'utilisation de Tesseract par Groklaw pour scanner des documents pdf (dépositions, motions, décisions de tribunaux). Un script est même fourni pour aider. Il semble que Tesseract soit très satisfaisant pour ces documents "du monde réel".
http://www.groklaw.net/article.php?story=20061210115516438

Ingo (pas Igno) Molnar avait accueilli le travail de Con de manière positive à l'origine. Le problème est plutôt que Con, qui souffrait visiblement pas mal du cou et ne pouvait par conséquent pas passer de temps sur son ordi a fait un gros coup de parano. C'est clair quand on lit les messages sur la liste de diffusion (au tout début du RSDL). Ingo avait fait des critiques constructives et techniques pour suggérer des améliorations, mais Con a préférer ne pas écouter. D'où deux résultats:
1- le message de Linus cité plus haut dans cette page, alors que Linus avait très clairement encouragé Con au début,
2- Ingo a décidé de faire lui-même ce que Con ne voulait et ne pouvait pas faire (pouvait: raison physique, vu ses graves problèmes de santé).

Et, au risque de me répéter lourdement: c'est INGO Molnar!

Ni de 120 et 180 Hz, qui sont les standards de la télévision de demain...

J'ai posté plus haut des mesures faites hier avec plusieurs éditeurs. Gedit, avec un faible niveau de fonctionnalités -- comparé à geany, Medit ou Nedit -- prend environ 4 fois plus de temps pour démarrer. geany et Medit sont tous deux des éditeurs en GTK2. C'est l'avantage d'avoir un vieil Athlon 600 MHz, les différences sont plus perceptibles.

Alors, rubrique "J'ai testé pour vous", merci Bernard :

Medit (v0.8.1) : très rapide (1s) au lancement et avec une bonne dose de fonctionnalités, mais j'ai réussi à le planter.

geany (v0.10) : rapide (2s) au lancement, et avec encore plus de fonctionnalités.

Pour comparaison (les temps sont très approximatifs en valeur absolue),

TEA : environ 2s pour se lancer. Niveau de fonctionnalités comparable à Medit. Gros défaut : lance un processus Gnome (Gconf ou gnome-vfs-machin, je ne sais plus lequel) sans l'arrêter après fermeture.

Gedit : 4-5s pour se lancer, très limité en fonctionnalités. Lance 2 processus Gnome sans les arrêter après fermeture (les 2 cités plus haut).

Nedit (v5.5) : <1s pour se lancer, beaucoup de fonctionnalités, mais un toolkit un peu vieillisant (motif).

Mousepad : <1s pour se lancer (il me semble qu'il a encore accéléré depuis la RC2), peu de fonctionnalités (quand même plus que notepad).

Wine + PSPad : 4-5s pour se lancer (finalement, comme Gedit, je croyais moins, mais je m'étais trompé), plein de fonctionnalités.
À noter que PSPad 4.52 plante chez moi sous wine, et que c' est la version 4.32 que j'utilise avec succès.

Kate : J'ai pas chronométré, mais comme il faut lancer tous les trucs de KDE avant (DCOP, etc.), il est lent, et en plus lance pleins de processus KDE qui ne se ferme pas une fois que l'on quitte (même problème avec Gedit et TEA et les processus Gnome). Mais plein de fonctionnalités

Kwrite, Kedit : pas testés

Donc, voici mon choix: Mousepad remplace définitivement Nedit pour voir les textes et les éditions simples. Pour les éditions plus élaborées, je vais voir entre Medit, PSPad et geany à l'usage.

La lourdeur ne se mesure pas que par le nombre de Mega-octets, mais aussi par le temps de réaction, le temps de lancement, le CPU utilisé...
Si tu compares les temps de lancements de Mousepad et de Gedit qui ont à peu près le même niveau de fonctionnalité, ou bien le temps pour afficher le contenu d'un répertoire entre Nautilus et Thunar, la lourdeur de Gnome est plus qu'évidente.

Merci à tous pour ces suggestions. Je vais essayer sous peu. Mais je crois avoir trouvé la solution. J'ai essayé hier un truc complètement con, plus comme expérience de savant fou, et ça s'est avéré une réussite au delà de toute espérance:
wine + PSPad
Bien que moins rapide que Nedit ou Mousepad, le lancement de PSPad sous wine est de 2 à 3 fois plus rapide que celui de Gedit ou Kate (je suis sous XFCE, mais même sous Gnome ou KDE, c'est encore plus rapide). Je crois que je vais donc en rester à Mousepad et Nedit pour les éditions triviales, et que PSPad servira à des éditions plus complexes (avec diff, search&replace, ...).
Je trouve quelque chose d'inquiétant à ce que un soft Windows se lance plus vite (avec plus de fonctionnalités) que des soft natifs...

Excellent environnement, qui a remplacé chez moi le couple E+Rox-Filer. Ma bécane étant un peu vieillisante (quoique bien dotée en RAM), sa légèreté/vitesse est appréciée. En plus, ses programmes sont en général plus utilisables que leur équivalents Gnome.
Thunar est un très bon gestionnaire de fichiers, et Terminal, quoique un peu plus lent que aterm, supporte l'UTF-8, ce qui fait qu'il a aussi pris la place de ce dernier pour moi. Même mousepad est devenu mon éditeur de texte de base, remplaçant le génial Nedit ou TEA (Gedit est trop lent à démarrer). Je trouve qu'il manque toujours un équivalent de PSPad sous Linux, néanmoins (Kate en est proche, sauf en temps de démarrage).
XFWM est très bien conçu, permettant de vraiment bien _gérer_ ses fenêtres (comme KWin ou E, et par opposition aux déficients Metacity et gestionnaire de fenêtre de Windows). En espérant qu'ils continuent à ajouter des programmes simples et fonctionnels.

D'ailleurs, je crois que ce qui définit le mieux XFCE, c'est "fonctionnel". Bref, quelque chose de bien.

Sinon, concernant la news... "Il suit au plus prêt les standards" -> "Il suit au plus près les standards" ;-)

Ouaip, mais la marque a déjà été déposée par Groland Télécom ('googlez' pour voir les vidéos)

>"la barbe, il m'a volé mon idée. N'empêche c'est moi qui ait la plus longue (de barbe)
>- oui, mais moi j'ai plus de cheveux
>- m'en fous j'ai un chapeau rouge"
- et moi j'ai un chapeau un papier d'alu ! (*)
- m'en fous, moi je parle gallois couramment !
- et moi j'ai écrit un éditeur de texte encore plus compliqué à comprendre que que le gallois !


(*) voir par ex. http://lwn.net/Articles/160913/

C'est là que l'on va voir toute la beauté d'une démocratie en marche. Comme pour les OGM l'année dernière, les citoyens Suisses vont avoir la possibilité de désavouer cette loi. C'est pas en Europe avec notre Commission non élue que décide de tout qu'on verrait ça, un peuple souverain. C'est dommage que l'exemple vienne de si loin! ;-)

Si te lis le PS en dessous de la photo, tu vois qu'au moins, il n'était pas empoisonné ;-)

Ce qui était révolutionnaire, c'est que avant E13 (et non pas E16 comme le dit la page de YD), l'interface graphique sous unix, c'était assez conventionnel (voire carrément moche), genre olwn. Avec E13/14/15/16, soudain, le bureau ressemblait à un vaisseau spatial:
http://download.freshmeat.net/screenshots/21746.jpg
http://www.tersonodesign.com/images/screens/full/dr13lge.jpg
http://www.stardock.com/products/odnt/wfx_ss/mandrake.jpg
Il y avait même un thème Giger avec des alien sur les fenêtres.
http://download.freshmeat.net/screenshots/23705.jpg