Enj0lras a écrit 250 commentaires

ça va, le sentiment de ta supériorité ne t'a pas encore étouffé ? Sérieusement, pourquoi les gens éprouvent ils toujours le besoin de montrer que eux, au moins, ils savent écrire correctement ? Qu'est ce que ça apporte ? C'est pas comme si vérifier les commentaires et lire les corrections en même temps que le journal était plus agréable que lire le journal avec les fautes…

Ça se résume en une phrase en fait ton journal :

GNOME, Red Hat, et Freedesktop c'est l'incartation du malin sur terre, KDE c'est les gentils bisounours, et le malin est méchant avec les bisounours. Et vous, si vous êtes des gens intégres et gentils, vous n'avez d'autre choix qu'haïr freedesktop. Entrez dans la secte !

… comme vim ?

Je vais pas m'amuser à écrire plusieurs fois la même chose, alors que je l'ai déjà fait dans un journal.

Et dire qu'il y en a encore pour croire que la démocratie, c'est quand tu vas mettre un petit papier dans une boite tout les 2 ans…

Je suis d'accord, le site est moche, et pas simple d'utilisation. Difficile d'y trouver ce qu'on cherche.

Mais il est aussi maintenu par des militants et il est libre maintenant. Je dis ça je dis rien :>.

Est-ce que le travail sur l'ordonnanceur de DragonflyBSD pourra être bénéfique aux autres BSD ?

Dans la majorité, non, car ils dépendent de choix techniques spécifiques à dragonfly. Les modifications de pmap pourraient être porté simplement sous FreeBSD je pense, mais FreeBSD vise déjà les huge pages.

FreeBSD se targue d'être utilisé dans de grosses boîtes comme yahoo, m'enfin vu les performances, on se demande s'ils n'en viendraient pas à regretter leur choix au moins de ce côté des choses.

Premièrement, les performances, ça ne veut rien dire, c'est un benchmark spécifique qui ne reflette même pas les conditions réelles. DragonFly a travaillé sur ce benchmark pour améliorer les performances SMP, mais ça n'en fait pas une mesure fiable. En plus il y a les réglages par défaut qui comptent, via sysctl, et qui peuvent aussi jouer sur les perfs. Je pense qu'optimizer FreeBSD dans ce cas ne serait peut être pas plus dur que d'optimiser dragonFly comme cela a été fait.

Et qu'en est-il d'OpenBSD ? Bien que ça ne soit pas forcément son objectif, si NetBSD est là alors pourquoi pas OpenBSD. pgsql n'a pas encore été porté peut-être.

Parce qu'openBSD n'avait pas de threads 1:1 jusqu'a la dernière version ? Alors tester le passage à l'échelle SMP, c'est un peu étrange…

Quand à pgsql qui ne serait pas porté : http://openports.se/databases/postgresql

1/ Le fait de s'adapter à la topologie des machines paraît une bonne idée. Est ce que les autres *BSD, Linux ou tout autre noyau utilise ce principe ?

Linux, ainsi que solaris et freeBSD, tiennent compte de la topologie dans leur scheduler. Toutefois, les schedulers sont différents et suivent des approches différentes. Linux bénéficie d'un gros travail sur les perfs du scheduler.

2/ Je ne connaissais pas Scientific Linux. Cela semble juste une distribution particulière de Linux mais avec rien de spécifique sur le noyau, n'est ce pas ?

C'est un clone de RHEL, donc un noyau RHEL. C'est juste le noyau 2.6.32.

3/ Le texte de la dépêche est alléchant sur le sujet performance ("500%") mais au final, on se rend compte que la version 3.0 était pas top et que la version 3.2 ne fait que ramener ce système dans le haut du panier.

Oui. Mais il faut se dire que le passage de la 3.0 à la 3.2 n'est que la partie visible de l'iceberg. C'est juste l'aboutissement d'un travail de base, les derniers réglages qui font que tout marche. D'ailleurs, les perfs de pgbench ont augmentées depuis plusieurs versions.

4/ du coup, est ce que l'approche "topologique" est bonne ou simplement, Linux le fait déjà et dragonfly ne fait que rattraper son retard ?

Si tant est qu'on puisse parler de retard, oui, on peut dire ça. Mais rattraper ce n'est pas forcément adapté, car l'approche est un peu différente.

je voudrais juste commenter ce benchmark, qui circule pas mal et que les gens ont tendance à mal interpréter.

