Bapt a écrit 772 commentaires

systemd on s'en fout total
pour kms:

# kldstat | grep kms
12    1 0xffffffff819b8000 6941e    i915kms.ko
# xdriinfo
Screen 0: i965
# uname -s
FreeBSD

bon il est vrai que kms/gem c'est une vrai merde à porter et surtout à maintenir.

btrfs je n'ai jamais entendu qui que ce soit à qui ça manque sous FreeBSD? si quelqu'un le veut il suffit de le porter sous forme de module.

Bref, pas un soucis.

seul libudev me pose soucis, parce que beaucoup de monde s'appuie dessus directement (sans abstraction) et que libudev est clairement pensé linux-only (exposant le matériel et les évènnement a la linux)

Avec un peu de courage plonger pour dans sysfs (très mal documenté) et comprendre comment sont exposer les infos dans libudev et le support serait possible, c'est juste pas motivant du tout et surtout on se demande dans combien de temps ça sera déprécié, ou refactorer rendant incompatible le portage.

pour le 2/ parce que AMQP est une énorme usine a gaz, et que pour ça justement ZeroMQ semble 10 fois plus approrié (en ne s'occupant que de la com)?

et puis sérieux qu'est ce qu'on s'en fout le dev estime que c'est bien de fournir une nouvelle version il la fournit c'est tout.

pour ceux que ça intéresse la version 2.4.0 est dispo dans FreeBSD: sysutils/dfc http://www.freshports.org/sysutils/dfc/ il manque juste le support des options de montage (EFLEMME) mais je le ferai plus tard.

Pour information on fait la même choses sous FreeBSD depuis un moment: http://wiki.freebsd.org/PortsAndClang avec des résultats plutôt meilleur que ce à quoi on aurait pu s'attendre, biensûr nous remontons aussi upstream les patchs et généralement ils sont bien accueillis.

xmlstartlet ça permet de maniper le XML presque comme un fichier texte normal que tu manipulerais simplement en cli :)

Au passage voici le planing pour la devroom BSD

http://wiki.freebsd.org/201202DevRoom

Non il n'y a pas encore de dépot mais ça ne va pas tarder :)

Considérant la vidéo elle est vieille, maintenant c'est encore mieux :D (la lenteur sur la vidéo est du au fait que le test est fait sur un vieil eeepc :)

oui ça prend en charge les jails, et bien plus

teaser: http://github.com/pkgng/pkgng et http://wiki.freebsd.org/pkgng

tu as aussi cdr dans zsh pour complémenter les hash -d (qui lui est dynamique) et ressemble un peu, l'avantage c'est qu'il se couple a la completion zsh du coup tu cdr [tab] est d'une convivialité absolue.

Je n'ai jamais testé autojump parce que cdr répond parfaitement a mon besoin de ce côté.

Dispo depuis zsh 4.3.12.

sous freebsd (pour 3.2) mais ça n'est pas encore dans les ports parce que la RELEASE 9 est imminente.

Mwai, les devs BSD ne proposent rien pour le faire donc c'est de leur faute...

tu sors ça d'où ???
on voit que tu connais bien ton sujet toi...

Pas du tout je dis que souvent (pas toujours) on l'a depuis longtemps cette interface et en version propre.

Parce que le problème c'est que la libudisk est freedesktop (donc soit-disant OS-agnostique) qu'ils poussent tout le monde à l'utiliser, mais si tu pousses un peu tu te rends vite compte qu'elle est incomplète et qu'il faut basculer sur la libudev pour vraiment l'utiliser.

Or ni libudev ni libudisk ne documentent ce qu'ils attendent, donc en admettant que ça se limite à la libudisk, ça reste linux-centric et non documenté et insuffisant pour remplir son rôle sans rentrer un minima dans la libudev qui souffre de la même chose, mais osef si libudisk fait tout ce qu'elle est censée faire.

je parle de la libudev et de la libudisk pas de udevd désolé de ne pas avoir été assez précis

Oui, mais en attendant d'en avoir une propre sous FreeBSD, bah on n'a rien

Tu pourrais donner des détails parce que la plupart du temps on a déjà quelques choses (contrairement au FUD) mais plutot que de faire quelque chose de portable RH (il n'y a pas que RH dans le monde linux qui fait ça) fait du linux centric et du coup on rame pour en faire un portage sur freebsd.
Alors que si le code était bien fait (genre interfaces propres à remplir selon les OS et documenté) on n'aurait pas ces soucis (Je ne demande pas a RH de faire la partie FreeBSD juste de prévoir des interfaces propre et de prévoir la doc du comment qu'on cause au merdier).

(/me fait coucou au fucking udisk/udev autres saloperies de merde linux-only et non documenté!!!)

en zsh il y a encore plus simple:
zargs **/*.c -- commande

tu peux aussi choisir le nombre de processus en parallèle:
--max-procs=max-procs, -P max-procs
le nombre d'arguments à filer à la commande:
--max-args=max-args, -n max-args
et beaucoup plus
Un super xargs quoi mais tu peux le combiner avec les fonctionalités avancées de zsh donc top
pour en bénéficié: autoload -U zargs dans le .zshrc :)

La seule et unique raison du refus de la GPLv3 est que l'on n'est pas des juristes et que cette licence est complètement imbitable donc on ne sait pas les risques que l'on fait encourir ou non a nos utilisateurs quelqu'ils soient et quelque soit la manière dont ils utilisent FreeBSD.

il existe une technologie qui dure plus de quelques mois sur Linux?

c'est plus pertinent comme ça ta question

</bav>

pb n°1 : on veut comprendre les licenses que l'on utilise, or la GPL est imbittable si tu n'es pas juriste et compliquée si tu es un juriste.

pb n°2 : on n'aime pas que l'on nous impose une license or quand tu te link a du code GPL la license est GPL est imposée a ton binaire (les GNUistes ont la LGPL pour éviter ça mais certains ne le comprennent pas genre libreadline)

La v2 des gens pouvaient encore espérer la comprendre, la v3 est juste totalement imbittable. Les seules personnes qui pensent l'avoir entièrement comprise sortent tout droit de l'asile d'arkham.

Sinon la majeure partie des BSDistes que je connais se fichent complet de la license GPL.

Encore moins un humain capable de la comprendre

merci

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

Elle est où la spec de libudev (au moins udisk d'ailleurs) ? Je parle bien de spec complète histoire que pour implémenter libudev sur FreeBSD je n'ai pas a deviner ce que Linux ferait dans son /sys et tenter de transformer les identifiants de matos FreeBSD en équivalent /sys ?
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 ?"

Surtout que dans le principe on n'avait pas besoin de libudev c'est pas comme si sur le papier libudev nous apportait quelque chose qui nous manquait... Donc aller participer a du dev linux sur quelque chose qui fournit un fonctionnalité que l'on a déjà...

Bref.