En gros, pour te brosser un portrait rapide de l'histoire de notre système solaire, il y a plus de 4 milliards d'années un immense nuage de poussières flottant dans l'espace s'est effondré sous sa propre gravité. Au centre du nuage s'est accumulé le plus de poussière et s'est formé le soleil. A la périphérie se sont formé les planètes.
On comprends doc bien que toute la matière se trouvant dans notre système solaire est issue de la même origine : le gros nuage originel. Si on analyse les ratios d'isotopes on retrouve la meme chose.
Ce qui passionne les scientifiques c'est d'essayer de se procurer un peu de matière venant d'ailleurs.
Les poussières de comètes intéressent aussi un peu les scientifiques mais pas beaucoup car ces comètes se sont formées dans notre système solaire et donc la matière qui les compose est bien connue.
En revanche les grains interstellaires n'ont pas (comme leur nom l'indique) leur origine dans notre système solaire. Ce sont des grains venant d'autres régions de la galaxie que notre système solaire. Ils ont été propulsés par les vents spatiaux et ils ont, par un heureux hasard, croisé le chemin du collecteur de Stardust.
Les ratios d'isotopes de ces grains doivent donc êtres différents de ceux des grains de comète et on aura ainsi la preuve qu'ils viennent bien d'ailleurs.
Pratique non ? Au lieu d'avoir à construire un vaisseau hyperspatial comme le faucon millenium pour aller récupérer des échantillons dans d'autres systèmes solaires on se contente de choper les grains flottant dans le vide et hop, on connait la réponse avant même d'avoir à faire le voyage !
>> Entre injecter de l'argent dans les structure publiques anglaises, il choisi de l'utiliser contre le SIDA.
Deux choses. Premièrement on sait qu'il dépense du temps pour des causes. On ne sait rien du tout de ses éventuels dons d'argent. Peut-être qu'il donne, peut-être qu'il ne donne pas. Deuxièmement je me fous de savoir si, à titre privé, il est un généreux mécène. La première des obligations du citoyen c'est de participer à la vie de la cité et cette participation passe par l'acquittement des impôts. C'est ça qui paye les crêches, les infirmières, les enseignants, notre sécurité et nos structures sociales.
Refuser de le faire et se planquer dans le coin le moins imposé d'Europe alors que son groupe gagne par an presque deux fois le budget annuel de Médecins sans frontière c'est répugnant.
Je sais pas si tu te rend compte des chiffres. Médecins sans frontières est une des plus grosses ONG du monde. Ils interviennent dans des dizaines de pays, sauvent des milliers de vie et soignent des dizaines de milliers de personnes. Ils ont dépensé en 2004 la somme de 107 millions d'euros.
U2 a eu 201 millions d'euros de revenus en 2005 !!!
>> tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#
Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ? Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.
Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
ça c'est pour le problème juridique (et encore c'est le point de vue hyper-partial d'Icaza...d'autres personnes sont beaucoup moins sures de l'innocuité de Mono).
Mais il ne faut pas oublier le problème technique : alors que les utilisateurs supplient les devs de faire quelque chose à propos de la lourdeur de Gnome, alors que KDE écrase Gnome sur le plan de la rapidité et de la fluidité, quelle est la réction des devs et quelle est la direction qui est empruntée ? Ajouter une bonne grosse machine virtuelle dans Gnome !!!!!!!!!
Il est évident que cette dépendance introduite ici va être utilisée par pleins de logiciels et qu'il va devenir impossible d'être un gnomiste sans utiliser Mono.
Conclusion : Vivement KDE 4.0. Le seul truc qui me retenait d'avoir une Kubuntu au lieu d'une Ubuntu c'est le fouillis bordélique que constitue KDE. Si ça s'améliore radicalement avec la 4.0 je switcherais sans regret.
Bon ben je vais attendre patiemment le paquet alors. J'en ai vraiment ma claque d'Evolution et de sa lourdeur pachydermique. Je vais peut-être trouver mon bonheur avec Sylpheed-Claws qui sait ?
Je suis sous dapper et je viens de modifier mon source.list pour pointer vers ton dépot mais je n'ai que la version 2.3.3-1 de dispo dans synaptic...c'est normal docteur ?
la vraie nouveauté c'est que c'est intégré et activé par défaut et que c'est simple a utiliser pour tous.
Ce qui fait peur en revanche c'est les risques sur la vie privée. le mec qui delete un fichier et qui vide la corbeille il croit qu'il est est tranquille et là paf ! le undelete de la mort qui tue et le patron peut constater que le mec passe son temps sur linuxfr au lieu de bosser.
c'est dangereux je trouve cette fonction. Il faudra faire gaffe si on veut préserver ses secrets.
Certes c'est dommage d'organiser ce genre de débat foireux....mais en même temps quelle est l'audience de cette chaine et cette emission en particulier ? 0.000pouillème ?
Moi je crois plus que la compréhension des tenants et des aboutissants du problème ne viendra vraiment que quand les gens se cogneront aux barrières mises en place par la loi. Quand ils comprendront que leur musique acheté sur le net est enfermée dans un coffre logiciel et qu'ils se sont fait rouler.
On peut accelerer le processus de prise de conscience en en parlant autour de nous mais fondamentalement il faut attendre que la merde arrive pour que les gens réagissent. C'est con mais c'est comme ça que l'humanité fonctionne...ce qui n'est pas rassurant pour les problèmes qui sont quasi-irréversibles (pétrole, climat...tout ça).
Jani pense ce qu'il veut de la politique israélienne. Tout le monde a le droit d'avoir un avis même extrème.
En revanche ce qui n'est absolument pas tolérable c'est l'amalgame qu'il fait entre la politique d'un état particulier et les juifs en général.
Dans les logs IRC on trouve : "Fuck you jews". Il aurait du se limiter au parfaitement acceptable : "I'm so full of that fucking country".
>> l n'y a qu'une solution propre pour sortir de ce merdier, c'est de demander au président de mettre son veto
uhh ?
Y'a un droit de véto accordé au président dans la constitution française ?
C'est pas parceque Bush met son véto à une loi étatsunienne que c'est la même chose ici.
moi j'estime qu'avoir pris la peine de rédiger ce post hilarant mérite vraiment une rétribution en carambar !
Va falloir que tene passe à la caisse....
Ok j'ai cliqué sur le petit bouton d'acceptation.
Maintenant il faut que je m'y retrouve dans l'interface pour donner son avis. Je vais sans doute faire quelques conneries avant que je comprenne comment ça marche....ça a toujours été ma méthode.
Tu peux détailler un peu les contraintes du fait d'être relecteur ? c'est compatible avec des horaires de boulot ? On est mal vu des autres relecteurs si on n'exerce ce sacerdoce qu'épisodiquement ?
Alors comme ça on profite lâchement du fait que je doive gagner ma croute en allant bosser pour poster dans mon dos une news sur le sommet Linux ?
Bon tant pis, il est hors de question que ce soit uniquement dev/null qui profite de mes petits résumés amoureusement fignolés....
Je poste donc MA news ;-)
Comme l'an dernier le site Linux Weekly News vient de rendre disponible son compte rendu complet du sommet 2006 des développeurs du noyau Linux qui a eu lieu les 17 et 18 juillet à Ottawa.
Cette réunion des principaux developpeurs du noyau est conçue pour permettre de décider les futures orientations technique de Linux et pour présenter les divers travaux en cours.
Comme en 2005 une Photo de groupe est disponible. Elle démontre une augmentation vertigineuse du nombre de femmes dans l'assistance (+100% !).
Journée du 17 juillet
Conférence sur les processeurs
AMD a annoncé l'arrivé de multiprocesseurs ayant des coeurs tournant chacun à des vitesses variables afin de réduite la consommation d'énergie. La firme de processeurs embarqués Freescale désire que le noyau puisse autoriser les opérations cryptographiques asynchroneset supporte les accélérations hardware des fonctions réseau.
Les developpeurs ont également évoqués les risques d'erreurs aléatoires au fur et à mesure que les transistors deviennent plus petits. Le noyau devrait permettre de confiner ces erreurs et de tuer la tâche fautive au lieu de se mettre en panic.
Enfin les fonctions de préchargement de données présentes dans des processeurs deviennent de plus en plus complexes et efficaces et les développeurs réfléchissent au fait que le code noyau s'occupant explicitement de ce préchargement va sans doute devenir moins utile ou même néfaste.
Multi-Conférence sur divers sujets
Cette session a abordé plusieurs mini-sujets de façon rapide : l'inclusion de la pile wifi DeviceStack qui se passe bien mais qui n'est pas encore apte au support des machines SMP; Le support de la qualité de service pour les réseaux sans fil; Les risques légaux en cas de reverse-engineering; les problèmes de fragmentation de mémoire; l'arrivée d'une infrastructure de tests pour la compatibilité ACPI. Le dernier sujet était la consommation de la batterie sous Linux et sous Windows. L'OS de Redmond est capable de tenir 290 minutes alors que Linux stoppe après 240 minutes. Il semble que Windows fasse une lecture en avance (readahead) du disque afin de remplir des tampons et stopper le disque plus vite. Des progrès du noyau sont donc à attendre de ce coté.
Conférence sur la qualité du noyau et le processus de developpement
Andrew Morton a présenté les résultats de son sondage informel auprès des lecteurs de LWN au sujet de la qualité du noyau. Une des plaintes courantes des utilisateurs est que le fait de rapporter un problème sur le bugzilla du noyau ne conduit à aucune réaction des developpeurs. La décision a été prise que les bugs postés sur le bugzilla du kernel seront automatiquements postés sur les kernel mailing-lists correspondantes.
Il a également été pointé le fait que beaucoup de personnes écrivent du code noyau mais que peu d'entre elles se consacrent à la relecture des patches des autres developpeurs. C'est ce qui explique, en partie, la longue attente de Reiser4 dans la branche -mm du fait de l'absence de volontaires pour la relecture et la validation du code.
Conférence sur l'interface ioctl()
Cette conférence très technique s'est concentrée sur la meilleure façon de gérer les interfaces avec le code noyau. L'interface ioctl() est une des techniques pour ajouter des appels système mais elle pose de nombreux problèmes : Les nouveaux appels système introduits tendent à êtres différents pour chaque périphérique; l'API résultante n'est pas revue; l'interface pose des problèmes sur les systèmes mixtes 32/64 bits et enfin la compatibilité avec les outils comme strace est médiocre. Des solutions pour contourner ces problèmes ainsi que des alternatives à ioctl() ont été discutés.
Conférence sur l'ABI du noyau (Application Binary Interface
Cette ABI, qui reste stable de manière à ce que les applications en user-space continuent de fonctionner après un changement de noyau, devient difficile à maintenir avec le temps. Une solution est d'utiliser Sysfs qui fait le lien entre l'ABI vue par les applications et l'API interne du noyau (susceptible de changer en permanence).
Le sujet de la capture des logs de crash du noyau avec le programme HAL (infrastructure d'abstraction du matériel qui est soutenue par Freedesktop et est commune à KDE et Gnome) a été évoqué. Pour améliorer la qualité de HAL une solution serait d'éventuellement l'inclure dans l'arbre des sources du noyau.
Conférence sur la mise en veille (Software suspend)
La controverse a été vive entre les partisans de la solution inlcuse dans le noyau et ceux en faveur d'un programme en espace utilisateur (ce qui permet d'avoir facilement des fonctions de compression et de chiffrage). Aucun consensus clair n'a pu surgir sur l'inclusion ou non des patches suspend2 de Nigel Cunningham. Ce sujet est difficile et Linux reste très en retard par rapport aux OS propriétaires ce qui provoque la grogne des utilisateurs.
Conférence sur la documentation
Cette conférence, co-dirigée par l'éditeur de LWN Jonathan Corbet, a pointé du doigt l'absence de maintenance de la documentation du noyau. On peut trouver dans cette documentation des phrases évoquant le fonctionnement de binaires Java avec le kernel 1.3 (!) ou d'autres détaillant comment faire marcher Linux sur des machines exotiques ayant plus de 16 Mo de RAM (!). Des discussions au sujet des outils de documentation automatique du code sont arrivées à la conclusion qu'il est actuellement trop lent d'utiliser ces techniques.
Les man pages sont également en retard (celle sur le réseau se réfère au noyau 2.2). Une solution serait qu'un mainteneur à plein temps soit payé pour s'occuper de ces man pages. La solution (adoptée par OpenBSD) d'imposer que chaque patch d'un developpeur soit accompagné d'une mise à jour de la man page correspondante a été refusée par Linus Torvalds. Selon lui ce n'est pas une bonne solution du fait que les developpeurs du noyau ne savent pas écrire de la documentation utile (a lot of kernel developers have huge problems communicating with humans).
Journée du 18 juillet
Conférence sur les patches pour le temps réel
L'inclusion du patch implémentant le support du temps réel a été évoqué par les developpeurs présents à cette conférence. Ce patch s'est réduit en taille ces derniers mois (il ne fait plus que 700 Ko) du fait de l'inclusion progressive dans le noyau de diverses fonctions liées au temps réel (futexes robustes, priority inheritance, couche IRQ générique, lock validator).
Les avancées futures concerneront les entrées/sorties temps réel pour les disques et les systèmes de fichiers.
Conférence sur les systèmes embarqués
Un des problème qui a surgit lors du developpement du projet OLPC (One Laptop Per Child) est celui des systèmes de fichiers spécifiques pour les mémoires flash. Le projet JFFFS2 n'a pas été prévu pour des grandes tailles de mémoire flash et il est nécessaire d'avoir du neuf dans ce domaine. En ce qui concerne le temps de boot du kernel (un problème crucial dans le monde de l'embarqué) il semble que les choses empirent et qu'une nouvelle approche doive être envisagée. On pourrait par exemple tester en paralèlle les périphériques lors du boot au lieu de le faire séquentiellement. Néanmoins il existe un risque de conflit de priorité (race condition). Des efforts importants pour réduire la taille du noyau (dans le cas de l'architecture i386) ont permis d'aboutir à des progrès significatifs : élimination des fonctions inline non indispensables; remplacement des sous-systèmes par des technologies plus légères (SLOB Allocator) suffisantes pour l'embarqué.
Conférence sur la sécurité
La conférence sur la sécurité, très attendue du fait de la controverse persistante entre les partisans de SELinux et les tenants d'AppArmor, a examiné ces deux technologies ainsi que la question du maintien ou non de la couche d'abstraction des modules de sécurité (LSM). Les developpeurs de SELinux ont critiqué le fait qu'AppArmor se base sur les noms de chemins (pathname) ce qui, selon eux, est dangereux car non déterministe. La discussion a été âpre mais il semble qu'AppArmor va être autorisé à entrer dans le noyau mainline ce qui assure également la perennité de LSM).
Conférence sur la virtualisation
Xen a été évoqué et il représente la seule solution libre de paravirtualisation disponible actuellement. L'inclusion dans le kernel progresse normalement. Néanmoins les développeurs souhaitent un peu de variété est ils ne veulent pas que Xen soit l'unique candidat. Une solution est de placer des points d'entrée génériques (hooks) dans le noyau afin que différents hyperviseurs puissent s'accrocher au kernel. Il y a toutefois le risque de graver trop tôt l'interface générique dans le marbre avant que les technologies de virtualisation soient vraiment matures.
L'option des containers a été examiné également dans le détail avec tous les problèmes d'espace de noms (namespace) qui apparaissent dans ce cas. Il faut arriver à ce que chaque container aie son espace de noms privé afin d'éviter les interférences. Le risque que les auteurs de rootkits utilisent ces containers a été évoqué sans qu'une solition claire n'émerge.
Conférence sur les procédures automatiques de test
Cette session n'a pas été très conflictuelle car tous le monde souhaite plus de tests afin de détecter les bugs le plus vite possible. Une procédure automatisée a été mise en place pour tester les versions du kernel et pour identifier les patchs fautifs. Les résultats sont disponibles sur cette page.
Conférence sur la couche VFS (Virtual File System)
Le code de la couche VFS n'a pas évolué significativement depuis quelques années ce qui tend à prouver sa maturité. De nouvelles fonctions sont néanmoins à l'horizon comme la possibilité pour les simples utilisateurs de monter les systèmes de fichier; le démontage même si un processus est resté ouvert; le montage à des emplacements différents et avec des attibuts différents ou encore l'idée d'Unionfs qui fusionne plusieurs systèmes de fichiers afin de présenter une vue représentant leur aggrégation.
Conférence sur la scalabilité
Les discussions sur ce sujet ont évoqués les limites qui apparaissent au fur et à mesure que le nombre de processeur du système augmente. Actuellement Linux fonctionne sur des machine NUMA à 1024 noeuds (4096 processeurs) mais le temps de boot est de plus d'une heure du fait qu'un seul processeur est chargé de l'initialisation. Il va être nécessaire de parcelliser cette fonction afin de la répartir sur plusieurs processeurs. De façon générale cette recherche des limites de Linux améliore réguliérement la qualité des algorithmes employés et est très bénéfique pour le kernel.
Conférence sur les problèmes de DMA et IOMMU
Encore une conférence extêmement technique sur la virtualisation des unitées de gestion mémoire des entrées/sorties (I/O memory management units). Cette virtualisation semble poser des problèmes de sécurité. En effet si un périphérique possède des droits d'écriture sur la mémoire (Direct Memory Access) alors il va pouvoir interférer avec tous les autres périphériques du système. Les choses devienent ancore plus compliquées si on tente de partager ces périphériques entre plusieurs machines virtuelles au point que personne ne voit vraiment comment faire cela de manière sécurisé.
Conférence sur le processus de developpement (seconde conférence)
La conférence de fermeture est revenue sur le processus de développement du kernel qui, selon Linus, fonctionne bien. Les points qui restent à améliorer concernent la branche -mm qui accueille des patches pour des durées trop longues; le manque de relecture critique par les pairs des patchs soumis et les relations avec les distributions qui peuvent s'avérer difficiles. Néanmoins Linus pense que les gens sont contents de l'état actuel du noyau (people are happy) ce qui a permis d'écourter la conférence et d'aller écluser plus vite les bières du bar.
>> Peut-être un jour assisterons-nous à un allègement du noyau.
Je doute que ces drivers soient dans ton noyau ou le mien. Ils ne doivent pas êtres compilé par défaut. Et même si ils le sont (improbable) ils ne sont dynamiquement chargés que quand on a besoin d'eux donc ils n'alourdissent pas ton kernel.
Bravo pour cette magnifique news, très complète et très interessante. En fait j'ai bien mieux compris les idées importantes de ce sommet en lisant ce résumé en français que quand j'étais allé déchiffrer péniblement les articles de LWN....Merci donc à herodiade.
Une petite question : On assiste depuis qq années à l'annonce de l'arrivée prochaine du stockage purement sur de la RAM persistante, que ce soit de la NAND perfectionnée ayant des cycles lectures/écritures corrects ou alors la nouvelle MRAM (magnetic RAM).
Je pense que les possesseurs de laptop seront d'accord avec moi pour ne pas regretter leurs disques durs si on obtient en échange une barette de 128 Go de MRAM : un support entièrement silencieux, sans aucune partie en mouvement, très fiable, économe en énergie et doté d'une rapidité sans commune mesure !
Mais est-ce qu'il sera toujours pertinent de s'appuyer sur nos fs classiques avec ce type de stockage état solide ? Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.
Est-ce qu'il ne faudrait pas dès maintenant commencer l'écriture d'un SSFS (Solid State File System) tirant parti au maximum des caratéristiques très alléchantes de ces supports ?
juste quelques questions sur ce disque dur : il est bruyant ? Il chauffe ? Il pompe plus la batterie ? Tu sens une grosse différence au lancement des applis ?
En gros j'envisage moi aussi d'acheter un disque dur en 7200tpm pour remplacer le 5400tpm de mon portable et je me demandais si le jeu en vaut la chandelle (je supporte plus les temps de lancement d'evolution/firefox/OOo)
hum...je me suis peut-être un peu avancé dans mes rêves de gloire ;-)
Je viens de m'apercevoir qu'il ne suffit pas d'ajouter le doctype mais il faut en plus (et surtout) choisir le bon doctype en fonction du code de la page. Evidemment comme ce n'est pas moi qui ai écrit ce code (c'est le soft tellico qui l'a généré) il va falloir que je devine.
Je viens de tester en ajoutant les doctype suivants : html 4.01 strict puis transitionnal; xhtml 1.0 strict puis transitionnal; xhtml 1.1
J'ai à chaque fois des erreurs ce qui signifie sans doute que le code que tellico génère n'est pas conforme....ça se présente mal pour la gloire !
[^] # Re: Question
Posté par patrick_g (site web personnel) . En réponse au journal Stardust@home. Évalué à 7.
En gros, pour te brosser un portrait rapide de l'histoire de notre système solaire, il y a plus de 4 milliards d'années un immense nuage de poussières flottant dans l'espace s'est effondré sous sa propre gravité. Au centre du nuage s'est accumulé le plus de poussière et s'est formé le soleil. A la périphérie se sont formé les planètes.
On comprends doc bien que toute la matière se trouvant dans notre système solaire est issue de la même origine : le gros nuage originel. Si on analyse les ratios d'isotopes on retrouve la meme chose.
Ce qui passionne les scientifiques c'est d'essayer de se procurer un peu de matière venant d'ailleurs.
Les poussières de comètes intéressent aussi un peu les scientifiques mais pas beaucoup car ces comètes se sont formées dans notre système solaire et donc la matière qui les compose est bien connue.
En revanche les grains interstellaires n'ont pas (comme leur nom l'indique) leur origine dans notre système solaire. Ce sont des grains venant d'autres régions de la galaxie que notre système solaire. Ils ont été propulsés par les vents spatiaux et ils ont, par un heureux hasard, croisé le chemin du collecteur de Stardust.
Les ratios d'isotopes de ces grains doivent donc êtres différents de ceux des grains de comète et on aura ainsi la preuve qu'ils viennent bien d'ailleurs.
Pratique non ? Au lieu d'avoir à construire un vaisseau hyperspatial comme le faucon millenium pour aller récupérer des échantillons dans d'autres systèmes solaires on se contente de choper les grains flottant dans le vide et hop, on connait la réponse avant même d'avoir à faire le voyage !
Lien wikipedia qui pointe vers plein d'autres : http://en.wikipedia.org/wiki/Stardust_%28spacecraft%29
[^] # Re: Bof
Posté par patrick_g (site web personnel) . En réponse au journal Bono et l'argent : La colère du samedi. Évalué à 10.
Deux choses. Premièrement on sait qu'il dépense du temps pour des causes. On ne sait rien du tout de ses éventuels dons d'argent. Peut-être qu'il donne, peut-être qu'il ne donne pas. Deuxièmement je me fous de savoir si, à titre privé, il est un généreux mécène. La première des obligations du citoyen c'est de participer à la vie de la cité et cette participation passe par l'acquittement des impôts. C'est ça qui paye les crêches, les infirmières, les enseignants, notre sécurité et nos structures sociales.
Refuser de le faire et se planquer dans le coin le moins imposé d'Europe alors que son groupe gagne par an presque deux fois le budget annuel de Médecins sans frontière c'est répugnant.
Je sais pas si tu te rend compte des chiffres. Médecins sans frontières est une des plus grosses ONG du monde. Ils interviennent dans des dizaines de pays, sauvent des milliers de vie et soignent des dizaines de milliers de personnes. Ils ont dépensé en 2004 la somme de 107 millions d'euros.
U2 a eu 201 millions d'euros de revenus en 2005 !!!
[^] # Re: Un classement qui sert à rien
Posté par patrick_g (site web personnel) . En réponse au journal Réactivité des distributions en terme de sécurité. Évalué à 5.
Des trolls du vendredi ?
[^] # Re: Excellent journal
Posté par patrick_g (site web personnel) . En réponse au journal Et Reiser4 nous apprend comment fonctionne la communauté. Évalué à 4.
Ah bon ?
J'avais tenté le coup d'une news d'analyse y'a deux ans et c'était passé donc tu peux tenter le coup.
cf : http://linuxfr.org/2004/07/23/16876.html
[^] # Re: Le passage Mono dans le document
Posté par patrick_g (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 10.
Oui et j'ai viré Beagle vite fait.
>> tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#
Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ? Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.
Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
[^] # Re: Le passage Mono dans le document
Posté par patrick_g (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 10.
Mais il ne faut pas oublier le problème technique : alors que les utilisateurs supplient les devs de faire quelque chose à propos de la lourdeur de Gnome, alors que KDE écrase Gnome sur le plan de la rapidité et de la fluidité, quelle est la réction des devs et quelle est la direction qui est empruntée ? Ajouter une bonne grosse machine virtuelle dans Gnome !!!!!!!!!
Il est évident que cette dépendance introduite ici va être utilisée par pleins de logiciels et qu'il va devenir impossible d'être un gnomiste sans utiliser Mono.
Conclusion : Vivement KDE 4.0. Le seul truc qui me retenait d'avoir une Kubuntu au lieu d'une Ubuntu c'est le fouillis bordélique que constitue KDE. Si ça s'améliore radicalement avec la 4.0 je switcherais sans regret.
[^] # Re: pour ou contre ?
Posté par patrick_g (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 5.
http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf
C'est long mais ça vaut vraiment le coup de le lire.
# maxi-Troll
Posté par patrick_g (site web personnel) . En réponse au journal Mono et Gnome. Évalué à -1.
[^] # Re: version dispo ?
Posté par patrick_g (site web personnel) . En réponse au journal Sylpheed-Claws 2.4.0 est sorti!. Évalué à 3.
# version dispo ?
Posté par patrick_g (site web personnel) . En réponse au journal Sylpheed-Claws 2.4.0 est sorti!. Évalué à 3.
[^] # Re: Mais quelle nouveauté !!!
Posté par patrick_g (site web personnel) . En réponse au journal J'en ai rêvé, Microsoft l'a fait !. Évalué à 9.
Ce qui fait peur en revanche c'est les risques sur la vie privée. le mec qui delete un fichier et qui vide la corbeille il croit qu'il est est tranquille et là paf ! le undelete de la mort qui tue et le patron peut constater que le mec passe son temps sur linuxfr au lieu de bosser.
c'est dangereux je trouve cette fonction. Il faudra faire gaffe si on veut préserver ses secrets.
# audimat
Posté par patrick_g (site web personnel) . En réponse au journal DAVDSI : JJ Beneix à côté de la plaque. Évalué à 5.
Moi je crois plus que la compréhension des tenants et des aboutissants du problème ne viendra vraiment que quand les gens se cogneront aux barrières mises en place par la loi. Quand ils comprendront que leur musique acheté sur le net est enfermée dans un coffre logiciel et qu'ils se sont fait rouler.
On peut accelerer le processus de prise de conscience en en parlant autour de nous mais fondamentalement il faut attendre que la merde arrive pour que les gens réagissent. C'est con mais c'est comme ça que l'humanité fonctionne...ce qui n'est pas rassurant pour les problèmes qui sont quasi-irréversibles (pétrole, climat...tout ça).
[^] # Re: liens
Posté par patrick_g (site web personnel) . En réponse au journal PHP is dying. Évalué à 10.
En revanche ce qui n'est absolument pas tolérable c'est l'amalgame qu'il fait entre la politique d'un état particulier et les juifs en général.
Dans les logs IRC on trouve : "Fuck you jews". Il aurait du se limiter au parfaitement acceptable : "I'm so full of that fucking country".
[^] # Re: Il est en panique :)
Posté par patrick_g (site web personnel) . En réponse au journal RDDV: Lettre ouverte aux internautes. Évalué à 1.
uhh ?
Y'a un droit de véto accordé au président dans la constitution française ?
C'est pas parceque Bush met son véto à une loi étatsunienne que c'est la même chose ici.
[^] # Re: Les 17 trolls
Posté par patrick_g (site web personnel) . En réponse au journal Les développeurs Open Source aident les pirates.... Évalué à 8.
Va falloir que tene passe à la caisse....
[^] # Re: Sommet Linux 2006
Posté par patrick_g (site web personnel) . En réponse à la dépêche Kernel Summit et Linux Symposium. Évalué à 2.
Maintenant il faut que je m'y retrouve dans l'interface pour donner son avis. Je vais sans doute faire quelques conneries avant que je comprenne comment ça marche....ça a toujours été ma méthode.
[^] # Re: Sommet Linux 2006
Posté par patrick_g (site web personnel) . En réponse à la dépêche Kernel Summit et Linux Symposium. Évalué à 1.
# Sommet Linux 2006
Posté par patrick_g (site web personnel) . En réponse à la dépêche Kernel Summit et Linux Symposium. Évalué à 10.
Alors comme ça on profite lâchement du fait que je doive gagner ma croute en allant bosser pour poster dans mon dos une news sur le sommet Linux ?
Bon tant pis, il est hors de question que ce soit uniquement dev/null qui profite de mes petits résumés amoureusement fignolés....
Je poste donc MA news ;-)
Comme l'an dernier le site Linux Weekly News vient de rendre disponible son compte rendu complet du sommet 2006 des développeurs du noyau Linux qui a eu lieu les 17 et 18 juillet à Ottawa.
Cette réunion des principaux developpeurs du noyau est conçue pour permettre de décider les futures orientations technique de Linux et pour présenter les divers travaux en cours.
Comme en 2005 une Photo de groupe est disponible. Elle démontre une augmentation vertigineuse du nombre de femmes dans l'assistance (+100% !).
Journée du 17 juillet
Conférence sur les processeurs
AMD a annoncé l'arrivé de multiprocesseurs ayant des coeurs tournant chacun à des vitesses variables afin de réduite la consommation d'énergie. La firme de processeurs embarqués Freescale désire que le noyau puisse autoriser les opérations cryptographiques asynchroneset supporte les accélérations hardware des fonctions réseau.
Les developpeurs ont également évoqués les risques d'erreurs aléatoires au fur et à mesure que les transistors deviennent plus petits. Le noyau devrait permettre de confiner ces erreurs et de tuer la tâche fautive au lieu de se mettre en panic.
Enfin les fonctions de préchargement de données présentes dans des processeurs deviennent de plus en plus complexes et efficaces et les développeurs réfléchissent au fait que le code noyau s'occupant explicitement de ce préchargement va sans doute devenir moins utile ou même néfaste.
Multi-Conférence sur divers sujets
Cette session a abordé plusieurs mini-sujets de façon rapide : l'inclusion de la pile wifi DeviceStack qui se passe bien mais qui n'est pas encore apte au support des machines SMP; Le support de la qualité de service pour les réseaux sans fil; Les risques légaux en cas de reverse-engineering; les problèmes de fragmentation de mémoire; l'arrivée d'une infrastructure de tests pour la compatibilité ACPI. Le dernier sujet était la consommation de la batterie sous Linux et sous Windows. L'OS de Redmond est capable de tenir 290 minutes alors que Linux stoppe après 240 minutes. Il semble que Windows fasse une lecture en avance (readahead) du disque afin de remplir des tampons et stopper le disque plus vite. Des progrès du noyau sont donc à attendre de ce coté.
Conférence sur la qualité du noyau et le processus de developpement
Andrew Morton a présenté les résultats de son sondage informel auprès des lecteurs de LWN au sujet de la qualité du noyau. Une des plaintes courantes des utilisateurs est que le fait de rapporter un problème sur le bugzilla du noyau ne conduit à aucune réaction des developpeurs. La décision a été prise que les bugs postés sur le bugzilla du kernel seront automatiquements postés sur les kernel mailing-lists correspondantes.
Il a également été pointé le fait que beaucoup de personnes écrivent du code noyau mais que peu d'entre elles se consacrent à la relecture des patches des autres developpeurs. C'est ce qui explique, en partie, la longue attente de Reiser4 dans la branche -mm du fait de l'absence de volontaires pour la relecture et la validation du code.
Conférence sur l'interface ioctl()
Cette conférence très technique s'est concentrée sur la meilleure façon de gérer les interfaces avec le code noyau. L'interface ioctl() est une des techniques pour ajouter des appels système mais elle pose de nombreux problèmes : Les nouveaux appels système introduits tendent à êtres différents pour chaque périphérique; l'API résultante n'est pas revue; l'interface pose des problèmes sur les systèmes mixtes 32/64 bits et enfin la compatibilité avec les outils comme strace est médiocre. Des solutions pour contourner ces problèmes ainsi que des alternatives à ioctl() ont été discutés.
Conférence sur l'ABI du noyau (Application Binary Interface
Cette ABI, qui reste stable de manière à ce que les applications en user-space continuent de fonctionner après un changement de noyau, devient difficile à maintenir avec le temps. Une solution est d'utiliser Sysfs qui fait le lien entre l'ABI vue par les applications et l'API interne du noyau (susceptible de changer en permanence).
Le sujet de la capture des logs de crash du noyau avec le programme HAL (infrastructure d'abstraction du matériel qui est soutenue par Freedesktop et est commune à KDE et Gnome) a été évoqué. Pour améliorer la qualité de HAL une solution serait d'éventuellement l'inclure dans l'arbre des sources du noyau.
Conférence sur la mise en veille (Software suspend)
La controverse a été vive entre les partisans de la solution inlcuse dans le noyau et ceux en faveur d'un programme en espace utilisateur (ce qui permet d'avoir facilement des fonctions de compression et de chiffrage). Aucun consensus clair n'a pu surgir sur l'inclusion ou non des patches suspend2 de Nigel Cunningham. Ce sujet est difficile et Linux reste très en retard par rapport aux OS propriétaires ce qui provoque la grogne des utilisateurs.
Conférence sur la documentation
Cette conférence, co-dirigée par l'éditeur de LWN Jonathan Corbet, a pointé du doigt l'absence de maintenance de la documentation du noyau. On peut trouver dans cette documentation des phrases évoquant le fonctionnement de binaires Java avec le kernel 1.3 (!) ou d'autres détaillant comment faire marcher Linux sur des machines exotiques ayant plus de 16 Mo de RAM (!). Des discussions au sujet des outils de documentation automatique du code sont arrivées à la conclusion qu'il est actuellement trop lent d'utiliser ces techniques.
Les man pages sont également en retard (celle sur le réseau se réfère au noyau 2.2). Une solution serait qu'un mainteneur à plein temps soit payé pour s'occuper de ces man pages. La solution (adoptée par OpenBSD) d'imposer que chaque patch d'un developpeur soit accompagné d'une mise à jour de la man page correspondante a été refusée par Linus Torvalds. Selon lui ce n'est pas une bonne solution du fait que les developpeurs du noyau ne savent pas écrire de la documentation utile (a lot of kernel developers have huge problems communicating with humans).
Journée du 18 juillet
Conférence sur les patches pour le temps réel
L'inclusion du patch implémentant le support du temps réel a été évoqué par les developpeurs présents à cette conférence. Ce patch s'est réduit en taille ces derniers mois (il ne fait plus que 700 Ko) du fait de l'inclusion progressive dans le noyau de diverses fonctions liées au temps réel (futexes robustes, priority inheritance, couche IRQ générique, lock validator).
Les avancées futures concerneront les entrées/sorties temps réel pour les disques et les systèmes de fichiers.
Conférence sur les systèmes embarqués
Un des problème qui a surgit lors du developpement du projet OLPC (One Laptop Per Child) est celui des systèmes de fichiers spécifiques pour les mémoires flash. Le projet JFFFS2 n'a pas été prévu pour des grandes tailles de mémoire flash et il est nécessaire d'avoir du neuf dans ce domaine. En ce qui concerne le temps de boot du kernel (un problème crucial dans le monde de l'embarqué) il semble que les choses empirent et qu'une nouvelle approche doive être envisagée. On pourrait par exemple tester en paralèlle les périphériques lors du boot au lieu de le faire séquentiellement. Néanmoins il existe un risque de conflit de priorité (race condition). Des efforts importants pour réduire la taille du noyau (dans le cas de l'architecture i386) ont permis d'aboutir à des progrès significatifs : élimination des fonctions inline non indispensables; remplacement des sous-systèmes par des technologies plus légères (SLOB Allocator) suffisantes pour l'embarqué.
Conférence sur la sécurité
La conférence sur la sécurité, très attendue du fait de la controverse persistante entre les partisans de SELinux et les tenants d'AppArmor, a examiné ces deux technologies ainsi que la question du maintien ou non de la couche d'abstraction des modules de sécurité (LSM). Les developpeurs de SELinux ont critiqué le fait qu'AppArmor se base sur les noms de chemins (pathname) ce qui, selon eux, est dangereux car non déterministe. La discussion a été âpre mais il semble qu'AppArmor va être autorisé à entrer dans le noyau mainline ce qui assure également la perennité de LSM).
Conférence sur la virtualisation
Xen a été évoqué et il représente la seule solution libre de paravirtualisation disponible actuellement. L'inclusion dans le kernel progresse normalement. Néanmoins les développeurs souhaitent un peu de variété est ils ne veulent pas que Xen soit l'unique candidat. Une solution est de placer des points d'entrée génériques (hooks) dans le noyau afin que différents hyperviseurs puissent s'accrocher au kernel. Il y a toutefois le risque de graver trop tôt l'interface générique dans le marbre avant que les technologies de virtualisation soient vraiment matures.
L'option des containers a été examiné également dans le détail avec tous les problèmes d'espace de noms (namespace) qui apparaissent dans ce cas. Il faut arriver à ce que chaque container aie son espace de noms privé afin d'éviter les interférences. Le risque que les auteurs de rootkits utilisent ces containers a été évoqué sans qu'une solition claire n'émerge.
Conférence sur les procédures automatiques de test
Cette session n'a pas été très conflictuelle car tous le monde souhaite plus de tests afin de détecter les bugs le plus vite possible. Une procédure automatisée a été mise en place pour tester les versions du kernel et pour identifier les patchs fautifs. Les résultats sont disponibles sur cette page.
Conférence sur la couche VFS (Virtual File System)
Le code de la couche VFS n'a pas évolué significativement depuis quelques années ce qui tend à prouver sa maturité. De nouvelles fonctions sont néanmoins à l'horizon comme la possibilité pour les simples utilisateurs de monter les systèmes de fichier; le démontage même si un processus est resté ouvert; le montage à des emplacements différents et avec des attibuts différents ou encore l'idée d'Unionfs qui fusionne plusieurs systèmes de fichiers afin de présenter une vue représentant leur aggrégation.
Conférence sur la scalabilité
Les discussions sur ce sujet ont évoqués les limites qui apparaissent au fur et à mesure que le nombre de processeur du système augmente. Actuellement Linux fonctionne sur des machine NUMA à 1024 noeuds (4096 processeurs) mais le temps de boot est de plus d'une heure du fait qu'un seul processeur est chargé de l'initialisation. Il va être nécessaire de parcelliser cette fonction afin de la répartir sur plusieurs processeurs. De façon générale cette recherche des limites de Linux améliore réguliérement la qualité des algorithmes employés et est très bénéfique pour le kernel.
Conférence sur les problèmes de DMA et IOMMU
Encore une conférence extêmement technique sur la virtualisation des unitées de gestion mémoire des entrées/sorties (I/O memory management units). Cette virtualisation semble poser des problèmes de sécurité. En effet si un périphérique possède des droits d'écriture sur la mémoire (Direct Memory Access) alors il va pouvoir interférer avec tous les autres périphériques du système. Les choses devienent ancore plus compliquées si on tente de partager ces périphériques entre plusieurs machines virtuelles au point que personne ne voit vraiment comment faire cela de manière sécurisé.
Conférence sur le processus de developpement (seconde conférence)
La conférence de fermeture est revenue sur le processus de développement du kernel qui, selon Linus, fonctionne bien. Les points qui restent à améliorer concernent la branche -mm qui accueille des patches pour des durées trop longues; le manque de relecture critique par les pairs des patchs soumis et les relations avec les distributions qui peuvent s'avérer difficiles. Néanmoins Linus pense que les gens sont contents de l'état actuel du noyau (people are happy) ce qui a permis d'écourter la conférence et d'aller écluser plus vite les bières du bar.
[^] # Re: Juste un point
Posté par patrick_g (site web personnel) . En réponse au journal Les mythes et les mensonges au sujet de Linux. Évalué à 10.
Je doute que ces drivers soient dans ton noyau ou le mien. Ils ne doivent pas êtres compilé par défaut. Et même si ils le sont (improbable) ils ne sont dynamiquement chargés que quand on a besoin d'eux donc ils n'alourdissent pas ton kernel.
[^] # Re: Euh....
Posté par patrick_g (site web personnel) . En réponse au journal Les mythes et les mensonges au sujet de Linux. Évalué à 8.
Les phrases sont juste des traductions de quelques commentaires inter-slides présents sur le site de GKH.
# Bravo !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 10.
Une petite question : On assiste depuis qq années à l'annonce de l'arrivée prochaine du stockage purement sur de la RAM persistante, que ce soit de la NAND perfectionnée ayant des cycles lectures/écritures corrects ou alors la nouvelle MRAM (magnetic RAM).
Je pense que les possesseurs de laptop seront d'accord avec moi pour ne pas regretter leurs disques durs si on obtient en échange une barette de 128 Go de MRAM : un support entièrement silencieux, sans aucune partie en mouvement, très fiable, économe en énergie et doté d'une rapidité sans commune mesure !
Mais est-ce qu'il sera toujours pertinent de s'appuyer sur nos fs classiques avec ce type de stockage état solide ? Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.
Est-ce qu'il ne faudrait pas dès maintenant commencer l'écriture d'un SSFS (Solid State File System) tirant parti au maximum des caratéristiques très alléchantes de ces supports ?
[^] # Re: OS par défaut
Posté par patrick_g (site web personnel) . En réponse au journal Asus V6J X001P et Ubuntu. Évalué à 2.
En gros j'envisage moi aussi d'acheter un disque dur en 7200tpm pour remplacer le 5400tpm de mon portable et je me demandais si le jeu en vaut la chandelle (je supporte plus les temps de lancement d'evolution/firefox/OOo)
[^] # Re: Les nouveautés en images
Posté par patrick_g (site web personnel) . En réponse au journal Firefox 2.0 beta 1. Évalué à 6.
Ah oui ?
Pourtant je viens d'ouvrir sur launchpad un bug pour signaler un freeze de Gedit 100% reproductible :
https://launchpad.net/bugs/52975
[^] # Re: 4e dimension
Posté par patrick_g (site web personnel) . En réponse au journal Statistiques des navigateurs OneStat juillet 2006. Évalué à 2.
[^] # Re: 4e dimension
Posté par patrick_g (site web personnel) . En réponse au journal Statistiques des navigateurs OneStat juillet 2006. Évalué à 2.
Je viens de m'apercevoir qu'il ne suffit pas d'ajouter le doctype mais il faut en plus (et surtout) choisir le bon doctype en fonction du code de la page. Evidemment comme ce n'est pas moi qui ai écrit ce code (c'est le soft tellico qui l'a généré) il va falloir que je devine.
Je viens de tester en ajoutant les doctype suivants : html 4.01 strict puis transitionnal; xhtml 1.0 strict puis transitionnal; xhtml 1.1
J'ai à chaque fois des erreurs ce qui signifie sans doute que le code que tellico génère n'est pas conforme....ça se présente mal pour la gloire !