Un benchmark, ça n'est utile que quand on sait ce qu'on mesure et qu'on sait que cette mesure a un sens. Je lis beaucoup de "dragonfly plus performant que X". Ça ne veut rien dire. Un benchmark, il faut le comprendre, il n'a aucune valeur en général.

Dans ce cas, le benchmark mesure quoi ? L'éxécution de processus contenant des threads en parallèles, les processus étant deux à deux liés. De plus, c'est processus font beaucoup d'I/O. C'est donc un bench trés large qui dépend de la vitesse en lecture/écriture du FS, de la gestion des sockets UNIX, des semaphores posix, de la gestion des threads et du scheduling, et de la gestion de la mémoire partagée. Ça fait beaucoup, et on se rend bien compte que beaucoup de paramètres peuvent jouer, à commencer par les réglages par défaut du noyau utilisé.

Ce qu'il a permi de mesurer avait un sens : le benchmark a été répété tout au lent du développement, après chaque changement. Il mesure donc l'impact sur les performances de chaque modifications, toutes choses étant égales par ailleurs. Pour comparer les versions, et identifier les goulot d'étranglement, c'est un bon benchmark.

Comparer avec d'autres OS a moins de sens déjà, car beaucoup de paramètres diffèrent. Toutefois, ça peut donner une idindication sur les bottlenecks restants, et ça a quand même une valeur indicative dans le processus de développement, tout autant que motivante (on peut rattraper X, ça donne un objectif).

Mais pour comparer les performances du point de vue d'un utilisateur, est ce que ça a un sens ? Je ne pense pas. Il s'agit purement d'un benchmark de développement : il s'intéresse à une charge particulière, qui n'a pas vraiment d'éxistense dans les conditions réelles : on ne fait jamais tourner un server par client, par exemple, ou le serveur risque d'avoir un socket TCP, et de toute manière, il faut avoir besoin d'un système qui monte à 200 000TPS.

La comparaison avec les autres systèmes est donc à mon avis trés flottante et sans grande valeur. Il est tout à fait possible que FreeBSD atteigne d'aussi bon résultats en changeant quelques sysctl.

Justement. Ce qui me déplait dans KDE ? que ce soit personnalisable à l'extrême.

Il y a trop d'interactions possibles et des boutons de configurations qui n'ont rien à faire dans mon workflow habituel. De même tu as toujours plusieurs manières de faire la même chose. Je deteste ça pour ma part, je trouve que ça rend l'utilisation beaucoup plus difficile en diminuant les automatismes et en introduisant une part de choix à quasiment chaque action qu'on veut réaliser.

Du coup, je n'aime pas KDE, justement à cause de ce que certains ici présentent comme la fonctionnalité utlitme qui rend KDE universel et adapté à tous.
Après, je n'aime pas forcément la gestion des fenêtres avec gnome (j'ai besoin de tiling), mais j'apprécie l'approche globale.

Du coup, si ma vie vous intéresse, j'utilise le WM awesome avec gnome.

Exactement, c'est même un des buts du projet. Le fait est que si tu as distro linux avec NFS et NFS qui a une faille, même si tu utilises pas NFS, tu as une faille. Donc c'est pas si absurde comme "record".

To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.
This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install.

Il va falloir que tu m'expliques en quoi c'est complétement différent. Pour, c'est le même problème, ou du moins, le SMP est juste un sous problème du cluster. Le projet SMP avait pour but d'augmenter la localité des données, et d'isoler les sous-systèmes tout en peremttant d'avoir des mécanismes de communication et de serialisation performants. Pour moi, c'est exactement ce qui est nécessaire pour faire un OS de cluster. Après, la partie restante, la cohérence de cache a je pense été abandonnée (j'en sais rien), parce que les nouveaux processeurs ccNUMA ou SMP gèrent ça eux même.

Il me semble que le SMP est juste un moyen, pas un but.

Well I strongly believe that any project needs to have an unattainable goal, and our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).

In the short term, I have become very exciting about our light weight kernel threading technology, in particular the methodlogy we are adopting to serialize data access by partitioning major subsystems into threads instead of serializing data access with mutexes (FreeBSD-5 and Linux use a mutex-centric model, DragonFly uses a thread-centric model). The reason for this excitement is that it is becoming clear to us that we can develop very clean-looking, elegant, debuggable, SMP scaleable software using this model whereas using the mutex model generally results in much less elegant (even ugly), difficult-to-debug code. Code complexity and code quality is a very important issue in any large piece of software and we believe we have hit on a model that directly addresses the issue in an SMP environment without compromising performance.

