Tout ça est bien réducteur... et c'est ignorer la démarche de fond qui est très importante et bénéfique à tous. Pour être honnète ce type de réflexion me navre (ou alors je t'ai mal compris).
Red Hat a participé au gros du travail dans la libc.
Red Hat est le mainteneur de gtk+, pango, glib et fait près d'un tier du boulot. Ce n'est pas que essuyer les plâtres mais pour faire avancer au mieux le logiciel libre. Meilleur est le logiciel libre, meilleur est l'offre de Red Hat fasse à ses concurrents.
Red Hat bosse beaucoup sur l'internationalisation car ils ont un gros marché dans les pays asiatiques et sont implantés un peu partout dans le monde.
La démarche n'est pas d'essuyer les plâtres et "débugger sur le tard" avec les utilisateurs mais d'installer des standards.
Une nouvelle technologie ne sort que lorsqu'elle est estimée bonne. Par exemple pour RH8.0 et RH9, il devait y avoir ACL et ACPI (toujours activé dans les versions betas). Et bien les release finales sont sortis sans (ou désactivé par défaut) car il y avait des problèmes. FC2 devait avoir SeLinux par défaut et bien c'est sorti avec SeLinux désactivé par défaut. Les tests sont fait dans rawhide ou les test/beta releases et non avec les releases finales pour justement éviter que les gens "essuient les plâtres". Trouver des bugs durant une phase de test ce n'est pas essuier les plâtres. C'est tout simplement débugger, faire le travail de mise au point. Lorsque la fonctionnalité est au point, elle sort en release finale et cette disponibilité "officielle" est un signal aux développeurs tières et ils savent qu'ils peuvent, voire qu'ils doivent, prendre en compte un nouveau "standard".
Évidement je ne prétend pas qu'une release finale est sans défaut. J'indique (avec insistance) qu'une release finale, même avec une nouvelle fonctionnalité, n'est pas une base pour les tests et le débuggage. Et évidemment aussi, t'as plus de change d'avoir des bugs lorsque tu diffuses des nouvelles technologies (même si tu penses avoir corrigé tous les bugs) que si tu restes conservateur.
Mais si personne n'adopte de nouveaux standards pour éviter "d'essuyer les plâtres" (plus pécisément pour éviter les problèmes de compatibilité) alors il n'y a jamais d'adoption de nouveaux standards qui font avancer les choses.
Ainsi FC2 est sorti avec 4KSTACK (incompatible avec l'ancien 8KSTACK) et ça a forcé (ou invité) nvidia a sortir son driver compatible 4KSTACK et celà a permis de porter et corriger plein de drivers.
Si personne ne sort une distribution avec 4KSTACK pour rester compatible avec l'existant et choyer ses clients/utilisateurs, alors Linux restera à 8KSTACK et les utilisateurs ne profiteront jamais des améliorations de 4KSTACK.
Idem pour NPTL, UTF-8, etc.
La démarche de Red Hat est "courageuse" car elle ajoute des incompatibilités qui gènent les utilisateurs. En effet Red Hat prend le risque de "froisser" des utilisateurs (donc de les perdre) à cause d'incompatibilité avec l'existant et ce dans l'objectif de faire avancer le logiciel libre (ou seulement son propre OS mais ça revient au même puisque c'est du logiciel libre). Ce risque pris par Red Hat profite à tout le monde et pas uniquement à Red Hat. Évidement ce risque est aussi accompagné de l'avantage de proposer une nouvelle caractéristique qui peut séduire du monde. Heureusement jusqu'à maintenant le rapport avantage/risque n'est pas mauvais.
Je ne demande pas que tous le monde fasse ça, mais seulement de respecter cette démarche qui profite au logiciel libre.
Red Hat n'est pas le seul à faire ça, mais dans ce domaine c'est le plus remarquable.
Pascal Terjan ne le prend pas mal, j'ai peut-être tout simplement mal interprété ta phrase.
> que ca marche bien depuis pas mal de temps
Les "problèmes" d'UTF-8 que j'ai rencontré (moi même ou sur des forums) sont à 95 % des gens qui utilisent autre chose que UTF-8 sur un système UTF-8. Par exemple des gens qui importent une base codée en iso8859 dans un SGDB qui tourne en UTF-8. Donc forcément ça merde. C'est comme ouvrir un fichier UTF-8 sur un système qui ne supporte pas UTF-8. C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8. De plus la commande iconv pour convertir les fichiers est très peu connue.
Dans le même registre ce sont les gens qui font des tris qui dépendent de la locale. Donc lorsque la locale change (pour UTF-8) ça merde. Ce n'est pas UTF-8 qui fait "merder" c'est le changement de locale. Tu changes vers une locales (non UTF-8) qui ignore les majuscules/minuscules et tu as le même problème.
Pour moi le plus gros problème d'UTF-8 était la lenteur de grep :-)
Ça c'est significativement amélioré.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 7.
Tout ça est bien réducteur... et c'est ignorer la démarche de fond qui est très importante et bénéfique à tous. Pour être honnète ce type de réflexion me navre (ou alors je t'ai mal compris).
Red Hat a participé au gros du travail dans la libc.
Red Hat est le mainteneur de gtk+, pango, glib et fait près d'un tier du boulot. Ce n'est pas que essuyer les plâtres mais pour faire avancer au mieux le logiciel libre. Meilleur est le logiciel libre, meilleur est l'offre de Red Hat fasse à ses concurrents.
Red Hat bosse beaucoup sur l'internationalisation car ils ont un gros marché dans les pays asiatiques et sont implantés un peu partout dans le monde.
La démarche n'est pas d'essuyer les plâtres et "débugger sur le tard" avec les utilisateurs mais d'installer des standards.
Une nouvelle technologie ne sort que lorsqu'elle est estimée bonne. Par exemple pour RH8.0 et RH9, il devait y avoir ACL et ACPI (toujours activé dans les versions betas). Et bien les release finales sont sortis sans (ou désactivé par défaut) car il y avait des problèmes. FC2 devait avoir SeLinux par défaut et bien c'est sorti avec SeLinux désactivé par défaut. Les tests sont fait dans rawhide ou les test/beta releases et non avec les releases finales pour justement éviter que les gens "essuient les plâtres". Trouver des bugs durant une phase de test ce n'est pas essuier les plâtres. C'est tout simplement débugger, faire le travail de mise au point. Lorsque la fonctionnalité est au point, elle sort en release finale et cette disponibilité "officielle" est un signal aux développeurs tières et ils savent qu'ils peuvent, voire qu'ils doivent, prendre en compte un nouveau "standard".
Évidement je ne prétend pas qu'une release finale est sans défaut. J'indique (avec insistance) qu'une release finale, même avec une nouvelle fonctionnalité, n'est pas une base pour les tests et le débuggage. Et évidemment aussi, t'as plus de change d'avoir des bugs lorsque tu diffuses des nouvelles technologies (même si tu penses avoir corrigé tous les bugs) que si tu restes conservateur.
Mais si personne n'adopte de nouveaux standards pour éviter "d'essuyer les plâtres" (plus pécisément pour éviter les problèmes de compatibilité) alors il n'y a jamais d'adoption de nouveaux standards qui font avancer les choses.
Ainsi FC2 est sorti avec 4KSTACK (incompatible avec l'ancien 8KSTACK) et ça a forcé (ou invité) nvidia a sortir son driver compatible 4KSTACK et celà a permis de porter et corriger plein de drivers.
Si personne ne sort une distribution avec 4KSTACK pour rester compatible avec l'existant et choyer ses clients/utilisateurs, alors Linux restera à 8KSTACK et les utilisateurs ne profiteront jamais des améliorations de 4KSTACK.
Idem pour NPTL, UTF-8, etc.
La démarche de Red Hat est "courageuse" car elle ajoute des incompatibilités qui gènent les utilisateurs. En effet Red Hat prend le risque de "froisser" des utilisateurs (donc de les perdre) à cause d'incompatibilité avec l'existant et ce dans l'objectif de faire avancer le logiciel libre (ou seulement son propre OS mais ça revient au même puisque c'est du logiciel libre). Ce risque pris par Red Hat profite à tout le monde et pas uniquement à Red Hat. Évidement ce risque est aussi accompagné de l'avantage de proposer une nouvelle caractéristique qui peut séduire du monde. Heureusement jusqu'à maintenant le rapport avantage/risque n'est pas mauvais.
Je ne demande pas que tous le monde fasse ça, mais seulement de respecter cette démarche qui profite au logiciel libre.
Red Hat n'est pas le seul à faire ça, mais dans ce domaine c'est le plus remarquable.
Pascal Terjan ne le prend pas mal, j'ai peut-être tout simplement mal interprété ta phrase.
> que ca marche bien depuis pas mal de temps
Les "problèmes" d'UTF-8 que j'ai rencontré (moi même ou sur des forums) sont à 95 % des gens qui utilisent autre chose que UTF-8 sur un système UTF-8. Par exemple des gens qui importent une base codée en iso8859 dans un SGDB qui tourne en UTF-8. Donc forcément ça merde. C'est comme ouvrir un fichier UTF-8 sur un système qui ne supporte pas UTF-8. C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8. De plus la commande iconv pour convertir les fichiers est très peu connue.
Dans le même registre ce sont les gens qui font des tris qui dépendent de la locale. Donc lorsque la locale change (pour UTF-8) ça merde. Ce n'est pas UTF-8 qui fait "merder" c'est le changement de locale. Tu changes vers une locales (non UTF-8) qui ignore les majuscules/minuscules et tu as le même problème.
Pour moi le plus gros problème d'UTF-8 était la lenteur de grep :-)
Ça c'est significativement amélioré.