Rien n'est parfait, mais recherche de trajets ultra-rapide et généralement optimale avec 3 correspondances (jamais été au-delà), suivi du statut des trains et des quais de gares en temps réel, le tout sur sur nationalrail.co.uk et des applications Android/iOS/? utilisant une API officiellement supportée.
Très utile vu que tout part en vrille dès qu'il neige, diront les mauvaises langues dont je fais partie.
Mais j'insiste sur mon propos : le droit étasunien s'applique même aux services que Google me fournit en France (ou dans mon cas, en UK), puisque Google, l'entreprise américaine, les y exporte.
Pourquoi regrettable? A mon avis, si tu n'as rien à te reprocher, tu pourras attaquer Google pour abus de position dominante ou terme juridique, et donc ils vont bien faire attention à ne virer que des trucs illégaux. Et tant que des trucs manifestement illégaux sont virés, je ne vois rien de gênant, c'est pareil pour les hébergeurs avec la LCEN et ça n'a pas eu les conséquences "le web va mourir" ou "la censure des hébergeurs web" qu'avaient prédit certains, juste que des sites manifestement illégaux sont supprimés d'office (et que si on te supprime un site illégal, un bon coup de procès au mec et il s'en prendra plein la gueule, l'abus est aussi puni).
Une grosse nuance : ce qui est illégal pour Google ne l'est pas forcément pour moi.
Je suis très content d'être en Europe. Le droit étasunien s'applique à Google.
Je ne dis pas que NetBSD n'est pas adapté. Je dis juste que le choix de nombre de structures, à tord ou à raison, est de s'orienter vers ces solutions clef en main.
totof2000, d'expérience, oui tout cela est relativement simple, oui c'est automatisable.
Si en tant que salarié, tu as la possibilité de faire changer d'avis ton management pour des solutions moins clefs-en-main mais plus adaptées aux besoins et/ou moins coûteuses à long terme, estime-toi heureux. Mais si tu penses que ton successeur saura rebuilder le système le base de NetBSD sans procédures, estime-toi inconscient !
En pratique, nombre de personnes, y compris des administrateurs système, appellent leur support plutôt que de faire "man rpm". Et c'est finalement préférable à ceux qui exécutent "rpm -e --force glibc" et s'attendent à pouvoir rebooter.
Parce que Arial ou Helvetica ne sont pas vraiment agréables pour la lecture de longs textes sur du papier.
Helvetica était conçue comme une alternative à Akzidenz-Grotesk, principalement pour la signalétique, et Arial est un quasi-clone dérivé entre autres pour en améliorer le rendu sur écrans (bien qu'il s'agisse d'une police d'impression aussi).
Ces polices rendent parfaitement... Jusqu'à ce que je doive me les taper plus de 5 minutes.
Pour ces longs textes, je pense rien ne vaut une police à apattement, comme Times New Roman par exemple (loin d'être ma préférée).
Je pense que mon point de vue est relativement consensuel dans le monde de la typo, mais je n'aurai pas la prétention de le connaître assez pour l'affirmer.
Généralement, ce genre de contraintes tient plus à la métrique de la police qu'autre chose. Souvent on voit cette contrainte accompagnée de marges et/ou métrique d'interlignes.
Red Hat a fait en sorte qu'une police à la métrique strictement identique soit disponible sous une licence Open Source.
Ta copine peut utiliser Liberation Serif, éventuellement en incluant une note indiquant qu'il s'agit d'un équivalent métrique librement utilisable.
Comme pour beaucoup de distributions, avoir un gestionnaire de paquets fait partie des attentes des usagers. Un NetBSD minimal n'en a pas. Ce n'est pas une critique.
Oui, ton serveur NFS tournera. Mais les compétences nécessaires pour prendre en charge les alertes de sécurité (j'imagine que tu prends des vacances, par exemple) n'incluent pas savoir compiler et tester un noyau NetBSD...
Donc même pour un "simple" serveur NFS, si tu n'as pas une armée de barbus à disposition (figure of speech), NetBSD ne remplira pas forcément tes attentes professionnelles.
Une vaste majorité des grandes entreprises, et un nombre conséquent d'universités, hôpitaux, administrations, utilisent des NAS/SAN à la NetApp en partie pour simplifier l'administration...
"It just works", ce n'est pas seulement pour les étudiants trendy. D'aucuns diront nivellement par le bas.
[http://fr.wiktionary.org/wiki/base] « 11. (Figuré) Ce qui est le principe, la donnée fondamentale d’une chose ou ce sur quoi elle repose. »
On a pas la même perception de base.
L'outil le propose, oui. C'est possible, oui. Ça signifie dans la plupart des cas te tirer dans le pied, oui.
À ma connaissance, dans l'histoire d'Unix et Linux, on empêche peu ou pas l'administrateur de faire n'importe quoi.
Pouvoir désactiver le groupe de base peut avoir du sens. Par exemple, tu sélectionnes ton set de paquets essentiels via d'autres biais (par exemple kickstart comme indiqué ailleurs, métapaquet, etc.)
Encore une fois, cette citation est celle d'un membre de la communauté, et certainement pas de l'un des organes de Fedora à même de prendre part à une décision qui sera d'ampleur historique, entre autres FESCo et releng.
On est bien au-delà du genre de changements introduits par systemd par exemple, où même l'auteur principal, énorme contributeur Fedora et Gnome, s'est vu débouler au rang de grincheux lors du freeze F14. Sa solution était déjà bien plus aboutie que je n'ose l'espérer pour Wayland dans un an.
Par ailleurs il dit simplement que ça a de bonnes chances d'arriver un jour ou l'autre, sur la base de considérations purement techniques, que j'espère personnellement fondées puisque ça a l'air génial d'ici (sans connaître l'état de l'art ou les discussions entre gens plus intelligents que moi).
Le commentateur n'affiche lui-même aucun projet autre qu'un simple packaging dès que possible, pour faire joujou. Je compte bien faire partie des joueurs :)
> Il y a quelques jours on apprenait qu'Ubuntu allait migrer progressivement vers un nouveau système d'affichage en remplacement de X nommé Wayland.
> Ces derniers jours on apprend également que Fedora va faire de même .
On apprend que des membres du projet vont l'empaqueter pour qu'on puisse jouer avec.
Il n'est pas vraiment question d'une migration pour le moment.
Ça me parait très différent de l'annonce de Shuttleworth...
L'équipe semble largement compétente, après une lecture du draft et de l'implémentation sous Linux, pour le coup je ne serais pas un early adopter, je vais être mauvais joueur et attendre que ça se répande un peu.
La couche cryptographique a l'air performante mais représente tout de même un certain surcoût... Surtout que netfilter jongle avec un processus userspace, bonjour les changements de contexte.
Le risque de déni de service me semble grandement augmenté, et à moins de passer longtemps à examiner les possibilités pour le réduire correctement et suffisamment, j'aurais peur pour mes systèmes.
Pour finir, j'aimerais des benchmarks sur l'impact en débit et latence sur divers types de connexions et flux. Et non, je n'en ai pas assez envie pour les faire moi-même.
Ça fait bizarre de revenir après 2 semaines chargées et de tomber sur un -9 :)
Olivier, non, pas "faux". Je répondais au commentaire parent, "Si on a du vmware il suffit de prendre le répertoire de la vm qui contient tout ce qu'il faut. Avec VBox, il faut s'amuser à prendre le disque d'un côté, la conf d'un autre, etc.". Je sais bien que VirtualBox gère les raw devices, et j'en suis très content.
Kerro, je critiquais l'utilisation de fichiers classiques (regular files) sur système de fichiers à la ext3. Utiliser des raw devices ou des logical volumes me convient très bien, ils sont pourtant exposés comme des fichiers spéciaux dans /dev.
Antoine, ce n'est pas particulièrement un problème de partitionnement... Tu as le temps perdu en espace noyau, la prédictibilité limitée de la plupart des systèmes de fichiers pour de très nombreux accès aléatoires sur de gros fichiers (parce que c'est un aspect généralement secondaire à la conception) causant des phases de "lag" qui peuvent être sensibles y compris sur de la prod serveur extranet.
Je passe sur les nombreuses erreurs de déploiement à plus fort impact, comme un journaling des données sur le système de fichiers hôte, ou de l'allocation dynamique pour l'image du disque... Là, les pertes ne sont vraiment pas dures à mesure.
Pour ceux qui théorisent que plus de couches peut vouloir dire meilleures perfs... J'aimerai voir des benchs.
Le cas le plus rigolo, c'est Xen qui utilise des loop devices quand le stockage est dans des "regular files" (traduction ?). J'ai vu des retours d'administrateurs rencontrant des problèmes de locking dans le noyau : au-dessus de 3 ou 4 machines virtuelles qui font beaucoup d'I/Os, les performances chutent de manière phénoménale. Apparemment un problème de design connu.
Déjà, toute solution de virtualisation qui repose sur des fichiers pour les disques virtuels me fait gentillement rigoler. Et ensuite, tu peux utiliser l'exportation comme tout le monde.
Sauf stupidité de ma part, Novell et Red Hat ont effectivement tous les près d'1 milliard de dollars en cash. Croissant trimestre-par-trismestre pour Red Hat, en baisse pour Novell. Même à un rythme d'escargots, il ne leur faudra vraissemblablement pas 10 ans pour se rencontrer ; plutôt un voire deux trimestre(s).
Si Red Hat a fait des déclarations concernant un avenir funeste de Novell, je serais très intéressé par des références : nous aurions tiré une conclusion vraissemblablement hâtive.
La branche SUSE de Novell a, comme Red Hat, été l'objet de nombreuses rumeurs de rachats ; il me parait ridicule d'accorder la moindre importance à ces spéculations permanentes.
Je pense que la concurrence est un moyen extraordinaire pour pousser Red Hat à faire toujours mieux, et garde jusque là plaisir à entendre les comparaisons de nos clients entre différents services de support.
Espérons que les équipes de SUSE, quelque soit le futur cadre, fasse survivre cette compétition !
Bilan 2010, donc comparaison avec 2009 :
"Total revenue for the quarter was $195.9 million, an increase of 18% from the year ago quarter. Subscription revenue for the quarter was $169.2 million, up 21% year-over-year. For the full year, total revenue was $748.2 million, an increase of 15% over the prior year, and subscription revenue was $638.7 million, up 18% year-over-year."
Ceci dit, oui, les performances sont désastreuses. Et les déploiements de sssd pour remplacer nscd+nss_ldap+pam_ldap+pam_krb5+pam_ccreds vont probablement s'en retrouver limités (sssd repose entièrement sur dbus).
On déplace du code en espace utilisateur vers du code noyau pour éviter du context switching.
Je doute qu'on puisse raisonnablement en conclure qu'on tend vers du microkernel.
La caractéristique des micro-noyaux ce n'est pas d'avoir un système d'IPC, puisque tous les noyaux en ont un ; c'est que :
- ce soit l'une des rares fonctionnalités offertes ("idéalement" le noyau ne fait que gérer les contextes d'exécution, donc ordonnancement des processus, communication entre les processus et gestion de l'addressage mémoire) ;
- qu'elle soit performante (puisque les tâches habituellement effectuées par le noyau le seront par une flotte de processus qui en aura donc beaucoup beaucoup besoin, des IPCs).
Je ne trollerai ni sur le nombre de fonctionnalités traînant dans le noyau, ni sur les performances de D-Bus.
Ceci dit ici le leitmotiv du changement c'est que le context switching coûte trop cher.
C'est en partie dû au design du noyau Linux.
Au contraire, les micro-noyaux :
- utilisent énormément de context switching puisqu'un tas de processus sont impliqués pour fournir une fonctionnalité qui est classiquement entièrement gérée en kernel space ;
- sont donc logiquement conçus pour être les plus efficaces possibles en la matière.
Sais-tu que Parcellite est actuellement sans mainteneur ?
Dans ma distro, j'ai xclip pour scripter mon manager de clipboard si je veux, xfce4-clipman-plugin (ça tombe bien c'est mon desktop), glipper (pour Gnome), glipper-old (moins de dépendances Gnome, pour les desktops légers), et parcellite (merci pour la référence).
C'est archlinux. Certainement pas grand public, je l'admets.
Mais ma question : ni clipman pour xfce, ni glipper ne sont packagés dans Ubuntu ?
Premier retour d'expérience, l'ayant déballée il y a deux heures : c'est extrêmement lent. Impossible de se balader agréablement dans le livre, et les délais aux changements de page semblent gênants pour une lecture page à page.
L'écran est peu lisible dans les conditions où je me trouve (éclairage très limité) et l'ordinateur portable, qui me bousille les yeux à longueur de journée, s'en retrouve plus pratique.
Je posterai après m'en être servi dans le train pour de la lecture linéaire !
Pour information mon cas d'usage pour les semaines à venir, c'est une collection d'eBooks pour le travail achetés avec empressement chez O'Reilly. Majoritairement ePub, sauf un PDF dont je redoute l'expérience.
Je lui laisse sa chance, mais je suis vraiment déçu pour le moment.
Je viens d'acheter en ligne la version mise à jour (avec multi-coques, les améliorations sont principalement logicielles et seront disponibles pour le premier modèle rapidement). Mon usage sera quasi-exclusivement la lecture de documents technique à priori. Je te donnerai mon avis après une semaine !
# Pendant ce temps, en Angleterre...
Posté par Pierre Carrier . En réponse au journal Merci la sncf. Évalué à 7.
Très utile vu que tout part en vrille dès qu'il neige, diront les mauvaises langues dont je fais partie.
[^] # Re: Censure?
Posté par Pierre Carrier . En réponse au journal Google: vers un contrôle assumé des résultats. Évalué à 2.
Mais j'insiste sur mon propos : le droit étasunien s'applique même aux services que Google me fournit en France (ou dans mon cas, en UK), puisque Google, l'entreprise américaine, les y exporte.
[^] # Re: Censure?
Posté par Pierre Carrier . En réponse au journal Google: vers un contrôle assumé des résultats. Évalué à 2.
Une grosse nuance : ce qui est illégal pour Google ne l'est pas forcément pour moi.
Je suis très content d'être en Europe. Le droit étasunien s'applique à Google.
[^] # Re: Debian un installation minimale ?
Posté par Pierre Carrier . En réponse au journal Mais pourquoi les debianneux n'aiment pas Redhat. Évalué à 2.
Je ne dis pas que NetBSD n'est pas adapté. Je dis juste que le choix de nombre de structures, à tord ou à raison, est de s'orienter vers ces solutions clef en main.
totof2000, d'expérience, oui tout cela est relativement simple, oui c'est automatisable.
Si en tant que salarié, tu as la possibilité de faire changer d'avis ton management pour des solutions moins clefs-en-main mais plus adaptées aux besoins et/ou moins coûteuses à long terme, estime-toi heureux. Mais si tu penses que ton successeur saura rebuilder le système le base de NetBSD sans procédures, estime-toi inconscient !
En pratique, nombre de personnes, y compris des administrateurs système, appellent leur support plutôt que de faire "man rpm". Et c'est finalement préférable à ceux qui exécutent "rpm -e --force glibc" et s'attendent à pouvoir rebooter.
[^] # ur la l
Posté par Pierre Carrier . En réponse au journal Police à l'université. Évalué à 10.
Helvetica était conçue comme une alternative à Akzidenz-Grotesk, principalement pour la signalétique, et Arial est un quasi-clone dérivé entre autres pour en améliorer le rendu sur écrans (bien qu'il s'agisse d'une police d'impression aussi).
Ces polices rendent parfaitement... Jusqu'à ce que je doive me les taper plus de 5 minutes.
Pour ces longs textes, je pense rien ne vaut une police à apattement, comme Times New Roman par exemple (loin d'être ma préférée).
Je pense que mon point de vue est relativement consensuel dans le monde de la typo, mais je n'aurai pas la prétention de le connaître assez pour l'affirmer.
Les goûts et les couleurs :)
# Question de contraintes de taille
Posté par Pierre Carrier . En réponse au journal Police à l'université. Évalué à 9.
Red Hat a fait en sorte qu'une police à la métrique strictement identique soit disponible sous une licence Open Source.
Ta copine peut utiliser Liberation Serif, éventuellement en incluant une note indiquant qu'il s'agit d'un équivalent métrique librement utilisable.
[http://en.wikipedia.org/wiki/Metric-compatible#Font_metrics] si tu souhaites plus d'informations.
# xdg-open
Posté par Pierre Carrier . En réponse au journal launch - le double clic en ligne de commande. Évalué à 10.
NAME
xdg-open - opens a file or URL in the user's preferred application
Je ne dis pas que le tien n'a aucun intérêt, mais qu'apporte-t-il ?
[^] # Re: Esprit humain ?
Posté par Pierre Carrier . En réponse au journal Mais pourquoi les debianneux n'aiment pas Redhat. Évalué à 2.
[^] # Re: Debian un installation minimale ?
Posté par Pierre Carrier . En réponse au journal Mais pourquoi les debianneux n'aiment pas Redhat. Évalué à 3.
Oui, ton serveur NFS tournera. Mais les compétences nécessaires pour prendre en charge les alertes de sécurité (j'imagine que tu prends des vacances, par exemple) n'incluent pas savoir compiler et tester un noyau NetBSD...
Donc même pour un "simple" serveur NFS, si tu n'as pas une armée de barbus à disposition (figure of speech), NetBSD ne remplira pas forcément tes attentes professionnelles.
Une vaste majorité des grandes entreprises, et un nombre conséquent d'universités, hôpitaux, administrations, utilisent des NAS/SAN à la NetApp en partie pour simplifier l'administration...
"It just works", ce n'est pas seulement pour les étudiants trendy. D'aucuns diront nivellement par le bas.
[^] # Re: L'explication
Posté par Pierre Carrier . En réponse au journal Mais pourquoi les debianneux n'aiment pas Redhat. Évalué à 1.
On a pas la même perception de base.
L'outil le propose, oui. C'est possible, oui. Ça signifie dans la plupart des cas te tirer dans le pied, oui.
À ma connaissance, dans l'histoire d'Unix et Linux, on empêche peu ou pas l'administrateur de faire n'importe quoi.
Pouvoir désactiver le groupe de base peut avoir du sens. Par exemple, tu sélectionnes ton set de paquets essentiels via d'autres biais (par exemple kickstart comme indiqué ailleurs, métapaquet, etc.)
[^] # Re: L'explication
Posté par Pierre Carrier . En réponse au journal Mais pourquoi les debianneux n'aiment pas Redhat. Évalué à -3.
Chez Canonical, les contributeurs spécialisés dans l'IHM bossent sur Synaptic, où un carré vert signifie installé et un carré blanc pas installé...
[^] # Re: Hmmm?
Posté par Pierre Carrier . En réponse au journal Fedora suit Ubuntu dans l'adoption prgressive de Wayland. Évalué à 2.
On est bien au-delà du genre de changements introduits par systemd par exemple, où même l'auteur principal, énorme contributeur Fedora et Gnome, s'est vu débouler au rang de grincheux lors du freeze F14. Sa solution était déjà bien plus aboutie que je n'ose l'espérer pour Wayland dans un an.
Par ailleurs il dit simplement que ça a de bonnes chances d'arriver un jour ou l'autre, sur la base de considérations purement techniques, que j'espère personnellement fondées puisque ça a l'air génial d'ici (sans connaître l'état de l'art ou les discussions entre gens plus intelligents que moi).
Le commentateur n'affiche lui-même aucun projet autre qu'un simple packaging dès que possible, pour faire joujou. Je compte bien faire partie des joueurs :)
# Hmmm?
Posté par Pierre Carrier . En réponse au journal Fedora suit Ubuntu dans l'adoption prgressive de Wayland. Évalué à 8.
> Ces derniers jours on apprend également que Fedora va faire de même .
On apprend que des membres du projet vont l'empaqueter pour qu'on puisse jouer avec.
Il n'est pas vraiment question d'une migration pour le moment.
Ça me parait très différent de l'annonce de Shuttleworth...
# Intéressant
Posté par Pierre Carrier . En réponse au journal tcpcrypt. Évalué à 6.
La couche cryptographique a l'air performante mais représente tout de même un certain surcoût... Surtout que netfilter jongle avec un processus userspace, bonjour les changements de contexte.
Le risque de déni de service me semble grandement augmenté, et à moins de passer longtemps à examiner les possibilités pour le réduire correctement et suffisamment, j'aurais peur pour mes systèmes.
Pour finir, j'aimerais des benchmarks sur l'impact en débit et latence sur divers types de connexions et flux. Et non, je n'en ai pas assez envie pour les faire moi-même.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Pierre Carrier . En réponse à la dépêche VirtualBox disponible en version 3.2.10. Évalué à -1.
Olivier, non, pas "faux". Je répondais au commentaire parent, "Si on a du vmware il suffit de prendre le répertoire de la vm qui contient tout ce qu'il faut. Avec VBox, il faut s'amuser à prendre le disque d'un côté, la conf d'un autre, etc.". Je sais bien que VirtualBox gère les raw devices, et j'en suis très content.
Kerro, je critiquais l'utilisation de fichiers classiques (regular files) sur système de fichiers à la ext3. Utiliser des raw devices ou des logical volumes me convient très bien, ils sont pourtant exposés comme des fichiers spéciaux dans /dev.
Antoine, ce n'est pas particulièrement un problème de partitionnement... Tu as le temps perdu en espace noyau, la prédictibilité limitée de la plupart des systèmes de fichiers pour de très nombreux accès aléatoires sur de gros fichiers (parce que c'est un aspect généralement secondaire à la conception) causant des phases de "lag" qui peuvent être sensibles y compris sur de la prod serveur extranet.
Je passe sur les nombreuses erreurs de déploiement à plus fort impact, comme un journaling des données sur le système de fichiers hôte, ou de l'allocation dynamique pour l'image du disque... Là, les pertes ne sont vraiment pas dures à mesure.
Pour ceux qui théorisent que plus de couches peut vouloir dire meilleures perfs... J'aimerai voir des benchs.
Le cas le plus rigolo, c'est Xen qui utilise des loop devices quand le stockage est dans des "regular files" (traduction ?). J'ai vu des retours d'administrateurs rencontrant des problèmes de locking dans le noyau : au-dessus de 3 ou 4 machines virtuelles qui font beaucoup d'I/Os, les performances chutent de manière phénoménale. Apparemment un problème de design connu.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Pierre Carrier . En réponse à la dépêche VirtualBox disponible en version 3.2.10. Évalué à -9.
[^] # Re: Coucher avec Microsoft
Posté par Pierre Carrier . En réponse au journal SuSE Linux en passe de se faire racheter par VMWare. Évalué à 2.
"Total cash, cash equivalents and investments as of May 31, 2010 was $967.8 million."
http://investors.redhat.com/releasedetail.cfm?ReleaseID=4817(...)
"Cash, cash equivalents and short-term investments were $980 million at April 30, 2010, down from $991 million last quarter."
http://www.novell.com/company/ir/qresults/10q2/schedules_10q(...)
[^] # Re: Coucher avec Microsoft
Posté par Pierre Carrier . En réponse au journal SuSE Linux en passe de se faire racheter par VMWare. Évalué à 1.
Voilà, du bruit pour rien. Merci d'avoir clarifié !
[^] # Re: Coucher avec Microsoft
Posté par Pierre Carrier . En réponse au journal SuSE Linux en passe de se faire racheter par VMWare. Évalué à 2.
La branche SUSE de Novell a, comme Red Hat, été l'objet de nombreuses rumeurs de rachats ; il me parait ridicule d'accorder la moindre importance à ces spéculations permanentes.
Je pense que la concurrence est un moyen extraordinaire pour pousser Red Hat à faire toujours mieux, et garde jusque là plaisir à entendre les comparaisons de nos clients entre différents services de support.
Espérons que les équipes de SUSE, quelque soit le futur cadre, fasse survivre cette compétition !
[^] # Re: Coucher avec Microsoft
Posté par Pierre Carrier . En réponse au journal SuSE Linux en passe de se faire racheter par VMWare. Évalué à 3.
Agonie ? Gnnn?
Red Hat GAAP net income, d'après http://investors.redhat.com/results.cfm:
2010Q1 $18.5M
2010Q2 $28.9M
2010Q3 $16.4M
2010Q4 $23.4M
2011Q1 $24.1M
Bilan 2010, donc comparaison avec 2009 :
"Total revenue for the quarter was $195.9 million, an increase of 18% from the year ago quarter. Subscription revenue for the quarter was $169.2 million, up 21% year-over-year. For the full year, total revenue was $748.2 million, an increase of 15% over the prior year, and subscription revenue was $638.7 million, up 18% year-over-year."
[^] # Re: socket
Posté par Pierre Carrier . En réponse au journal addr.sun_family = AF_DBUS;. Évalué à 2.
http://dbus.freedesktop.org/doc/dbus-specification.html#tran(...)
Et sur http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusCon(...) :
dbus_bool_t dbus_connection_get_socket(DBusConnection * connection, int * fd)
Ceci dit, oui, les performances sont désastreuses. Et les déploiements de sssd pour remplacer nscd+nss_ldap+pam_ldap+pam_krb5+pam_ccreds vont probablement s'en retrouver limités (sssd repose entièrement sur dbus).
[^] # Re: Microkernel ?
Posté par Pierre Carrier . En réponse au journal addr.sun_family = AF_DBUS;. Évalué à 10.
Je doute qu'on puisse raisonnablement en conclure qu'on tend vers du microkernel.
La caractéristique des micro-noyaux ce n'est pas d'avoir un système d'IPC, puisque tous les noyaux en ont un ; c'est que :
- ce soit l'une des rares fonctionnalités offertes ("idéalement" le noyau ne fait que gérer les contextes d'exécution, donc ordonnancement des processus, communication entre les processus et gestion de l'addressage mémoire) ;
- qu'elle soit performante (puisque les tâches habituellement effectuées par le noyau le seront par une flotte de processus qui en aura donc beaucoup beaucoup besoin, des IPCs).
Je ne trollerai ni sur le nombre de fonctionnalités traînant dans le noyau, ni sur les performances de D-Bus.
Ceci dit ici le leitmotiv du changement c'est que le context switching coûte trop cher.
C'est en partie dû au design du noyau Linux.
Au contraire, les micro-noyaux :
- utilisent énormément de context switching puisqu'un tas de processus sont impliqués pour fournir une fonctionnalité qui est classiquement entièrement gérée en kernel space ;
- sont donc logiquement conçus pour être les plus efficaces possibles en la matière.
# ... Mauvais exemple.
Posté par Pierre Carrier . En réponse au journal Petit coup de gueule contre les distributions grand public. Évalué à 2.
Dans ma distro, j'ai xclip pour scripter mon manager de clipboard si je veux, xfce4-clipman-plugin (ça tombe bien c'est mon desktop), glipper (pour Gnome), glipper-old (moins de dépendances Gnome, pour les desktops légers), et parcellite (merci pour la référence).
C'est archlinux. Certainement pas grand public, je l'admets.
Mais ma question : ni clipman pour xfce, ni glipper ne sont packagés dans Ubuntu ?
[^] # Re: Cybook Opus
Posté par Pierre Carrier . En réponse au journal Liseuses sous Gnu/Linux pour de la documentation. Évalué à 2.
L'écran est peu lisible dans les conditions où je me trouve (éclairage très limité) et l'ordinateur portable, qui me bousille les yeux à longueur de journée, s'en retrouve plus pratique.
Je posterai après m'en être servi dans le train pour de la lecture linéaire !
Pour information mon cas d'usage pour les semaines à venir, c'est une collection d'eBooks pour le travail achetés avec empressement chez O'Reilly. Majoritairement ePub, sauf un PDF dont je redoute l'expérience.
Je lui laisse sa chance, mais je suis vraiment déçu pour le moment.
# Cybook Opus
Posté par Pierre Carrier . En réponse au journal Liseuses sous Gnu/Linux pour de la documentation. Évalué à 2.