C'est vraiment une bonne nouvelle, je ne comprends pas pourquoi Google Wave n'a pas eu de succés (enfin, si je comprend, c'est complexe à maitriser et pas simple à utiliser au premier abord. Les devs Gnome diraient "pas intuitif").

J'ai utilisé un moment Wave in a box, l'implémentation maintenue par la fondation Apache, mais il n'y avait pas trop de contribution. Apparament, cette version est une interface remaniée. J'ai pas l'impression que l'interface y gagne en clareté et en cohérence, c'est même l'inverse ihmo, mais c'est vraiment cool qu'il y ai des users.

Si j'ai bien compris, c'est juste un frontend au dessus de l'implémentation Appache Wave ? Dans ce cas pourquoi ne pas utiliser wave in a box ? quelqu'un qui a déjà testé (je suis à peine en train de découvrir) a une opinion sur les avantages que ça apporte ?

Et aussi, je suis curieux de savoir si c'est porté sous java 7, mais ça avait l'air d'être un sacré morceau.

C'est honteux, KDE et GNOME n'utilisent pas le même compositeur et WM, quelle duplication d'effort ! Il faudrait merger mutter et KWin ! Et vite.

Sérieusement, ça serait bien ici que les gens arrêtent de crier au loup sans cesse. Tu vois le diable là ou tu veux bien le voir.

sinon, tu pourrais prendre la peine de te renseigner avant d'affirmer n'importe quoi.

Il s'agit pas d'un WM appelé serveur d'affichage, ni l'inverse, il s'agit d'un WM qui est un serveur d'affichage ainsi qu'un compositeur. Alors, oui, il faut recoder un serveur d'affichage pour recoder une WM. Mais, il y a plusieurs choses à prendre en compte :

• il y a une lib
• si la licence te convient, tu peux repartir de weston
• Weston fait 21279 lignes alors même qu'il implémente beaucoup de backends (android, par exemple), ce qui est pour info grosso modo la taille d'awesome WM.

Donc, il y a de fortes chances qu'on voit fleurir des compositeurs waylands adaptés, voire même des ports de wm existants pour X, pour ceux qui on une logique propre comme awesome.

J'aimerais bien savoir ce qu'un non informaticien pourrait bien avoir à reprocher à systemd…

Ces gens là je ne les classe pas dans des utilisateurs,mais des contributeurs.

a) La communauté (même ceux qui ne développent pas, qui ne traduisent pas etc.) a toujours le droit d'ouvrir sa gueule du moment qu'elle utilise. Les admins sys sont la raison d'exister de Red Hat

Et ça sert à quoi à part faire chier le monde ?

Tu devrais en parler à Lennart, il n'est pas au courant.
Lennart a choisi de ne pas écrire du code portable, parce que ça simplifie largement sa base de code. Je ne vois pas en quoi c'est un problème. C'est son parti pris, il fait ce qu'il veut. Si tu trouves que c'est un problème, tu peux forker. Mais perso, je trouve que lennart fait beaucou pour la portabilité.

Ce qui est important, c'est les interfaces. Aux dernières nouvelles, les BSD n'utilisent pas le même init que GNU. Ni la même libc. Personne ne crie au scandale, du moment qu'il y a des interfaces standards documentées. Et c'est le cas de systemd.
De toute manière, les systèmes BSD rechigeraient à porter systemd dans leur base, vu que c'est GPL. Donc, ce je ne vois strictement aucun problème de portabilité. De plus, la transition sysvinit → systemd n'a RIEN changé de ce point de vue.

Non, ça c'est toi qui le dit. Moi, j'ai posé la question.

oui c'est ce que je dis. Et je ne vois pas en quoi c'est mal.

C'est tout à fait ça, Lennart c'est un brave bénévole, il vit d'amour et d'eau fraîche.
systemd est un projet de bénévole oui. Et quoi qu'il arrive, même quand il travaille pour Red Hat, il ne travaille pas pour n'importe quel user, il travaille pour les clients Red Hat. Les utilisateurs clients de Red Hat ont payé pour avoir le droit d'ouvrir leur gueule, pas l'utilisateur lambda.

non, non, on ne mettra pas de #ifdef dans mon code pour assurer une meilleure portabilité

Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

