GeneralZod a écrit 2316 commentaires

C'est encore très jeune, les extensions "officielles" sont encore à l'état expérimental.

ça c'est de la mascotte !

Mark J. Cox est un ingénieur de sécurité de Red Hat, il a publié une petite rétrospective sur les errata de sécurité de RHEL 6 publié jusqu'à aujourd'hui.
http://www.awe.com/mark/blog/20110520.html

Je peux te citer sans problème une dizaine de personnes plus violentes que Théo de Raadt, mais plus dictatorial que le dictateur Ulrich sans hésitation = {0}

Toi, t'as jamais utilisé les jails.

J'ai probablement plus utilisé les jails que toi LXC ...

Si tu tiens à savoir, j'ai deux serveurs freeBSD uniquement pour ça, le premier me permet de confiner divers services (lighttpd, postgres, nginx, git, mercurial) -migré parce que la syntaxe affreuse d'IPTables me sortait par les trous de nez-, le second des slaves de compilation pour Jenkins pour tester diverses combinaison de bibliothèques.

Côté Linux, j'ai pas mal utilisé OpenVZ et LXC, la seule chose que LXC aurait à envier aux jails, c'est les outils userland qui sont clairement à la ramasse pour LXC (c'est moins le cas avec OpenVZ qui a des outils très sympas mais qui lui est à la traine en terme de support).

pourtant tout le code de Gnome 2, qui fonctionnait parfaitement, et passé à la poubelle lors de la réécriture de gnome 3.

Euh, la plupart des bibliothèques et applications ont été portées sur Gtk+3 et adaptés au shell, le peu de code qui est allé à la poubelle c'est essentiellement du code déprécié.

Idem pour le projet Compiz, qui fonctionnait parfaitement avec gnome2, et qui n'est plus prévu pour gnome 3 et gnome shell.

T'as essayé de faire fonctionner un autre windows manager avec Unity/Compiz ? T'as exactement le même problème qu'avec GNOME Shell/Mutter.

Et depuis gnome 3, je ne peux plus faire appel à des programmes gtk3 depuis un DE différent (KDE par exemple), ça bloque les boutons.

Sous F15, OpenSuSE Factory, ça juste marche hors de la boite (testé avec KDE 4.6, LXDE, XFCE), en revanche, t'es obligé d'utiliser le thème adwaita si tu veux pas que tes applications Gtk+3 soient dépareillées avec les applications Gtk+2.

KDE n'a jamais participé au dev de dbus-menu.

Tu as raison, je confonds avec status notifier proposé sur fd.o par KDE puis appuyé par Canonical, je fatigue moi.

Raté, ce sont des port usermode d'un OS. Ce que n'est pas rump, qui est surtout une architecture kernel.

Au temps pour moi, décidément, j'ai du mal à cerner rump (si quelqu'un cherchait une idée d'article pour GLMF, ça fait un moment que j'ai rien lu autour des BSD :] )

Microsoft et Apple n'empêchent pas de réimplémenter leurs specs: ca ne pose pas de problème à Wine.

La différence majeure à mes yeux, c'est qu'en l'absence de specs, le source est disponible pour les balles d'yeux, les développeurs sont disponibles pour répondre aux questions, ce qui est rarement le cas avec nos zigotos de M$ et la pomme.

C'est une entité qui s'est imposée d'elle même étant donné le bordel qu'est l'écosystème de distributions Linux, et le manque d'homogénéité entre les distribs

En 2000, c'était le bordel pour l'interopérabilité des bureaux *nix, c'est pour ça que Havoc Pennington a eu l'idée d'un espace de discussion. Même si ça n'est pas parfait, fd.o a aplanit énormément de problèmes, et les petits s'y retrouvent (du moins, c'est moins pire qu'avant).
Pour les couches basses du système (noyau + userland), ça commence à sentir très mauvais, Posix s'encroute, le rift est en train de s'agrandir et les égos sont encore plus énormes que ceux des développeurs de bureaux. Il est d'autant plus important de créer un espace de discussion et de faciliter les échanges de code (ne serait-ce que pour les pilotes ou définir des interfaces) que l'on est en train de recréer l'enfer des *nix propriétaires en pire et sans rien d'autre à gagner que de fragmenter inutilement le marché

Faudrait comprendre qu'on a pas 1500 développeurs et que tous ne peuvent se permettre de réécrire la pile IP lundi, USB pour le mardi, et changer 3 fois les API du scheduler parce que ca nous chante

