Bapt a écrit 772 commentaires

C'est assez simple, poudrière, load presque tous les sous-systèmes de ta machine:
- La vfs,
- La VM,
- Le CPU,
- même les tty :)
- beaucoup plus,

Du coup tu te retrouves avec un serveur stressé dans tous les sens de manière pratiquement impossible a avoir autrement. Ce qui faire apparaitre des bugs, des races conditions etc qui ne serait pas visible autrement.

Sous FreeBSD par exemple, beaucoup de problèmes de contension de la VM ont été découvert, des problèmes de dead lock zfs, tmpfs, nullfs etc.

Sous Dragonfly je n'ai plus les détails, mais beaucoup de bugs on aussi pu être découvert et corrigés.

sous zsh tu as zparseopts qui est assez magique aussi :), man zshmodules pour plus d'infos

Juste pour info, PC-BSD utilise pkgng pour toutes les applicatifs "de base" (X, kde, etc). Ensuite rien n'empeche d'avoir des PBI-like sur pkgng. des PBI ce sont juste de bon gros flat packages, sans dépendance, j'ai déjà fait un PoC pour faire de PBI avec pkgng, du coup tu n'a qu'un seul gestionnaire de package pour gérer les paquets traditionnels et les PBI.

Pas du bash, du shell sh! c'est pas du tout pareil :)

Ah libsolv :), biensûr que l'on y a pensé très fortement même, libsolv c'est génial ça fait tout ce qui fait mal a la tête pour toi et ça le fait bien, en plus ils sont une license amicale.
Depuis le début du projet j'ai libsolv en tête, et je compte bien l'utiliser. Mais au final libsolv c'est assez intrusif: c'est libsolv qui gère les repo, du coup il faut apprendre a libsolv comment utiliser les repo pkgng, il faut aussi lui apprendre toutes les spécifités de la politique de packaging de l'OS. Bref si on si on utilise libsolv, il faut faire les choses à la libsolv et modifier libsolv lui même pour se faire., disons que à mon gout libsolv n'est pas assez générique, j'aurai aimé le même genre de bibliothèque, mais qui apprennent les spécificités via des callbacks par exemple.

La dernière chose c'est que les structures représentant les packages dans libsolv n'est pas compatible avec les structure représentant les paquets de pkgng (du a des méta donnée de "transition" mais indispensable que l'on a du introduire dans pkgng pour permettre la migration progressive).

Je regarde toujours libsolv du coin de ligne, mais disons que pour le moment ça ne colle pas encore :)

Les principales raisons qui m'ont été données par les entreprises qui m'ont contacté :
- Simplicité pour remonter les patchs, avoir un seul upstream unifié pour tout ce qui concerne la base de l'OS est très pratique.
- Simplicité pour produire des images embarquées avec nanobsd.
- POLA (politic of less astonishment) qui signifie que l'on ne casse pas tout du jour au lendemain et que si on casse ont prévoie des procédures de migrations le plus simple et automatique possible.

J'ai reçu plein d'autres raisons mais celles ci sont les raisons majeures.

Parmi les raisons qui m'ont été données qui les font envisager de quitter Linux:
- instabilité des composants (dans les sens ont casse tout et ont recommence.) par exemple udev ses nombreuses cassures de compatibilité, ou encore les hal->devicekit->udev ou encore les systèmes d'init, chez redhat par exemple: scripts -> upstart -> systemd. Beaucoup sont perdues et se posent des questions quand à la pérennité de leurs développements (si je me base sur une brique logicielle, va t elle perdurée, va elle rester compatible, etc)
- trop de "fanatique", les entreprises n'ont pas le temps de mettre en place une infrastructure pour contribuer leur code qu'elles se font déjà harceler. Pour beaucoup ce n'est pas quelque chose de naturel de contribuer le code, elles sont volontaires mais il faut leur laisser le temps de s'organiser.

L'arrivée de pkgnsg et la simplicité de déployer des repos maison est souvent l'excuse qui leur a fait franchir le pas (encore une fois pour celles qui m'ont contacté.)

La license BSD est rarement la raison majeur pour s'intéresser a FreeBSD, Les seuls cas que j'ai rencontré où la license BSD était évoqué concerne des entreprises dont les avocats (pour celles qui en avaient) n'étaient pas capable d'expliquer de manière simple et concrete pour un humain normal ce que la license GPLv3 leur imposait de faire ou non, si il y avait des risques pour eux ou non, parce que la license est trop compliquée. Ces mêmes entreprises avaient précédemment fait la même démarche pour la GPLv2 et l'acceptaient sans soucis.

Dans tous les cas que j'ai rencontré, ces entreprises souhaitent contribuer en retour!

pkgng ne sais pas compiler des ports, mais les ports savent un minimum gérer les paquets en utilisant pkgng justement :)

Nix a l'air bien tout ça tout ça, mais il ne faut pas oublier une chose: l'historique.