Cette réponse serait pertinente si tout utilisateur avait les capacités pour contribuer, ce qui est très loin d'être le cas.

Pourquoi ? Elle est pertinente quoiqu'il arrive. Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule. Et bien oui, s'il n'a pas de solution à proposer. Un tel utilisateur ferme sa gueule, ou alors il peut payer quelqu'un pour coder ce dont il a besoin. Kickstarter existe par exemple.

Je ne vois pas en quoi c'est un problème. Des devs bénévoles ne sont pas là pour répondre aux besoins de tout le monde. Ils écrivent du code pour répondre à un besoin particulier et le distribuent pour que des gens qui ont le même besoin qu'eux puissent en profiter. C'est déjà beaucoup. Tu ne peux pas leur demander de combler tout les besoins de tout le monde sur terre.

Si le besoin qu'ils comblent ne correspond pas au tient, bah soit tu contribues/modifies, soit tu trouves una utre logiciel qui correspond mieux à tes besoins, soit tu payes quelqu'un/convaint quelqu'un de dev quelque chose pour tes besoins.

Mais c'est pas en trollant sans cesse que les gens vont convaincre les devs de faire ce que eux ils veulent et non ce que les devs veulent eux même.

Quand on lit que GNOME pourra dépendre d'un init particulier, on croit rêver…

Déjà, c'est faux, c'est même complétement faux. Il dépend d'une API. Maintenant, au lieu de lancer un troll dans le vents, que donne ton argument si tu prends la peine de le justifier ? Je ne dis pas qu'il est mauvais, mais qu'en l'état de ta formulation, il est un peu faible.

Parce que, je peux l'appliquer à autre chose :

quand on voit des applications unix qui dépendent de l'API POSIX, on droit rêver ! Ah non. On rêve pas.

Du coup, je serais heureux de savoir ce qui te pose réelement problème là dedans.

Ou de devenir contributeur, au choix.

Je trouve le paralèle avec dragonfly un peu gros. Ici, on parle d'un système d'init, qui ne change pas grand chose en réalité. C'est un peu comme si on disait qu'il fallait forker ubuntu avec chromium proposé par défaut. Les différences entre DragonFly et FreeBSD vont largement au delà du choix d'un logiciel, fut il aussi aussi basique qu'init. Toutefois, je suis d'accord avec l'idée véhiculée.

D'une manière générale, je trouve que la dramatisation de cette histoire est un peu ridicule, et le fanatisme de certains me fait un peu peur. Je trouve que l'ambiance de la communauté est devenue assez malsaine ces derniers temps à cause de fanatiques professant leurs haine à l'encontre des devs (ou pour les devs, ça vaut pour les deux camps), dégradant le climat sain dans lequel un projet open source peut prospérer.

La haine à l'encontre de projets comme Gnome ou systemd est à mon sens sans objet. Un utilisateur pur n'a aucun droit. Être en désaccord avec un choix technique est un fait, mais l'action est la seule réponse valable. Monopoliser le temps de tout le monde dans des débats stériles ne bénéfie à personne, et freine l'évolution des projets libres.

Pour moi, un utilisateur n'a aucun droit, et encore moins le droit de faire chier le monde en râlant sans cesse. Quand des devs bénévoles s'investissent dans un projet libre, ils font ce qui leur semble bon, et qui plus est, ce qui leur plait. Si un utilisateur n'est pas d'accord, il peut certe exprimer son opinion dans la mesure ou elle apporte quelque chose de NOUVEAU au débat, car c'est dans la communauté que se construit un projet. Mais il doit le faire constructivement. Et les débats passionés qu'on peut voir actuellement sont tout sauf constructifs. Dans le monde de l'opensource, rien n'est du aux utilisateurs, et tout est à construire, tout se gagne. Ensemble.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Un utilisateur n'aime pas systemd ? Soit. Et bien, qu'il n'utilise plus Arch, ou qu'il code une autre solution. Mais on n'a pas besoin de le savoir, jours après jours, de manière de plus en plus violente. Mais assez de débats stériles avec des arguments bancals, assez de flamewars inutiles, tout cela est malsain.

ça permet aux développeurs et aux utilisateurs de se rendre compte que l'appli est lente, et de se confronter à la réalité. Une fois fait, les devs et les utilisateurs peuvent travailler de concert pour régler ce problème.

Un seul exemple : Firefox.

En gros, ça exige de la qualité.

La communauté ?