GeneralZod a écrit 2316 commentaires

En même temps, ça dépends en partie des polices, autant on voit la différence avec DejaVu, autant c'est imperceptible avec Liberation.

> aspect des caractères nikel par rapport à Fedora (mais ça va changer, y'a un brevet qui est bientôt terminé je crois)

rpmfusion propose une version de freetype compilé avec l'interpréteur de bytecode breveté (qui ne l'est plus depuis fin 2009)
$ yum --enablerepo=rpmfusion-free freetype-freeworld
Pour le moment, c'est encore désactivé dans Fedora à cause d'une régression.

> c'est plus de 60% des navigateurs web (à la louche) qui supporte peu / pas / mal HTML5.

Les choses évoluent, sans compter que la durée de vie d'un smartphone, c'est grosso modo deux ans, et des nouveaux modèles et révisions d'OS sortent tout les 3 à 6 mois.
IE (le principal boulet à l'adoption de HTML5) est complétement à la ramasse sur ce marché et IE9 devrait combler une partie du gouffre.

> De plus en terme de perf, un flash bien fait et du pur html5 / js n'ont rien à voir en terme de répondant.

La plupart des conneries flash du web peuvent être remplacé avantageusement par HTML5+javascript.

> la compatibilité avec les navigateurs du marché est très différente

La reprise de la guerre des navigateurs, l'arrivée de l'iPhone ont justement commencé à faire bouger les géants du web afin qu'ils prennent en compte les nouveaux standards du web.

> je ne vois pas ça comme un pas en arrière vis à vis du HTML 5, mais comme une phase de transition obligatoire

Apple a prouvé le contraire, l'iPhone a complétement chamboulé le marché des smartphones et S. Jobs a complétement gagné son pari de vendre sa brique sans flash.

> On voit que Android, lui au moins, a un réel argument pour que l'on programme avec le SDK fourni au lieu d'avoir une sur-couche.

On voit surtout que tu dis n'importe quoi (et que tu n'as pas compris l'article de Robert Love). L'intérêt des SDK alternatifs pour l'iPhone n'est pas de permettre le multi-tâches mais de réutiliser le code et les compétences existantes.
Android permet une forme de multi-tâches, mais derrière faut se palucher une architecture applicative différente de ce qui existe, les possibilités de réutiliser des libs natives existantes sont très pauvres (le NDK est un cache misère, entre autre impossible de lancer un processus natif en dehors de l'environnement Android). Si Android est boudé par les éditeurs de jeux, et continuent de supporter les restrictions d'Apple (notamment pas de moteurs de scripts tiers), c'est pas pour faire chier Google.

Si tu compares les deux SDK, celui de l'iPhone l'emporte haut la main. Apple a une bien meilleure maitrise de sa plateforme et une plus grande expérience dans la conception d'API.
https://linuxfr.org//forums/31/28589.html

Après, les notifications, la synchro des distros, les réseaux sociaux sont la nouvelle marotte de PlasticMan.
Je trouve d'ailleurs surprenant qu'on ne parle pas de MeMenu dans la dépêche, une applet permettant d'accéder aux réseaux sociaux/messageries instantanément directement. Pourtant, ça constitue avec Gwibber la grosse nouveauté de cette version LTS.
https://wiki.ubuntu.com/MeMenu

c'est xsane qui a dégagé, simple-scan s'appuie toujours sur sane (et pourquoi ils n'ont pas repris le développement de gnome-scan/flegita tout simplement mystère !)

Pour HAL, regarde mon commentaire plus haut.

Pour Ubuntu One, TVS travaille sur un port Fedora (les dépendances ont été importées, reste à travailler sur le client)et Maemo (pas fonctionnel encore)
http://thomas.apestaart.org/log/?p=1074


> Si non, dropbox a encore de beaux jours devant lui...
L'absence d'un client windows et mac est plus rédhibitoire pour l'avenir commercial du service, d'un point de vue business, c'est même de l'amateurisme.

Le nettoyage de HAL n'est pas terminé: par exemple, le contrôle du backlight chez radeon passe encore par HAL, pm-utils, beaucoup de paquets dépendent de gnome-vfs (qui ne sera pas mis à jour, étant déprécié par gvfs)
https://wiki.ubuntu.com/Halsectomy
http://fedoraproject.org/wiki/Features/HalRemoval

Quant à DeviceKit, il est lui-même déprécié et remplacé par upower et udisks (anciennement DeviceKit-Power et DeviceKit-Disks).

> Sauf qu'il avoue juste qu'il ne veut pas de Flash pour qu'on developpe des applis natives sans surcouche

Dans son communiqué, il traite de deux problèmes distincts, Flash/HTML5 pour le web, et des SDK multiplateformes pour smartphones.
Pour le second problème, il n'a pas tout à fait tort, en disant que la plupart des SDK se limitent au dénominateur commun et s'intègrent mal à l'environnement. Le succès de l'iPhone est basé sur une expérience utilisateur cohérente, chose impossible avec JME et l'actuelle mouture de Flash. Ici aussi, ça reste une explication plausible, même si on n'est pas d'accord.

Ce qui est dommage, c'est que ça affecte potentiellement des SDK qui essaie justement de s'intégrer au plus près des plateformes cibles tel que MonoTouch.
http://tirania.org/blog/archive/2010/Apr-28.html


> L'iPhone a surtout démontré que tout le monde est prêt à redévelopper une appli par plateforme cible pour accéder à son site plutôt que de respecter un standard.

Quel standard ? Gtk+ ? Qt4 ? .Net ? Java ? les standards du web ?
À l'origine, Apple encourageait les développeurs à faire des applications web, le SDK n'est apparu que sous la pression des développeurs justement.

> Le cauchemar des webdesigner avec le standard de facto qu'était IE s'apprête à se répéter.
Tu délires complétement, WebKit est l'un des moteurs de rendu les plus respectueux des recommandations du W3C. C'est le même WebKit derrière Safari, QtWebKit, WebKitGtk, wxWebKit, etc ...

Quicktime, c'est juste l'API multimédia d'Apple (et un lecteur multimédia éponyme), bref, tu comparerais flash à gstreamer ?

Faut replacer cette critique dans son contexte, S. Jobs parle uniquement du web.
Aujourd'hui, Flash est complétement dépassé: conso CPU hallucinante, multiplication des plateformes (tactile, absence de claviers physiques, taille d'écran plus nombreuses), et en même temps les technologies du web ont bien évolués (HTML5, SVG, javascript etc ...) et sont de mieux en mieux supportés (même Microsoft est obligé de suivre le mouvement, c'est dire).

l'iPhone a démontré que l'on pouvait se débarrasser de Flash, l'iPhone se vends comme des petits pains malgré un "accès incomplet" au web (dixit la daube).

Je trouve l'argumentaire de S. Jobs plutôt pertinent, Adobe ferait bien de suivre son conseil d'abandonner Flash au profit de HTML5 (et montre que Jobs considère encore Adobe comme un partenaire que comme un simple rival). Il a toujours eu le nez fin pour dénicher les bonnes technologies, et ces derniers temps (juste la dernière décennie quoi), ça se répercute sur son business.
Je note une fausse note: H264 n'est pas ouvert, et ne peut que mener à la fragmentation du web.

Je sais pas si c'est une édition post-mortem, mais en tant qu'amateur d'humour noir, ça m'a fait sourire, cette ligne sur son profil.
Interests: Life
http://chakra-project.org/team.html#funkyou

Mes condoléances à la famille, les amis et à la communauté Chakra Linux.

> il est simple de migrer vers la centos ou la scientific linux (sans tout réinstaller)
Suffit tout simplement de remplacer les paquets redhat-release-notes redhat-release redhat-logos par leurs équivalents CentOS et ça roule. C'est même expliqué quelque part sur le wiki de CentOS.
Par contre, faudra un peu de patience avant que CentOS ouvre la branche 6 (pour la 5.5, ils sont encore à la phase construction/QA)

À titre d'exemple, la manoeuvre inverse (la principale différence est l'activation de RHN):
http://blog.famillecollet.com/post/2010/04/15/Switch-from-Ce(...)

http://www.daskeyboard.com/daskeyboard_model_s_ultimate.php

En plus, il est très agréable d'utilisation.

> Si tu surfes au clavier, pointer une adresse au milieu de la page te prendra plus de temps au clavier qu'a la souris
Avec un navigateur adapté à la navigation clavier genre uzbl ou vimperator, pas du tout.

> et encore plus de temps qu'avec un ecran tactile..
Forcément, primo, ce genre de gadgets n'a pas de vrais claviers en général, secundo, avec ton doigt, ça ira forcément plus vite qu'avec une souris.

> Parce que meme pour du code je prefererais toujours quelqu'un qui reflechis a ce qu'il fais qu'a quelqu'un qui tappe vite.
L'objectif ce n'est pas de taper le plus rapidement possible, mais d'être le moins freiné possible par ton environnement. Après, si le goulot d'étranglement se situe avant, c'est un autre problème.
Sans devoir taper au kilomètre en permanence, on gagne plus souvent du temps quand on se dispense de la souris que l'inverse.

Le temps de réponse est plutôt bon, mais faudra également tester avec d'autres pages (notamment dynamiques) et les autres serveurs pour faire ton choix.

Je te recommanderais de pas faire le test en local, voire pas sur le même réseau local pour que ce soit plus pertinent.

Merci d'avoir satisfait ma curiosité (et du dialogue amusant !). :o)

Niveau performances, je te conseille d'utiliser ab l'utilitaire de benchmarks d'Apache pour tester le comportement de ton serveur en charge.
À ce niveau-là, Cherokee est plutôt bon avec une empreinte mémoire faible, son interface d'admin est simple d'utilisation. Par contre, les fichiers de confs sont une horreur à éditer manuellement, et c'est pas vraiment fait pour des pages dynamiques.

Je préfère lighttpd qui a des bonnes perfs, simple d'administration, on me dit également beaucoup de bien de nginx notamment avec des sites à gros trafic.

Pour la question du reverse proxy pour subversion, l'ayant fait avec lighttpd, t'es quant même gagnant. Personnellement, j'utilise plus subversion au profit de Git et Mercurial. Mercurial est très bon pour les transferts via HTTP (pour Git, il vaut mieux utiliser le protocole dédié).

Je te déconseille vivement sqlite pour un trac, à partir d'une certaine taille et niveau de concurrence, ça devient ingérable. Pour la base de données, si tu aimes les outils d'administration graphique ==> MySQL, (note que Dotclear2 exige le moteur transactionnel InnoDB avec MySQL), MySQL pulse bien avec les applications web avec MyISAM. Sinon Postgres est plus robuste et offre des fonctionnalités plus avancées.

> compiz est entièrement pilotable au clavier
J'ai dit le contraire quelque part ? Même si il est entièrement pilotable au clavier, c'est loin d'être aussi optimal qu'un gestionnaire de fenêtres en tuiles.
Sans compter que Compiz, c'est le Jacky des gestionnaires de fenêtres, certes, les effets sont plus spectaculaires que ceux d'OS X mais ils ne font que desservir l'expérience utilisateur. Certes ça se configure, mais c'est pénible avant d'arriver à quelque chose d'utilisable, et c'est lent (faut le faire pour être significativement plus lent que Metacity).

Les gestionnaires de fenêtres des bureaux majeurs ont un mode composition donc on peut se passer de Compiz.

Je dis juste que GOLD n'est pas la solution miracle non plus: pas multiplateforme, dans certains cas moins bon que GNU ld mais ça ne lui retire rien de ses qualités (rapide, robuste, meilleure gestion du C++)

> mais en pratique, je connais des collègues autour qui n'ont pu effectuer l'édition de lien de leur que grâce à GOLD (ld finissait en out-of-memory).

question qui me turlupine, ils faisaient comment avant ?

Élargir ta productivité tout simplement, avec un peu de maitrise, tu seras toujours plus rapide avec un clavier qu'avec une souris.
L'intérêt c'est d'avoir un environnement adapté pour chaque type d'utilisateur, pas vraiment d'économiser les ressources matérielles. Sinon pourquoi Emacs, pourquoi Vim, pourquoi un shell, pourquoi uzbl ? la courbe d'apprentissage est longue, mais si on se donne la peine d'aller jusqu'au bout, ça vaut le coup.

> Il n'y a que moi qui trouve que tu n'as pas lu le commentaire auquel tu réponds ?

Si j'ai lu, mais je trouve qu'au contraire c'est bien choisi comme nom. Le projet a pour objectif d'offrir des logiciels qui "sucent moins" pour sa cible, les utilisateurs tout puissants. Contrat rempli, non ?
Puis, c'est un clin d'oeil humoristique au langage peu châtié (voire de charretier) des passionnés d'informatiques de la vieille école. Puis je vois mal un projet grand public s'appeler "suce moins" donc pourquoi s'en priver ?

> Il n'y a que moi qui trouve ça un peu élitiste, un peu à contre courant des valeurs de tolérance, d'ouverture du libre ?

Il n'y a que moi qui trouve ce message un peu populiste, un peu à contre courant des valeurs de tolérance, d'ouverture du libre ?

C'est quoi le problème si des personnes veulent écrire dans leur coin du code pour satisfaire *leurs* besoins propres ? C'est très bien qu'on s'occupe du joseph moyen, mais c'est tout aussi bien de s'occuper de l'utilisateur tout puissant. On satisfait une gamme plus large d'utilisateurs, on évite pas mal de conflits dû aux divergences d'opinion au sein des projets source, etc ...

Marre de la dictature populo-populiste qui veut absolument que les développeurs libristes chient de la codasse amicale à l'utilisateur problématique entre la chaise et le clavier.

Theora étant nettement moins consommateur de CPU que H264, on peut probablement s'en tirer avec un décodeur logiciel bien optimisé.

C'est négliger le fait qu'avec Android, Youtube, Chrome, Google aurait très bien pu peser sur la balance en imposant Theora. Récemment, ils ont sortis un téléphone, ils auraient très bien pu imposer la présence d'un décodeur Theora, bref, si ils voulaient vraiment soutenir Theora, ils possédent le poids suffisants pour que les industriels écoutent.

Mais ils ne l'ont pas fait et ont choisi de soutenir H264.


> ce financement serait un choix judicieux pour se conserver une porte de sortie le jour où H.264 posera problème.

Ça réglerait pas les soit-disant problèmes de qualité, bande passante, le rachat du matériel, tsouin tsouin pouet pouet que zenitram évoque. Avant de financer une implémentation spécifique, si vraiment Google voulait faire de Theora une porte de sortie, il serait peut-être plus pertinent de financer l'amélioration du codec (comme Mozilla et WikiMedia l'ont fait). Donc, évoquer une porter de sortie dans ce contexte, c'est faire le grand écart.

Ce financement, c'est de la poudre aux yeux pour dire "regardez, nous Gogole on est des gentils, on donne des sousous à Theora (alors qu'en fait c'est juste TheorARM)", et probablement avoir un meilleur support de Theora.

> C'est vrai ça, mettre de l'argent dans une partie de Theora

Ils financent *une* implémentation de Theora sur plateforme ARM, c'est très différent de financer le développement du codec.

> et mettre Theora dans son navigateur

Et derrière Google refuse les patchs qui permettraient de lire du Theora dans Chromium là où on ne peut pas fournir FFMPEG (Cf la proposition des développeurs de GStreamer de fournir un support optionnel de GStreamer). Google veut bien qu'on puisse lire du Theora dans Chromium/Chrome à condition que H264 soit supporté derrière.
Quant au support de Theora dans Chromium, il est loin d'être mature.


> pourquoi tu y met pas ton ton argent à la place de râler que les autres y mettent pas le leur

Merci, mais je ne t'ai pas attendu pour le faire.
http://www.xiph.org/donate/
Et je n'exige pas de Google de mettre de l'argent dans Theora, juste qu'ils arrêtent de pousser H264 dans HTML5.


> Pour le moment, Google soutient bien plus, beaucoup plus, Theora que toi.

Et Microsoft soutient bien plus, beaucoup plus le logiciel libre que toi. Après tout, ils maintiennent bien IronPython et quelques trucs libres.
Certes, ils financent TheorARM, ils ont financés Xiph via les GSoC avant 2010, ils ont même filé le code à la base de Theora via On2 ... etc. Par contre, y a plus personne pour soutenir les codecs libres dans HTML5.

Faudrait trouver des arguments plus convaincants que ça parce que là, on atteint le comble du ridicule avec "Google soutenant Theora"