Il nous fallait prendre en compte l'historique de FreeBSD et permetter une évolution la plus douce possible vers le nouveau système de packages et du coup ça nous as beaucoup limité techniquement nous empêchant de faire quelque chose de comparable a Nix.

Enfin nous avons l'arbre des ports dans lequel sont déjà porté 25 000 packages, ce qui nous apportent du bon et du mauvais, le bon: déjà 25 000 packages possible dès de début, rien de mieux pour confronter son outil a des cas tordus. désavantage nous avons tu faire des choix techniques limitatif pour rentrer dans les clous de l'arbre des ports, enfin les clous je les déplace beaucoup ces derniers temps pour assouplir tout ça :)

La raison de la non publication des repos officiels pkgng est politico-humano-bla

A savoir techniquement le projet ne veut maintenant diffuser que des repos signés, mais qui dit signature dit infrastructure de signature, politique de revocation etc et là c'est la merde :)

Donc techniquement on peut le faire mais en pratique bah…

Sinon si vous mettez:
packagesite: http://pkg-test.freebsd.org/pkg-test-${ABI} dans vos /usr/local/etc/pkg.conf vous avez des répos dispo :)

La bibliothèque fournie est minimaliste recodée la notre était tout aussi simple permettant surtout de bien l'intégrer dans pkgng.

C'est la norme que nous avons suivit pour définir notre nouveau solver car nous voulons respecter les standards au maximum. Donc oui pkgng 1.2 sera capable d'exporter ses informations dans ce format.

Les ports fonctionnent très bien avec pkgng pour info, les fan des ports peuvent continuer a les utiliser avec pkgng.

Pour les différence entre les formats je pense sincèrement que ça n'est pas très important, pour les format de dépôt aussi, il n'y a pas vraiment de diff entre yum/apt/pkgng a ce propos si ce n'est les briques techniques utilisées et je ne pense pas que la valeure ajoutée soit très importante a ce niveau là.

FreeBSD dispose déjà d'un système de paquet binaire depuis 1993, mais il n'était pas top :)

oh le vilain markdown c'est tout en gros et gras on dirait que je gueule, un admin pourrai corriger svp?

Un bon logiciel (pas trop linux centric) devrait compilé sur toute plateforme relativement unix, avec un Makefile minimum, port ou pkgsrc. Le problème sous-jacent, c'est imho la portabilité des logiciels.

J'aime la théorie, la pratique est très loin de là.

Mon interrogation concernait surtout la méthode de synchronisation entre ports et dports. Par exemple, firefox est rentré dans ports il y'a deux semaines, mais n'est pas encore dans dports. Une synchronisation semi-manuelle entre les deux dépôts me parait extrêmement coûteuse en temps (et extrêmement rébarbatif aussi), surtout pour quelques hommes. De plus, en regardant rapidement le dépôt github de dports, je vois beaucoup de 'tweaks xxx', ce qui me laisse penser qu'il y'a quand même une certaine adaptation à faire.

C'est la même chose qu'avec pkgsrc ici, quand une mise a jour entre dans pkgsrc, elle ne passait pas non plus forcément sous dfly, donc le problème est identique. de plus dports fonctionne avec un système de as, seuls les ports ayant passé ce sas sont synchronisés, aka, seul ceux qui sont passer a travers une machines de build en cleanroom (poudriere) avec succès sont synchonisés, c'est pour ça qu'il y a 2 git dans dports.

Concernant poudriere, vu que je vois que tu as travaillé dessus, est-ce que tu peux me dire qu'est qu'il fait qu'il est beaucoup plus performant qu'un pbulk ? Est-ce que ça serait dur de le porter à pkgsrc ou au contraire est-ce que ça utilise des features extrêmement spécialisés de ports ?

Oui je peux le dire, par exemple sur une machine avec 24 core et 100G de ram je suis capable de compiler l'intégralité du ports tree en 18h chose qui est totallement impossible avec pbulk.
Par défault si tu as 24 coeurs alors tu auras en permanence 24 packages qui compile en parallèle, le code a été vraiment travailler pour la performance (oui c'est possible en pure shell posix).

Je suis l'auteur de poudriere (et de pkgng) , donc si quelqu'un veut porter poudriere pour pkgsrc, c'est avec plaisir que je lui fournirai l'accès au répo fossil ainsi que les input pour le faire.

Poudriere dispose de spécificité ports/freebsd mais facilement contournable et reste bien générique. par contre attention il stress vraiment très fort l'OS dans tous les sens (un petit peu moins violent maintenant), du coup tu risques d'avoir des surprises :), en 5min il crachait le kernel dragonfly au début du portage :), il a permit de trouver des races conditions dans l'OS absoluement partout :), sur un NetBSD j'avais fait un portage rapide il y a longtemps, et je suis tombé sur un deadlock dans le fs (corrigé depuis si j'ai bien compris) très très rapidement. Si tu arrives a le porter tu verras toi même la différence avec pbulk :)

#poudriere (anglais) sur freenode pour en discuter si tu veux.

DPorts est beaucoup plus simple a maintenir pour les gens de Dragonfly que pkgsrc, et les outils autours des ports permettent un très grande simplicité. Pour info, l'auteur de dports a maintenant un commit bit dans les ports FreeBSD, ce qui devrait grandement faciliter les choses.

Parmis les motivations qui a poussé DPorts il y a justement la facilité du portage, DragonFly reste relativement proche de FreeBSD, il n'y a donc pas grand chose a faire pour qu'un ports FreeBSD compile correctement et tourne sous DragonFly, il suffit de rajouter à cela poudriere et pkgng et la différence pour les gens de DragonFly est énorme.

Pour info poudriere c'est une sorte de 'pbulk' mais extrêment performant, et hautement parallélisé (a tel point qu'il a mit en avant énormément de bug DragonFly - kernel, fs, tty, réseau, etc - qu'il a fallut corriger pour pouvoir faire tourner une construction de package complète aka tout le ports tree sans cracher l'os) Cet outil permet très rapidement sur une machine un peu costaud de construire tous l'arbre des ports.

