Je ne comprends pas vraiment l'intérêt de bloquer l'installation d'OS alternatifs sur plateforme ARM, étant donné que ça ne concerne que trois geek à lunettes dans leur garage. En fait, les plateformes ARM n'étant pas plug & play, même installer un Android 2.2 sur une machine Android 1.6 est déjà très difficile (pilotes à porter manuellement au nouveau noyau).
Quant aux vendeurs comme HTC qui vendent certaines machines avec Windows Phone 7 ou Android, le dual boot leur sera interdit (s'ils veulent le logo), mais ils peuvent toujours vendre deux modèles... Voire, un modèle Windows 8 certifié et un modèle dual boot sans logo.
Peut-être Microsoft craint-il que ça faciliterait le contournement des DRM.
C'est assez étonnant de voir que les nouvelles règles de certification Microsoft font une différence énorme entre x86 et ARM.
1) Sur ARM, le "Secure Boot" ne doit pas pouvoir être désactivé, même par action explicite de l'utilisateur. L'utilisateur ne peut pas non plus ajouter de nouvelles clés.
2) Sur les plateformes non ARM (x86-32 et 64), le "Secure Boot" doit pouvoir être désactivé par action explicite et manuelle de l'utilisateur. L'utilisateur doit aussi avoir la possibilité d'ajouter de nouvelles clés manuellement (via le Custom Mode).
Donc, les utilisateurs PC peuvent se rassurer. Je suppose que Microsoft craint que sans ça, il lui soit impossible d'upgrader à Windows 9 sur les PC Windows 8, même si en théorie, le système de signature le permettrait.
On peut se plaindre que des possibilités qui semblent techniquement correctes au premier abord, ont été refusées, mais il faut savoir qu'une fois une API de l'espace utilisateur est définie, la politique du noyau oblige à la conserver définitivement, sauf exception rare (p.e. sysctl(2) pourrait être supprimée). Donc, une erreur de design est conservée définitivement (p.e. dnotify). Mieux vaut donc réfléchir à deux ou quatre fois avant d'implémenter quelque chose.
C'est possible que ta distro ait inclus le patch bien avant l'upstream.
Par exemple, le bogue a été corrigé en 2007 dans Ubuntu et Debian.
Moi, j'en ai souffert parce que Gentoo inclus une version très proche de l'upstream.
De plus, la lenteur se sent plus sur certaines regexp, dont celles incluant le méta-caractère point.
Mike Haertel oublie de préciser que jusqu'en 2010 GNU grep avait des performances atroces en UTF-8, ce qui n'est pas glorieux.
Par exemple grep 2.5.4 met 42 secondes sur un Core 2 Duo 2Ghz à exécuter:
$ time LC_ALL=fr_FR.UTF-8 grep . a.txt > /dev/null
real 0m42.440s
user 0m42.432s
sys 0m0.001s
Où le fichier a.txt est un fichier de 40000 lignes (80 Ko) de 'a'.
Alors qu'en locale C, 8 millisecondes suffisent
$ time LC_ALL=C grep . a.txt > /dev/null
real 0m0.008s
user 0m0.007s
sys 0m0.000s
C'était tellement lent que j'ai découvert le "bogue" sur un traitement d'un fichier contenant des noms de fichiers à déplacer d'un répertoire à un autre, parce que c'était trop lent... Le facteur limitant n'étant pas le déplacement des fichiers mais quelques opérations grep!
Heureusement ça a été corrigé à la 2.7 sortie en septembre 2010.
Le bogue
Microsoft a dit que secure boot doit être actif pour booter Windows
C'est incorrect. Microsoft oblige "secure boot" a être actif pour donner le logo "Designed for Microsoft Windows 8", mais Windows 8 pourra très bien démarrer sur des machines n'ayant pas de secure boot.
Ce que tu décris, ça ressemble à une installation de GNU/Linux d’avant 2000 ou à
un scénario catastrophe, mais absolument pas à la réalité d’une installation de
distribution actuelle !
C'est vrai que je n'ai pas eu de chance, mais le fait que RHEL ne soit pas vraiment pensé pour le desktop, le fait qu'en plus j'ai installé des paquetages non officiels n'a pas arrangé les choses, XFCE ne faisant pas partie de RHEL et en plus, CentOS incluant une version qui date d'une époque où XFCE n'était pas très au point.
Le coeur de RHEL/CentOS fonctionne bien, c'est juste qu'à mon avis, il vaut mieux installer une Fedora sur le desktop, parce qu'elle contient des pilotes récents, et que les environnements comme GNOME2 et XFCE4 s'améliorent suffisamment pour que ça vaille la peine de prendre une version récente, plutôt qu'une vieille version en partie déboguée (GNOME2 est en 2.16 sous CentOS 5 et XFCE4 était en 4.4, et maintenant en 4.6).
En fait, ton témoignage me paraît tellement loin de la réalité que je me suis même
demandé honnêtement s’il n’avait pas comme objectif caché de faire fuir les
débutants qui voudraient se tourner vers GNU/Linux.
Non. En fait, maintenant que j'ai réussi à faire une bonne install de CentOS, je la recopie sur des nouveaux PC sans problème, mais, ma conclusion est que les débutants devraient plutôt essayer Fedora, Linux Mint ou Ubuntu.
En tout cas, tes parents ne doivent pas vraiment se sentir maître de leur outil
informatique maintenant, ou savent-ils faire tout ça ?
Ils ne se sont jamais sentis maître de leur ordinateur, mais avec Linux, c'est bien plus facile de scripter leur interface pour qu'elle fasse ce qu'ils souhaitent le plus simplement possible.
== Mon expérience avec CentOS sur le desktop ==
Comme j'en avais marre d'utiliser des distributions instables et que je n'aime pas Debian à cause de modifications apportées à certains paquets (notamment exim4), ça fait maintenant un bon moment que j'utilise CentOS 5.x.
Je l'ai installé sur les PC de mes parents qui sont tous deux des newbies en informatique. L'installation elle même demande pas mal de temps, parce qu'il ne supporte pas nativement le matériel moderne. Pour le wifi, il suffit de recompiler un noyau récent, par contre pour gérer les chipsets Intel intégrés GMA 945, il m'a fallu recompiler depuis les sources un X.org récent, Mesa, et pas mal de dépendances, et puis KMS dans le noyau.
J'ai fait l'erreur d'installer XFCE depuis les dépôts extra CentOS, parce que nautilus manquait des fonctions cruciales (p.e. mode liste). Mais les éléments d'XFCE plantent trop souvent (xfdesktop tout le temps, xfce4-panel dans une moindre mesure, le gestionnaire de volume sonore de temps en temps). J'ai finalement amélioré Thunar (qui a de sérieux problèmes de performances à la base) et installé un système hybride GNOME/XFCE, avec le desktop nautilus modifié pour utiliser l'association Thunar sur les dossiers plutôt que nautilus lui-même, avec Xfwm4 (qui n'a jamais planté) comme gestionnaire de fenêtres, et tout le reste en GNOME.
J'ai aussi eu quelques soucis avec le fait qu'ext3 réserve 5% de l'espace disque, par défaut, au root, et ainsi quand il n'y a que 4% d'espace disque restant, les fichiers de config des programmes ont la fâcheuse tendance d'être détruit, ne faisant plus que zéro octets, parce que les programmes ont une mauvaise gestion des erreurs. Mousepad était encore meilleur que ça puisqu'il SEGFAULTAIT bourrin dans ces circonstances.
Moyennant ça, il n'y a pas de problème de stabilité majeur. Les seuls problèmes restant sont gedit qui semble figer en prenant 100% du CPU dans certaines circonstances rares, et fusesmb qui plante souvent (provenant de RPMforge), NFS n'ayant pas une tolérance d'erreur suffisante pour être utilisable. L'édition de partition de musique n'est pas encore au point, avec rosegarden qui plante quand même assez souvent.
Sinon, mplayer, firefox, sylpheed, gthumb, GIMP, xterm et le calendrier d'Evolution marchent très bien. Le bon vieux GDM est très stable, complet, et joli. Le noyau 2.6.32.x que j'ai compilé marche très bien. Les problèmes viennent surtout des paquetages ne provenant pas de Red Hat.
Enfin, il m'a fallu beaucoup de temps pour avoir un système fonctionnel, mais maintenant, ça marche pas mal.
PS: Avec les distro bleeding-edge comme ArchLinux ou Fedora, j'ai beaucoup plus de problèmes, notamment des régressions à toutes les mises à jour.
Avec tun/tap, c'est très commode pour créer du tunneling IP sur une seule connexion TCP, à travers un pare-feu. En théorie, ça doit même marcher si on a juste un PROXY HTTP à disposition, du moment qu'il supporte l'option CONNECT.
Je n'ai jamais essayé, mais avec SSL:, SSL-LISTEN: et PTY:, on doit pouvoir facilement créer quelque chose d'équivalent à SSH.
En pratique, c'est aussi assez commode pour copier une install Linux sur une nouvelle machine, avec Schily's star qui crée la tarball d'un côté, socat qui copie via une simple connexion TCP nue, et star qui décomprime la tarball de l'autre côté. C'est plus simple qu'un point de montage NFS.
2) Il fait partie de l'Open Specification Promise de Microsoft. Ainsi, Microsoft promet qu'il n'attaquera pas en justice sur ses brevets quiconque fournira une implémentation conforme à ses spécifications. C'est la même chose pour OOXML.
Bien sûr, il y a toujours un risque que Microsoft attaque en argumentant que quelque détail n'est pas conforme à sa spécification.
3) Il existe des implémentations fonctionnelles indépendantes.
4) Quand bien même Microsoft attaquerait quelqu'un sur ses brevets, le format d'Excel n'a pas énormément changé depuis Excel 5 en 1993 (il utilisait déjà le Compound Document Format et VBA pour les macros). Les derniers brevets significatifs tomberont donc au plus tard en 2013. Quant aux nouvelles fonctionnalités, on peut certainement les oublier sans perdre d'information.
De plus, les CSV ont une première ligne qui contient des métadonnées. Certes très abrégées, mais en réfléchissant un peu, on peut comprendre ce qu'elles signifient.
Franchement, je ne m'attendais pas à des données aussi exploitables que ça... Ils auraient pû nous filer des scans de mauvaise qualité de documents imprimés.
Vu que beaucoup de chose sont du travail de
fond ce que je veux bien comprendre
pourquoi ne pas diminuer par au moins 2 le
nombre de mise à jour.
À mon avis, un rythme de sortie trop rapide pose des problèmes
1) De stabilité et sécurité: car on rajoute beaucoup de bogues à chaque version et les quelques semaines de développement actif ne suffisent pas à les corriger.
2) D'adaptation en milieu de l'entreprise. Ce n'est pas agréable, toutes les 6 semaines, d'avoir un doute quand à la compatibilité de ses services Web intranet, même si c'est de la faute au service mal codé.
La solution qui me paraît la meilleure est celle adoptée par le noyau Linux. Avoir des versions supportées sur le long terme (1 ou 2 ans), qui contiennent tous les rétro-portages des bogues corrigés dans les versions ultérieures.
Pardon, y’a deux pauv' programmes qui foutent la merde, et c’est se voiler la face > que de considérer que ce sont ceux là qu’il faudrait changer plutôt que le système > de distribution des milliers de paquets qui tournent au poil ?
Le fait que ces programmes soient supportés par Linux Mint implique qu'ils sont testés, contrairement à Debian sid ou même Debian testing, et c'est d'autant plus normal que le bogue n'est pas dans la GLIBC.
Si on a pas besoin de ces programmes, Debian testing est peut-être aussi bon ou meilleur que Linux Mint, mais le fait est que beaucoup d'utilisateurs veulent les installer. Au quel cas, Linux Mint est un choix plus logique.
Le fait que les NVIDIA ou Adobe soient responsables de ça, ne change rien au fait.
Quant aux alternatives libres (nouveau et GNASH), elles ne sont pas encore suffisament prêtes.
La GLIBC est très rétro-compatible, au niveau source, mais même au niveau binaire depuis la version 2.0. Bon, d'accord, Ulrich Drepper a un peu pété les plombs avec la 2.14, mais ça n'affecte pas GNOME2.
Le noyau est très rétro-compatible. Par exemple, j'ai utilisé un vieil environnement Debian 1.2 avec un noyau 2.6.32.
XLib n'a pas vraiment changé depuis longtemps, par contre, en effet, on risque d'en baver avec Wayland. On sera obligé d'utiliser un serveur X par dessus Wayland.
La détection du matériel n'a pas changée au niveau de l'interface avec le noyau (/sbin/hotplug, sysfs, netlink). C'est juste les programmes comme HAL, udev, udisks, systemd qui font exprès de changer pour le plaisir. Ça pose quelques problèmes de délégation de responsabilité, mais, ce n'est pas très dur de configurer le système pour donner toute la responsabilité, soit à HAL+GNOME2, soit à UDISKS+GNOME3.
Après, c'est sûr que GNOME3, bousille les concepts de rétro-compatibilité et modularité de Linux, ce qui a pour effet de restreindre les choix.
Ce projet est un pari.
S'il échoue, ça voudra dire que la liberté de choix du logiciel libre est totalement illusoire, ce qui me paraît tout à fait possible.
S'il réussit, ça voudra dire que le libre sert quand même à quelque chose.
C'est ce que j'appelle maintenance minimale. Sans vraiment ajouter de nouvelles fonctions, on corrige les bogues qui "apparaissent". Ça ne paraît pas être une tâche titanesque. Après tout, en 2 jours, j'étais arrivé à faire fonctionner GNOME 1.4 pas trop mal, sur une machine moderne.
Pense tu sérieusement que malgré la bonne volonté des personnes
derrières Matte ils arriveront à avoir le même niveau de stabilité que
le projet mainstream ?
Il n'y a pas grand chose à faire pour l'instant puisque GNOME 2 est déjà stable et complet. Il y a un certain travail de rebranding à faire, mais après, la maintenance est minimale.
Donc, en gros, ce n'est pas en regardant le code, la licence, ou le modèle de développement (communautaire comme Linux, ou dirigé par une seule société comme Qt) que l'on peut savoir si c'est libre ou open source, mais en regardant si les mainteneurs ont de la barbe et portent un Tee-shirt FSF.
Franchement, j'ai vraiment cru que c'était une blague quand j'ai vu qu'ils commençaient à parler de changer l'historique du noyau... Mais, l'article ne date pas du premier avril et j'ai suivi les références, et non seulement, le projet Linux-libre semble exister, avec des changelogs comme:
> ARCH_NETX - Hilscher NetX based
> arch/arm/mach-netx/xc.c: disabled non-Free firmware-loading machinery
> arch/arm/mach-netx/xc.c: removed blobs
> drivers/net/netx-eth.c: removed blobs
S'ils ne veulent pas induire en erreur les gens sur le firmware proprio, ils n'avaient qu'à le mettre dans un dossier proprietary/, comme ça, l'utilisateur verrait dans la sortie du noyau un message du genre "Could not load firmware proprietary-non-free/binary-only/no-source-code-available/use-at-your-own-risk/b43/ucode15.fw", comme ça on ne peut pas dire que l'utilisateur n'aura pas été averti.
En effet, grace à Ubuntu, GNU/Linux a été introduit chez plein de gens. Malheureusement Ubuntu s'est dégradé, Unity ayant détourné les ressources de développement dédiées aux correctifs de bogues, tout en restant déstabilisant et instable.
Avec Unity, GNOME 3 et KDE 4 (toujours trop bogué, bien que maintenant assez complet), les vieux utilisateurs commencent à fuir GNU/Linux et les nouveaux viennent moins. J'avais toujours conseillé Fedora et Ubuntu au newbies, maintenant je crois qu'il faut se tourner vers Linux Mint.
L'idée, c'est que GTK 2 et GNOME 2 ont été amélioré et débogué des années et tendent vers quelque chose de vraiment sympa, stable, fonctionnel et accessible, alors que GNOME 3 est incomplet et instable.
Porter à GTK 3. Pouquoi pas? Mais, GTK 3 ne bénéficie pas des des milliers the thèmes graphiques, ni des fonctions d'accessibilité, ni de la maturité de GTK 2.
Ce genre de projet prouve que la liberté de choix du logiciel libre n'est finalement pas complètement illusoire, puisqu'on peut choisir de rester à ce que l'on aimait.
D'un autre côté, le projet manquera probablement vite de mainteneurs, et je ne serais pas étonné que d'ici un an ou deux il soit abandonné, ce qui aura donné un peu plus de temps à GNOME 3 pour devenir à peu près complet et fonctionnel.
Et ils viennent d'où, les paquets Debian ? C'est pas Madame Michu qui les a faits ?!
Non, c'est plutôt des Geek barbus portant un tee-shirt Debian.
Il est même sans doute simple de packager un logiciel bien fait que de configurer
le {son,wifi,pilote graphique} avec bien des distributions/OS quand on a du matos
un chouilla récent ou rare.
C'est pourquoi les non-geeks se contentent d'utiliser Fedora ou Ubuntu qui ont un bon support matériel "out of the box", en renonçant à leur matériel non supporté, ou alors en suivant aveuglément les instructions, sans les comprendre, d'un forum d'aide où un Geek à lunettes leur explique comment ajouter le pilote manquant ou contourner un bogue connu, ou alors demandent à leur voisin/cousin/pôte geek à lunettes de s'occuper de tout puisque de toute façon c'était lui qui leur avait conseillé d'utiliser Linux.
Et la méthode pour faire un paquet pour la plupart des BSD, c'est extrêmement bien documenté.
Mais, pour corriger les erreurs de compilation dues au GNU-ismes employées par le paquetage, il faut quand même un peu connaître le langage C, ce que madame Michu ne maîtrise certainement pas.
Pour avoir plus de paquetages pour NetBSD, il faut plus de Geek à lunettes qui l'utilisent.
J'avais compté uniquement les paquetages marqué "release", mais apparemment, les paquetages "Everything" sont aussi disponibles dans les dépôts par défaut (quoique pas sur les DVD).
En effet, WDDM déplace une partie du code en espace utilisateur. Il faut dire que Microsoft et les développeurs de pilotes vidéo ont tellement d'argent et de ressources de développement qu'ils peuvent finalement se le permettre (au coût de performances quand même un peu diminuées comparées à Windows XP). Comme quoi, le fait d'avoir un design monolithique ne condamne pas définitivement à y rester entièrement...
On peut déplacer quelques éléments en espace utilisateur. De la même manière, on a FUSE pour les systèmes de fichiers sous Linux, même si les pilotes FUSE comme NTFS-3G ont tendance a être très gourmand en ressources CPU.
Sans compter que le problèmes de perf, en grande partie liée aux kernel-switches à chaque interaction entre deux composants du système. Plus il y a de composants, et plus ils interagissent, plus les perfs baissent.
Déjà, sur un Athlon64, une opération d'écriture d'un octet dans un fichier (write(fd, &c, 1)), nécessite environ 350 cycles de CPU sous Linux, dont 160 cycles pour le kernel-switch proprement dit, alors que MINIX a besoin de 9000 cycles de CPU pour la même opération, mais, on peut supposer que le nombre d'interactions entre les composants système augmente avec la complexité du système nécessaire à gérer le matériel et les abstractions utiles dans la vraie vie.
Pour les fichiers, on s'en tire bien en gérant un tampon de mémoire de 8 ou 16 Ko. Maintenant, si on a un protocole entre deux modules (noyau ou applicatifs) qui dépendent beaucoup d'allers-retours de petites quantités données entre les deux modules, ça marche moins bien.
Tu peux aussi balancer les arguments opposés : un micro-noyau, en appliquant des
découpages plus scricts, impose une séparation plus clair des responsabilités,
chaque bloc devient plus facile à maintenir / faire évoluer indépendamment.
Malheureusement, on s'aperçoit vite que les découpages stricts, avec l'évolution du matériel, notamment les cartes graphiques, ne reflètent plus la réalité matérielle.
D'ailleurs, même sous Linux, le sous-système gérant les cartes 3D a récemment subi des modifications majeures (FB, X.org, GLX, DRM, GEM, KMS, Gallium3D, Wayland), parce que c'est dur de faire une bonne abstraction, et notamment avec le modèle DRM+X.org, on a un peu l'idée d'un micro-noyau (X.org composant user-space contenant le code du pilote), mais ça ne marchait pas, au sens où, chaque chipset graphique avait besoin d'une interface DRM différente, bien qu'assez légère comparée à la complexité du code en espace utilisateur. Au final, les choses sous Linux sont en train d'évoluer, avec tout qui passe en espace noyau bien monolithique comme sous Windows, ce qui ne veut pas dire qu'il n'y a pas d'abstraction matérielle, mais elle part du principe que la mémoire est partagée dans le noyau, ce qui permet d'avoir des interfaces beaucoup plus complexes et subtiles pour le même temps de développement.
MINIX et HURD ne prouvent rien. Tout le monde peut faire des interfaces propres, stables et bien définies pour des choses aussi simples que PATA ou Ethernet 10/100 Mbps.
Par contre, dans l'embarqué, où les choses sont beaucoup plus simples, un micro-noyau peut être très intéressant.
[^] # Re: Rien ne m'étonne
Posté par NanoTech . En réponse à la dépêche UEFI Secure Boot et les tablettes/téléphones Windows 8 - conclusion ?. Évalué à 2.
Je ne comprends pas vraiment l'intérêt de bloquer l'installation d'OS alternatifs sur plateforme ARM, étant donné que ça ne concerne que trois geek à lunettes dans leur garage. En fait, les plateformes ARM n'étant pas plug & play, même installer un Android 2.2 sur une machine Android 1.6 est déjà très difficile (pilotes à porter manuellement au nouveau noyau).
Quant aux vendeurs comme HTC qui vendent certaines machines avec Windows Phone 7 ou Android, le dual boot leur sera interdit (s'ils veulent le logo), mais ils peuvent toujours vendre deux modèles... Voire, un modèle Windows 8 certifié et un modèle dual boot sans logo.
Peut-être Microsoft craint-il que ça faciliterait le contournement des DRM.
# Mais sur PC...
Posté par NanoTech . En réponse à la dépêche UEFI Secure Boot et les tablettes/téléphones Windows 8 - conclusion ?. Évalué à 8.
C'est assez étonnant de voir que les nouvelles règles de certification Microsoft font une différence énorme entre x86 et ARM.
1) Sur ARM, le "Secure Boot" ne doit pas pouvoir être désactivé, même par action explicite de l'utilisateur. L'utilisateur ne peut pas non plus ajouter de nouvelles clés.
2) Sur les plateformes non ARM (x86-32 et 64), le "Secure Boot" doit pouvoir être désactivé par action explicite et manuelle de l'utilisateur. L'utilisateur doit aussi avoir la possibilité d'ajouter de nouvelles clés manuellement (via le Custom Mode).
Donc, les utilisateurs PC peuvent se rassurer. Je suppose que Microsoft craint que sans ça, il lui soit impossible d'upgrader à Windows 9 sur les PC Windows 8, même si en théorie, le système de signature le permettrait.
Référence: Page 116 du Windows 8 Hardware Certification Requirements: http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf
# Prendre son temps pour bien faire
Posté par NanoTech . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 5.
On peut se plaindre que des possibilités qui semblent techniquement correctes au premier abord, ont été refusées, mais il faut savoir qu'une fois une API de l'espace utilisateur est définie, la politique du noyau oblige à la conserver définitivement, sauf exception rare (p.e. sysctl(2) pourrait être supprimée). Donc, une erreur de design est conservée définitivement (p.e. dnotify). Mieux vaut donc réfléchir à deux ou quatre fois avant d'implémenter quelque chose.
[^] # Re: capabilities
Posté par NanoTech . En réponse à la dépêche FreeBSD 9.0 est disponible. Évalué à 5.
C'est possible que ta distro ait inclus le patch bien avant l'upstream.
Par exemple, le bogue a été corrigé en 2007 dans Ubuntu et Debian.
Moi, j'en ai souffert parce que Gentoo inclus une version très proche de l'upstream.
De plus, la lenteur se sent plus sur certaines regexp, dont celles incluant le méta-caractère point.
[^] # Re: capabilities
Posté par NanoTech . En réponse à la dépêche FreeBSD 9.0 est disponible. Évalué à 8.
Mike Haertel oublie de préciser que jusqu'en 2010 GNU grep avait des performances atroces en UTF-8, ce qui n'est pas glorieux.
Par exemple grep 2.5.4 met 42 secondes sur un Core 2 Duo 2Ghz à exécuter:
$ time LC_ALL=fr_FR.UTF-8 grep . a.txt > /dev/null
real 0m42.440s
user 0m42.432s
sys 0m0.001s
Où le fichier a.txt est un fichier de 40000 lignes (80 Ko) de 'a'.
Alors qu'en locale C, 8 millisecondes suffisent
$ time LC_ALL=C grep . a.txt > /dev/null
real 0m0.008s
user 0m0.007s
sys 0m0.000s
C'était tellement lent que j'ai découvert le "bogue" sur un traitement d'un fichier contenant des noms de fichiers à déplacer d'un répertoire à un autre, parce que c'était trop lent... Le facteur limitant n'étant pas le déplacement des fichiers mais quelques opérations grep!
Heureusement ça a été corrigé à la 2.7 sortie en septembre 2010.
Le bogue
Références
http://git.savannah.gnu.org/gitweb/?p=grep.git;a=commitdiff;h=7a0ad00f634237b753572378289d76fa8f1c5942
http://rg03.wordpress.com/2009/09/09/gnu-grep-is-slow-on-utf-8/
[^] # Re: Sécurité absolue
Posté par NanoTech . En réponse à la dépêche Le noyau Linux 3.2 est disponible. Évalué à 3.
C'est incorrect. Microsoft oblige "secure boot" a être actif pour donner le logo "Designed for Microsoft Windows 8", mais Windows 8 pourra très bien démarrer sur des machines n'ayant pas de secure boot.
[^] # Re: Utilisation desktop?
Posté par NanoTech . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à 1.
C'est vrai que je n'ai pas eu de chance, mais le fait que RHEL ne soit pas vraiment pensé pour le desktop, le fait qu'en plus j'ai installé des paquetages non officiels n'a pas arrangé les choses, XFCE ne faisant pas partie de RHEL et en plus, CentOS incluant une version qui date d'une époque où XFCE n'était pas très au point.
Le coeur de RHEL/CentOS fonctionne bien, c'est juste qu'à mon avis, il vaut mieux installer une Fedora sur le desktop, parce qu'elle contient des pilotes récents, et que les environnements comme GNOME2 et XFCE4 s'améliorent suffisamment pour que ça vaille la peine de prendre une version récente, plutôt qu'une vieille version en partie déboguée (GNOME2 est en 2.16 sous CentOS 5 et XFCE4 était en 4.4, et maintenant en 4.6).
Non. En fait, maintenant que j'ai réussi à faire une bonne install de CentOS, je la recopie sur des nouveaux PC sans problème, mais, ma conclusion est que les débutants devraient plutôt essayer Fedora, Linux Mint ou Ubuntu.
Ils ne se sont jamais sentis maître de leur ordinateur, mais avec Linux, c'est bien plus facile de scripter leur interface pour qu'elle fasse ce qu'ils souhaitent le plus simplement possible.
[^] # Re: Utilisation desktop?
Posté par NanoTech . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à -1. Dernière modification le 11 décembre 2011 à 19:03.
== Mon expérience avec CentOS sur le desktop ==
Comme j'en avais marre d'utiliser des distributions instables et que je n'aime pas Debian à cause de modifications apportées à certains paquets (notamment exim4), ça fait maintenant un bon moment que j'utilise CentOS 5.x.
Je l'ai installé sur les PC de mes parents qui sont tous deux des newbies en informatique. L'installation elle même demande pas mal de temps, parce qu'il ne supporte pas nativement le matériel moderne. Pour le wifi, il suffit de recompiler un noyau récent, par contre pour gérer les chipsets Intel intégrés GMA 945, il m'a fallu recompiler depuis les sources un X.org récent, Mesa, et pas mal de dépendances, et puis KMS dans le noyau.
J'ai fait l'erreur d'installer XFCE depuis les dépôts extra CentOS, parce que nautilus manquait des fonctions cruciales (p.e. mode liste). Mais les éléments d'XFCE plantent trop souvent (xfdesktop tout le temps, xfce4-panel dans une moindre mesure, le gestionnaire de volume sonore de temps en temps). J'ai finalement amélioré Thunar (qui a de sérieux problèmes de performances à la base) et installé un système hybride GNOME/XFCE, avec le desktop nautilus modifié pour utiliser l'association Thunar sur les dossiers plutôt que nautilus lui-même, avec Xfwm4 (qui n'a jamais planté) comme gestionnaire de fenêtres, et tout le reste en GNOME.
J'ai aussi eu quelques soucis avec le fait qu'ext3 réserve 5% de l'espace disque, par défaut, au root, et ainsi quand il n'y a que 4% d'espace disque restant, les fichiers de config des programmes ont la fâcheuse tendance d'être détruit, ne faisant plus que zéro octets, parce que les programmes ont une mauvaise gestion des erreurs. Mousepad était encore meilleur que ça puisqu'il SEGFAULTAIT bourrin dans ces circonstances.
Moyennant ça, il n'y a pas de problème de stabilité majeur. Les seuls problèmes restant sont gedit qui semble figer en prenant 100% du CPU dans certaines circonstances rares, et fusesmb qui plante souvent (provenant de RPMforge), NFS n'ayant pas une tolérance d'erreur suffisante pour être utilisable. L'édition de partition de musique n'est pas encore au point, avec rosegarden qui plante quand même assez souvent.
Sinon, mplayer, firefox, sylpheed, gthumb, GIMP, xterm et le calendrier d'Evolution marchent très bien. Le bon vieux GDM est très stable, complet, et joli. Le noyau 2.6.32.x que j'ai compilé marche très bien. Les problèmes viennent surtout des paquetages ne provenant pas de Red Hat.
Enfin, il m'a fallu beaucoup de temps pour avoir un système fonctionnel, mais maintenant, ça marche pas mal.
PS: Avec les distro bleeding-edge comme ArchLinux ou Fedora, j'ai beaucoup plus de problèmes, notamment des régressions à toutes les mises à jour.
[^] # Re: netcat
Posté par NanoTech . En réponse à la dépêche Socat, un outil en ligne de commande pour maîtriser vos sockets. Évalué à 1.
socat est extrêmement polyvalent.
Avec tun/tap, c'est très commode pour créer du tunneling IP sur une seule connexion TCP, à travers un pare-feu. En théorie, ça doit même marcher si on a juste un PROXY HTTP à disposition, du moment qu'il supporte l'option CONNECT.
Je n'ai jamais essayé, mais avec SSL:, SSL-LISTEN: et PTY:, on doit pouvoir facilement créer quelque chose d'équivalent à SSH.
En pratique, c'est aussi assez commode pour copier une install Linux sur une nouvelle machine, avec Schily's star qui crée la tarball d'un côté, socat qui copie via une simple connexion TCP nue, et star qui décomprime la tarball de l'autre côté. C'est plus simple qu'un point de montage NFS.
[^] # Re: Petit jugement sur la forme
Posté par NanoTech . En réponse à la dépêche La plateforme française des données publiques est ouverte. Évalué à 5.
Il ne faut pas se plaindre, le format XLS n'est pas parfait, mais est loin d'être aussi fermé que l'on pourrait l'imaginer.
1) Il est documenté par Microsoft, au même titre qu'OOXML.
http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise#Binary_file_formats
2) Il fait partie de l'Open Specification Promise de Microsoft. Ainsi, Microsoft promet qu'il n'attaquera pas en justice sur ses brevets quiconque fournira une implémentation conforme à ses spécifications. C'est la même chose pour OOXML.
Bien sûr, il y a toujours un risque que Microsoft attaque en argumentant que quelque détail n'est pas conforme à sa spécification.
3) Il existe des implémentations fonctionnelles indépendantes.
4) Quand bien même Microsoft attaquerait quelqu'un sur ses brevets, le format d'Excel n'a pas énormément changé depuis Excel 5 en 1993 (il utilisait déjà le Compound Document Format et VBA pour les macros). Les derniers brevets significatifs tomberont donc au plus tard en 2013. Quant aux nouvelles fonctionnalités, on peut certainement les oublier sans perdre d'information.
De plus, les CSV ont une première ligne qui contient des métadonnées. Certes très abrégées, mais en réfléchissant un peu, on peut comprendre ce qu'elles signifient.
Franchement, je ne m'attendais pas à des données aussi exploitables que ça... Ils auraient pû nous filer des scans de mauvaise qualité de documents imprimés.
[^] # Re: Firefox 9
Posté par NanoTech . En réponse à la dépêche Firefox 8 est disponible. Évalué à 1.
À mon avis, un rythme de sortie trop rapide pose des problèmes
1) De stabilité et sécurité: car on rajoute beaucoup de bogues à chaque version et les quelques semaines de développement actif ne suffisent pas à les corriger.
2) D'adaptation en milieu de l'entreprise. Ce n'est pas agréable, toutes les 6 semaines, d'avoir un doute quand à la compatibilité de ses services Web intranet, même si c'est de la faute au service mal codé.
La solution qui me paraît la meilleure est celle adoptée par le noyau Linux. Avoir des versions supportées sur le long terme (1 ou 2 ans), qui contiennent tous les rétro-portages des bogues corrigés dans les versions ultérieures.
Comme ça, on a le meilleur des deux mondes.
[^] # Re: Distrib' idéale pour novices.
Posté par NanoTech . En réponse à la dépêche Linux à la menthe : Linux Mint 12. Évalué à 1.
Le fait que ces programmes soient supportés par Linux Mint implique qu'ils sont testés, contrairement à Debian sid ou même Debian testing, et c'est d'autant plus normal que le bogue n'est pas dans la GLIBC.
Si on a pas besoin de ces programmes, Debian testing est peut-être aussi bon ou meilleur que Linux Mint, mais le fait est que beaucoup d'utilisateurs veulent les installer. Au quel cas, Linux Mint est un choix plus logique.
Le fait que les NVIDIA ou Adobe soient responsables de ça, ne change rien au fait.
Quant aux alternatives libres (nouveau et GNASH), elles ne sont pas encore suffisament prêtes.
[^] # Re: Mais si ni NetBSD ni Plan9 ne sont propres, simples, épurés et diaphanes, qui le sera?
Posté par NanoTech . En réponse au journal Test de NetBSD. Évalué à 1.
KolibriOS ?
[^] # Re: Même erreur que trinity ?
Posté par NanoTech . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 3.
La GLIBC est très rétro-compatible, au niveau source, mais même au niveau binaire depuis la version 2.0. Bon, d'accord, Ulrich Drepper a un peu pété les plombs avec la 2.14, mais ça n'affecte pas GNOME2.
Le noyau est très rétro-compatible. Par exemple, j'ai utilisé un vieil environnement Debian 1.2 avec un noyau 2.6.32.
XLib n'a pas vraiment changé depuis longtemps, par contre, en effet, on risque d'en baver avec Wayland. On sera obligé d'utiliser un serveur X par dessus Wayland.
La détection du matériel n'a pas changée au niveau de l'interface avec le noyau (/sbin/hotplug, sysfs, netlink). C'est juste les programmes comme HAL, udev, udisks, systemd qui font exprès de changer pour le plaisir. Ça pose quelques problèmes de délégation de responsabilité, mais, ce n'est pas très dur de configurer le système pour donner toute la responsabilité, soit à HAL+GNOME2, soit à UDISKS+GNOME3.
Après, c'est sûr que GNOME3, bousille les concepts de rétro-compatibilité et modularité de Linux, ce qui a pour effet de restreindre les choix.
Ce projet est un pari.
S'il échoue, ça voudra dire que la liberté de choix du logiciel libre est totalement illusoire, ce qui me paraît tout à fait possible.
S'il réussit, ça voudra dire que le libre sert quand même à quelque chose.
[^] # Re: Même erreur que trinity ?
Posté par NanoTech . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 2.
C'est ce que j'appelle maintenance minimale. Sans vraiment ajouter de nouvelles fonctions, on corrige les bogues qui "apparaissent". Ça ne paraît pas être une tâche titanesque. Après tout, en 2 jours, j'étais arrivé à faire fonctionner GNOME 1.4 pas trop mal, sur une machine moderne.
[^] # Re: Même erreur que trinity ?
Posté par NanoTech . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 3.
Il n'y a pas grand chose à faire pour l'instant puisque GNOME 2 est déjà stable et complet. Il y a un certain travail de rebranding à faire, mais après, la maintenance est minimale.
[^] # Re: Il n'y aurait pas un mélange FSF / Libre?
Posté par NanoTech . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 3.
Donc, en gros, ce n'est pas en regardant le code, la licence, ou le modèle de développement (communautaire comme Linux, ou dirigé par une seule société comme Qt) que l'on peut savoir si c'est libre ou open source, mais en regardant si les mainteneurs ont de la barbe et portent un Tee-shirt FSF.
[^] # Re: Il n'y aurait pas un mélange FSF / Libre?
Posté par NanoTech . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 5.
Incroyable... Vraiment incroyable!
Franchement, j'ai vraiment cru que c'était une blague quand j'ai vu qu'ils commençaient à parler de changer l'historique du noyau... Mais, l'article ne date pas du premier avril et j'ai suivi les références, et non seulement, le projet Linux-libre semble exister, avec des changelogs comme:
> ARCH_NETX - Hilscher NetX based
> arch/arm/mach-netx/xc.c: disabled non-Free firmware-loading machinery
> arch/arm/mach-netx/xc.c: removed blobs
> drivers/net/netx-eth.c: removed blobs
Mais en plus, la discussion sur le changement de l'historique du noyau a réellement existé:
http://comments.gmane.org/gmane.linux.distributions.gnu-linux-libre/814
Et, le ton ne pas l'air parodique...
S'ils ne veulent pas induire en erreur les gens sur le firmware proprio, ils n'avaient qu'à le mettre dans un dossier proprietary/, comme ça, l'utilisateur verrait dans la sortie du noyau un message du genre "Could not load firmware proprietary-non-free/binary-only/no-source-code-available/use-at-your-own-risk/b43/ucode15.fw", comme ça on ne peut pas dire que l'utilisateur n'aura pas été averti.
Mais bon, l'intégrisme de RMS n'est plus à prouver. Il avait failli faire sortir GNOME du projet GNU quand il avait voulu censurer Planet GNOME en interdisant de mentionner les logiciels propriétaires.
http://www.itwire.com/opinion-and-analysis/open-sauce/29995-gnome-dev-proposes-vote-on-split-from-gnu-project?start=2
[^] # Re: Il n'y aurait pas un mélange FSF / Libre?
Posté par NanoTech . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 2.
En effet, grace à Ubuntu, GNU/Linux a été introduit chez plein de gens. Malheureusement Ubuntu s'est dégradé, Unity ayant détourné les ressources de développement dédiées aux correctifs de bogues, tout en restant déstabilisant et instable.
Avec Unity, GNOME 3 et KDE 4 (toujours trop bogué, bien que maintenant assez complet), les vieux utilisateurs commencent à fuir GNU/Linux et les nouveaux viennent moins. J'avais toujours conseillé Fedora et Ubuntu au newbies, maintenant je crois qu'il faut se tourner vers Linux Mint.
[^] # Re: Même erreur que trinity ?
Posté par NanoTech . En réponse à la dépêche MATE, fourchette de GNOME 2. Évalué à 10.
L'idée, c'est que GTK 2 et GNOME 2 ont été amélioré et débogué des années et tendent vers quelque chose de vraiment sympa, stable, fonctionnel et accessible, alors que GNOME 3 est incomplet et instable.
Porter à GTK 3. Pouquoi pas? Mais, GTK 3 ne bénéficie pas des des milliers the thèmes graphiques, ni des fonctions d'accessibilité, ni de la maturité de GTK 2.
Ce genre de projet prouve que la liberté de choix du logiciel libre n'est finalement pas complètement illusoire, puisqu'on peut choisir de rester à ce que l'on aimait.
D'un autre côté, le projet manquera probablement vite de mainteneurs, et je ne serais pas étonné que d'ici un an ou deux il soit abandonné, ce qui aura donné un peu plus de temps à GNOME 3 pour devenir à peu près complet et fonctionnel.
[^] # Re: Pas assez bien
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 3.
Non, c'est plutôt des Geek barbus portant un tee-shirt Debian.
C'est pourquoi les non-geeks se contentent d'utiliser Fedora ou Ubuntu qui ont un bon support matériel "out of the box", en renonçant à leur matériel non supporté, ou alors en suivant aveuglément les instructions, sans les comprendre, d'un forum d'aide où un Geek à lunettes leur explique comment ajouter le pilote manquant ou contourner un bogue connu, ou alors demandent à leur voisin/cousin/pôte geek à lunettes de s'occuper de tout puisque de toute façon c'était lui qui leur avait conseillé d'utiliser Linux.
Mais, pour corriger les erreurs de compilation dues au GNU-ismes employées par le paquetage, il faut quand même un peu connaître le langage C, ce que madame Michu ne maîtrise certainement pas.
Pour avoir plus de paquetages pour NetBSD, il faut plus de Geek à lunettes qui l'utilisent.
[^] # Re: Pas assez bien
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.
J'avais compté uniquement les paquetages marqué "release", mais apparemment, les paquetages "Everything" sont aussi disponibles dans les dépôts par défaut (quoique pas sur les DVD).
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 1.
En effet, WDDM déplace une partie du code en espace utilisateur. Il faut dire que Microsoft et les développeurs de pilotes vidéo ont tellement d'argent et de ressources de développement qu'ils peuvent finalement se le permettre (au coût de performances quand même un peu diminuées comparées à Windows XP). Comme quoi, le fait d'avoir un design monolithique ne condamne pas définitivement à y rester entièrement...
On peut déplacer quelques éléments en espace utilisateur. De la même manière, on a FUSE pour les systèmes de fichiers sous Linux, même si les pilotes FUSE comme NTFS-3G ont tendance a être très gourmand en ressources CPU.
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 3.
Sans compter que le problèmes de perf, en grande partie liée aux kernel-switches à chaque interaction entre deux composants du système. Plus il y a de composants, et plus ils interagissent, plus les perfs baissent.
Déjà, sur un Athlon64, une opération d'écriture d'un octet dans un fichier (write(fd, &c, 1)), nécessite environ 350 cycles de CPU sous Linux, dont 160 cycles pour le kernel-switch proprement dit, alors que MINIX a besoin de 9000 cycles de CPU pour la même opération, mais, on peut supposer que le nombre d'interactions entre les composants système augmente avec la complexité du système nécessaire à gérer le matériel et les abstractions utiles dans la vraie vie.
Pour les fichiers, on s'en tire bien en gérant un tampon de mémoire de 8 ou 16 Ko. Maintenant, si on a un protocole entre deux modules (noyau ou applicatifs) qui dépendent beaucoup d'allers-retours de petites quantités données entre les deux modules, ça marche moins bien.
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 3.
Malheureusement, on s'aperçoit vite que les découpages stricts, avec l'évolution du matériel, notamment les cartes graphiques, ne reflètent plus la réalité matérielle.
D'ailleurs, même sous Linux, le sous-système gérant les cartes 3D a récemment subi des modifications majeures (FB, X.org, GLX, DRM, GEM, KMS, Gallium3D, Wayland), parce que c'est dur de faire une bonne abstraction, et notamment avec le modèle DRM+X.org, on a un peu l'idée d'un micro-noyau (X.org composant user-space contenant le code du pilote), mais ça ne marchait pas, au sens où, chaque chipset graphique avait besoin d'une interface DRM différente, bien qu'assez légère comparée à la complexité du code en espace utilisateur. Au final, les choses sous Linux sont en train d'évoluer, avec tout qui passe en espace noyau bien monolithique comme sous Windows, ce qui ne veut pas dire qu'il n'y a pas d'abstraction matérielle, mais elle part du principe que la mémoire est partagée dans le noyau, ce qui permet d'avoir des interfaces beaucoup plus complexes et subtiles pour le même temps de développement.
MINIX et HURD ne prouvent rien. Tout le monde peut faire des interfaces propres, stables et bien définies pour des choses aussi simples que PATA ou Ethernet 10/100 Mbps.
Par contre, dans l'embarqué, où les choses sont beaucoup plus simples, un micro-noyau peut être très intéressant.