certes, on a un gros problème d'incompréhension mutuelle, et un front désuni des OS libres ça n'aide pas à mutualiser les ressources (la division du marché pour obtenir la collaboration des fabricants, le manque de ressources -pas que chez BSD, Linux manque parfois de bras dans certains domaines-)

On se plaint régulièrement de la lenteur de POSIX à évoluer: c'est le propre même d'un standard, qui demande une certaine réflexion.

Le problème c'est qu'il n'y a plus de réflexion dans Posix, on toilette les API, y a eu la fusion avec SUS et c'est à peu près tout. Par exemple, avoir une interface standard moderne pour la gestion de notification; ça serait pas du luxe dans Posix, entre kqueue de BSD et les gesticulations linuxiennes, ben, on est content que libevent soit là (enfin, ça commence également à chier avec l'arrivée libevent 2.x)

Là ou le bat blesse, c'est que le monde FLOSS s'y prête mal; à cause des egos forts; du droit discrétionnaire de certains à disposer de leur bébé (le cas de la glibc est criant -- et un OS sans libc, ca va pas loin); du manque de moyens et d'investissement.

Je te plussoie.

Mais je croyais que KDE et Canonical avaient fait leur truc de leur cote? Tu te contredis un petit peu.

1. KDE propose un truc sur la liste fd.o
2. mclasen et vuntz font des suggestions > /dev/null
3. Canonical et KDE s'associent et font leur truc dans leur coin sans jamais en parler sur fd.o où inviter des mecs externes à participer.
4. 9 mois* plus tard, dbus-menu vient au monde et les papas tout fiers demandent qu'on adopte le bébé et refusent toute critique

C'est quoi qui est contradictoire là-dedans ?

• durée non contractuelle pour les malcomprenants, j'ai la flemme de recompter la durée exacte en millionième de seconde séparant 1. et 4.

il n'a jamais imposé systemd, il propose que GNOME utilise l'interface DBus de systemd, rien n'interdit d'implémenter un daemon BSD pour faire la même chose différemment. DBus a été créé pour faciliter l'interopérabilité entre les bureaux, autant s'en servir, si l'interface de systemd pue, proposez autre chose, Lennart n'a jamais été fermé à la discussion (hein, il a réussi à mettre tout le monde d'accord au sein du mastodonte FHS), même si il est (très) rugueux sur les bords.

De plus il faut mentionner que Gnome ne tourne pas que sous *BSD et Linux mais aussi Solaris, AIX etc.

Tu veux que ton expérience de bureau soit limité au plus petit dénominateur commun ? bon courage avec AIX.

Ce n'est pas beau de re-ecrire l'histoire!

tu te fous de notre gueule ? On en a déjà parlé, et quand KDE avait lancé la discussion mclasen et vuntz avait fait des suggestions qui sont allés tout droit dans /dev/null et plusieurs mois après, KDE et Canonical se pointent avec un truc fini fait dans un coin en disant: "voilà, utilisez notre truc" et aseigo & cie ont fait leur numéro d'autistes digne d'un mccann. Les listes sont publiques, encore une fois.

Elle est où la spec de libudev (au moins udisk d'ailleurs) ?

Voilà les interfaces DBus à implémenter pour udisks (y a nettement pire que DBus pour faire une couche d'abstraction, ça ne requiert au minimum que les sockets Unix)
http://hal.freedesktop.org/docs/udisks/
Les APIs spécifiques à Linux sont explicitement marqués, il y a surement moyen de faire mieux.

Elle est où l'annonce disant sur freedesktop: "hé, on va coder une interface générique pour l'accès au matos sous la forme d'une lib parce que hal était une mauvaise idée, voici mes idées discutons en ?"

http://lists.freedesktop.org/archives/hal/2008-May/011560.html Tu noteras que udisks/upower et leur prédécesseur DeviceKit n'ont jamais été fermé aux autres unices.

cela semble ok si c'est Gnome qui pond une norme dessus, de preference sans discuter avec personne

Arrête de dire n'importe quoi, les archives des listes fd.o sont publiques, les normes fd.o sont discutés puis validés, après faut pas venir se plaindre.

mais si c'est KDE, par exemple, cela ne sera jamais adopte par Gnome.

Quelle norme ? si tu parles dbus-menu, Canonical et KDE ont fait leur truc dans leur coin avant de tenter de l'imposer.

Donc dire que les devs BSD ne s'impliquent pas c'est un peu fort de café ;-)

D'où le quasiment ;) C'est du logiciel libre, on n'impose rien à personne, si XFCE impose une dépendance à udev pour Thunder, bah faut proposer une alternative or ça n'a pas été le cas pour le moment. Idem pour GNOME (c'est une proposition, rien n'est décidé, si quelqu'un a une meilleure proposition ==> feel free to do it), mais tant que personne ne fera preuve d'empathie, les BSD-istes continueront de penser que les GNU/Linuxiens sont des "cow-boys égoïstes" et les derniers que les premiers sont une espèce en voie de disparition juste bon à râler.

Certes, mais dans le cas de XFCE, aucune couche d'abstraction n'existe et quasiment tout les devs sont sur Linux (c'est le point d'achoppement). C'est un problème intrinsèque au libre, tu ne peux pas forcer les développeurs à développer pour un système qu'il n'utilise pas, comme on peut pas te forcer à développer pour linux.
La solution, c'est qu'il y ait plus de gens de BSD dans les projets upstream, envoyer des patchs, normaliser les interfaces et que les gens sous GNU/Linux soient un peu plus ouverts mais tant qu'on reste dans une logique de guerre tranchées, c'est le plus fort (et pas forcément le meilleur) qui l'emportera.

son comportement n'a absolument rien à voir en comparaison de celui de gars comme Theo de Raadt ou Ulrich Drepper

Ulrich Drepper c'est une catégorie à lui seul et quelques mondes le sépare du reste du peloton de tête. Je doute qu'on puisse encore le rattacher à l'espèce humaine.

Linus aime parfois troller et il a des opinions bien arrêtées sur pleins de sujets

comme Théo, je pense honnêtement que si tu les mets face à face, la question de savoir lequel des deux est le moins collaboratif risque d'être indéterminée.

Si on voulait être de mauvaise foi, on pourrait dire que les développeurs d'OpenBSD ne l'ont pas conçu dans une optique de portabilité et que c'est pour ça que ça n'existe pas dans Linux. Et après les monsieurs de BSD nous répondront que les développeurs de Linux n'avaient qu'à participer au développement de CARP. :]

Théo et Linus ont deux points communs, ils sont tout aussi compétents et tout aussi imbuvables socialement parlant, si on veut que les choses avancent, il faudra bien à un moment ou à un autre faire preuve d'empathie et discuter autour d'une table (ou d'un arbre, c'est rigolo aussi).

Btrfs (modulo le fsck) marche très bien lui

L'API est complètement délirante et linux centrique, pourquoi ne pas avoir réfléchi (sick) à une API propre ET générique genre je veux un truc qui me donne telle ou telle information

Ce qui est délirant, c'est qu'aucun développeur *BSD n'ait daigné participer au développement de udev et après on vient se plaindre que les développeurs Linux font des interfaces spécifiques ... bah oui, forcément, faut p'tet descendre de sa tour d'ivoire et reconnaitre que les torts ne sont pas à sens unique.

il est passé où le temps ou les gens réfléchissait avant de pondre un code, le temps où l'on essayait coûte que coûte de pondre du code simple et portable ?

Certes, mais pour moi, le coeur du problème, c'est qu'il n'y a plus de concertation et qu'il n'y a aucun effort de normalisation quelconque. Il faudrait un FreeDesktop.org pour les OS Unix/Unix-like et beaucoup moins de mauvaise foi de part et d'autre.

Signé, le monsieur qui bave et qui ne sait pas de quoi il parle.

Linux est loin d'avoir un rump à la NetBSD

CoLinux, UML etc ....

les containers manquent de fonctionnalités que les jails et les zones ont depuis des années (pile réseau virtualisée, voire migration à chaud

Actuellement, seul FreeBSD propose encore les jails, ça fait plus d'un an que NetBSD et OpenBSD ont retiré le support à cause d'un problème de sécurité. La migration à chaud, je le faisais avec OpenVZ quand NetBSD avait encore le support des jails, LXC le fait (Cf. freeze/unfreeze), pour la pile réseau virtualisé, c'est disponible

Il m'est arrivé de lire ici qu'il était question avant tout de choix libre, non contraint, avec l'interopérabilité comme toile de fond. Vous savez, celle qui vous fait régulièrement cracher sur Microsoft ou Apple. Propos que je trouve subitement hypocrites.

Le problème c'est que Microsoft ou Apple t'empêche d'être intéropérable, alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre (ils sont où les gens de NetBSD sur fd.o ?), pour les APIs noyaux, il n'y a quasiment plus aucun effort de standardisation et c'est fort regrettable. Je pense pas que côté *BSD, on soit aussi irréprochable que tu le dit.

On a les jails, ZFS, carp, Packet Filter

Jails ==> LXC (inclus de base dans le noyau et qui avec CGroups offre déjà des fonctionnalités plus fine que les jails), OpenVZ, VServers etc ... On peut aussi comparer le support de la virtualisation en tant que host (FreeBSD => VirtualBox, NetBSD => Xen, OpenBSD => qemu + support incertain de Kqemu, sous Linux, nativement, tu as KVM, lguest et bientôt Xen)
ZFS ==> BtrFs et deux ports natifs sous Linux sont en cours.
CARP ==> certes, pas de support natif dans la kernel, mais UCARP est là.
PF ==> PF a de grandes qualité, mais si on mets de côté la syntaxe atroce d'IPTables (qui contraste furieusement avec celle simplissime de PF - et IPFilter et IPFW sont encores plus simples bien qu'étant moins souples que PF), sur le plan fonctionnel, ils se valent.

Les *BSD ont d'énormes qualités (robustesse, cohérence, etc ...) mais ils sont à la traine, est-ce que la solution est de figer TOUTE innovations ? je comprends le point de vue de Lennart, et ça n'est pas la première fois que les *BSD sont laissés pour compte (suffit de voir l'état lamentable de X.org sur *BSD - merci, KMS & cie - où FreeBSD tente tant bien que mal de revenir sur cette régression fonctionnelle), je comprends que ça exaspère les *BSD-istes (dont je fais partie), mais quelle est la solution ? mettre des #ifdef partout au point de rendre le code non-maintenable à long terme ? (le but de systemd c'est à l'origine de se débarasser de TOUT les vieux hacks à la con dont certains plus personne ne se rappelle la raison d'être !), se limiter à un socle commun qui n'évolue PLUS ? ou bien de relancer le processus de standardisation autour de Posix ou bien d'un autre process de normalisation (Standard BSD and Open Unix-like Base ?) plus ouvert et plus aggressif ? Redynamiser le développement autour des *BSD faire contrepoids au tentaculaire Linux ?

sans ces emmerdeurs à vouloir des normes communes, ça serait tellement plus rapide d'innover...

Justement, pour la partie desktop, le coeur du problème est que les gens de BSD ne s'investissent pas assez dans les efforts de standardisations formelles (freedesktop) ou informelles (fournir du code, tester les projets communs).
Quant à la partie système, c'est bien de respecter les normes mais les seules évolutions qu'a connu POSIX cette décennie passée ont été: fusion avec SUS, toilettage de l'API, prise en compte d'IPv6 etc ... On peut ânonner POSIX jusqu'à la fin des temps ou bien se sortir les doigts du cul et utiliser des alternatives plus avancées.
Là ou Lennart marque un point, c'est que les normes se basent sur les innovations proposées par les différents participants, or la plupart des innovations se font dans Linux (ou GNU dans un contexte plus large) qui est devenu le standard de FAIT. Le problème c'est que POSIX n'évolue plus, donc soit on le sort de l'ornière, soit on crée un nouveau groupe de standardisation sur le modèle fd.o (j'ose pas imaginer le niveau trollesque d'une liste réunissant quotidiennement de Raadt, Trollvalds, RMS etc ...) pour collaborer plus étroitement.

Sinon pour revenir au sujet principal:
* systemd n'est pas un bloatware: la portabilité à tout prix a un coût, le choix du linux-o-centrisme a été fait pour éviter justement que systemd devienne un bloatware.
* le choix de D-Bus: D-Bus est un protocole qui s'appuie sur un IPC plus que standard: les sockets BSD. En plus, systemd s'appuie sur une toute petite lib, rien n'interdit de la réimplémenter, si elle est trop bloated.
* Lennart n'a rien contre la portabilité et les standards, au cours du développement de systemd, il a rapporté plus de bogues au FHS à lui seul que la majorité des distros ces dernières années. Le but n'est pas de péter FHS mais de corriger ces lacunes et de standardiser ça au lieu que chaque distro fasse son hack dans son coin comme c'est le cas actuellement. Au final, systemd contribuera a simplifier le boulot de ces feignasses de sysadmins sous GNU/Linux (quant aux BSD, ils utilisaient déjà leurs propres init donc ça change pas grand chose de ce côté là)

Quand le développeur s'appelle Airbus, le client la République Démocratique Populaire de Chine et le commercial Nicolas S. on appelle ça un transfert de technologie ...

c'est évident: moi !

c'est le gestionnaire d'ipod & cie le plus complet qui existe dans le monde libre. Sinon, la plupart des lecteurs type amarok, rhythmbox arrivent à se démerder.