Le résultat a été qu'ils ont pu bénéficier de plus de 20k packages en quelques mois de boulot d'un seul mec ! Chose que ce même gars n'a pas pu obtenir avec pkgsrc. En ce qui concerne les aller et retours, les ports FreeBSD bénéficient déjà de retour venant de dragonfly: bug fix et idée issues de l'expérience de l'auteur en question sur pkgsrc.

En ce qui concerne pkgng, ça leur a permit d'avoir un outil qui fait la gestion complète des packages binaries sur dragonfly, l'adoption par les utilisateurs de DFly n'a pas tardé.

Les statistiques sont assez flagrante et une très grosse partie (je pense la grande majorité) des utilisateurs de DragonFly sont passés a dports+pkgng.

Bref c'est surtout parce que justement il est plus simple de maintenir d'un point de vue humain dports que pkgsrc sous dfly que le switch a eu lieu.

Pour info l'auteur de dports continue a travailler sur pkgsrc et aime toujours pkgsrc :), il envisage même de pouvoir générer des packages pkgng avec pkgsrc, en tout cas il se pose la question de la faisabilité.

Non le vrai linker llvm est/sera http://code.google.com/p/mclinker/

Le lien poudriere pointe sur http://en.wikipedia.org/wiki/Advanced_Vector_Extensions au lieu de pointer sur https://fossil.etoilebsd.net/poudriere

Ça n'a rien d'étonnant, pkgin c'est pour pkgsrc, et ça fonctionne au dessus des pkg_tools.
pkgng c'est pour les ports FreeBSD (ici DPorts) et ça remplace les pkg_* tools. Les repos binaires pour pkgng sont fermés depuis 6 mois, parce que l'on a décidé de reconstruire toute la chaine de distribution de packages et ça ne se fait pas en 2 jours (avec tous pleins de trucs fashion et tout).

En attendant PC-BSD propose des repos binaries pour FreeBSD 9.1 qui fonctionnent très bien et http://mirror.exonetric.net/pub/pkgng/README.txt propose des paquets binaires pour toutes les versions supportées (8, 9 et 10) pour i386 et amd64.

Sous BSD on sait très bien gérer ces logiciels tiers, pkgng utilise toujours la même infra (les ports) pour la construction de packages, pour l'utilisateur final, il y a peu de changement de passer de pkg_install (tous les vieux pkg_) a pkgng si il utilisait les ports.

Qu'est ce qui est inutilisable je l'utlise tous les jours sur des 9.1-RELEASE, 9-STABLE et 10-CURRENT ça marche très je n'ai rien eu a déplorer. En quoi VESA est mieux?

Ce qui prouve qu'il n a rien compris a pkgng, parce que avec pkgng aussi tout peut se trouver dans des paquets binaires.

Ca m'interesse vraiment son avis sur pkgng mais je ne trouve aucun lien

Pour info il me faut environ 1 min pour faire en sorte que makepkg puis generer des paquets binaire pkgng au lieu de pacman

Le projet a été abandonné parce que a l'époque où le portage a été fait, la licence ne convenait pas, le changement de licence de launchd a eu lieu après, mais voila depuis personne ne s'est repenché sur launchd sérieusement.

Je pense également que FreeBSD souffre beaucoup d'un certain conservatisme dans ses réglages par défaut

Ça serait intéressant que tu donnes des détails là

C'est ce qu'essayent de faire les devs pkgconf, mais ce n'est pas gagné :)
http://lists.freedesktop.org/archives/pkg-config/2012-September/000884.html

Au moins la partie fichier .pc au niveau spec ça a l'air de faire son chemin, mais pour la spécification de la commande ce n'est pas gagné

Malheureusement ça n'a pas été mergé dans la 9.1, donc ce bout de code ne sera de retour "que" pour la 10.0

Peut être 9.2 si quelqu'un insiste pour demande le merge :D

C'est toujours bon à savoir… Donc il le mettent pas dans le noyau parce qu'ils :

• En ont rien a foutre, et importer du code linux donc les APIs sont instables c'est hyper chiant a maintenir.