zul a écrit 443 commentaires

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.

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.

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 ?

Hack ce n'est pas en soit péjoratif, sale hack par contre :). Bref, j'ai l'impression que c'est assez coûteux à maintenir comme système, vu que les patchs ne rentrent à priori pas dans ports. Je ne sais pas précisément comment se fait la synchronisation des sources entre ports et dports, mais je pense que sur le long terme, ça risque d'être pénible, c'est dans ce sens que je pense que ça me parait une méthode coûteuse (en temps, en homme). D'autant plus qu'un certains nombres de développeurs DragonFly se sont investis dans pkgsrc. Après, ce ne sont évidemment pas des compétences perdues.

Après, comme je le disais, du point de vue de la gestion des binaires, pkgng est probablement largement supérieur. pkgsrc, y'a src dedans :) et la question des binaires est toujours problématiques même sur NetBSD. pkgin semblerait être une solution à ce genre de problèmes, je ne l'ai pas assez utilisé pour avoir une opinion fondée sur la question.

Le système de pkg officiel de DragonflyBSD reste pour l'instant pkgsrc. Dports est un hack des ports FreeBSD pour que ça fonctionne sur DragonFlyBSD. L'intérêt principal est, d'après ce que j'ai compris, de pouvoir utiliser les outils de gestion des paquets binaires pkgng, qui semblent être meilleurs que ceux offerts par pkgsrc (pkgin entre autre), en particulier pour la mise à jour du système. Difficile à dire comment ça va évoluer, ça dépendra de combien de développeurs vont contribuer à dports et quelles parties vont être remontées dans le système de ports officiels de FreeBSD. Mon avis personnel est que le jeu n'en vaut pas la chandelle, et qu'il aurait mieux valu améliorer les outils de gestions binaires de pkgsrc. M'enfin, c'est la beauté du libre :D

HTTPS commence a être connu (et simple, sauf pour LinuxFr ;-) ), mais pour les emails, le chiffrement de bout en bout, c'est la galère :(.

GPG marche pas si mal pour chiffrer des emails.

Gdb, valgrind ou printf (ou système de logging approprié), tout dépend du système à débugger!

Tu peux me répondre à rien, évidemment, mais quel est l'avantage d'avoir développer ce logiciel dans firefox (que ce soit un plugin ou une application externe qui dépend de xulrunner). Est-ce que cette plateforme a un avantage quelconque par rapport à d'autres choix techniques (applis Qt (C++ ou Python) par exemple) ?

Comme benchmark :
http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
Lisaac a été premier de ce benchmark quelque temps avant que les téchniques soient copié pour les code C et C++.

Un seul benchmark ne prouve pas grand chose. De plus, d'après la suite du commentaire, les différences ne viendraient pas forcément des optimisations permises par le langage mais l'algorithme utilisé (à moins que ce soit les optimisations qui étaient reprises dans g++). Haskell (enfin surtout ghc) arrive à battre le C (gcc) sur un ou deux benchmarks bien choisis, mais personne d'honnête n'irait prétendre que Haskell bat les performances de C.

À un moment, il faut être réaliste aussi. Ça fait des années qu'un "smart enough compiler" va arriver au niveau des performances du C. En pratique, ce n'est pas encore le cas (même si je crois personnellement que c'est possible). Pas la peine de vendre du rêve! Peut être que Rust va arriver à quelquechose de ce point de vue là.

C'est que tu te surnotes mon petit :). Le commun des développeurs C++ c'est plutôt vers 3 ou 4. Les templates ça n'a rien de difficile en soit, c'est juste que c'est une approche différente de l'approche 'OO avec classes' classiques.

Et franchement, ça (les visiteurs), c'est facile par rapport à des choses comme boost::proto, boost::spirit, nt2, et autres trucs vraiment poilus. Bref, soit les gens qui développent ça sont à 17 sur 10, soit ton échelle de valeur est cassé :).

Tu parle du hack fait pour gérer le FTP passif qu'il faut activer manuellement. Tu en connais d'autres ? (mis à part « yakafocon ») C'est une vrai question.

find /lib/modules// -name "*conntrack*"

mais oui, évidémment, ça le fait au niveau système. Pour le faire au niveau process, on peut utiliser les solutions évoqués plus haut pour refuser le connect selon des listes banches | noires. Évidemment, quand il y'a k "processus" dans un processus, bah on est obligé de le faire au niveau dudit processus et de tout réiventer. Mais bon, d'après moi, c'est déjà une "erreur de design" à la base qu'une application gére ses "tabs" en interne (uzbl, uzbl … :)). C'est au noyal de gérer les différents processus, et au wm de gérer les différentes fenêtres.

Cool ! C'est quoi l'alternative ? Chaque jeu développe son protocole qui est chiffré par SSL (ou truc plus exotique) et qui inclus les pub au sein même de son flux normal ? Tu as quoi pour te protéger d'un skype (tout en t'en servant) ?

Parce qu'il ne va pas se passer exactement la même chose, sauf qu'au lieu d'être encapsulé dans un paquet tcp, il sera encapsulé dans un paquet http (ce qui est déjà la technique générique pour essayer de bypasser les firewalls).

Tu gagnera bien plus à utiliser soit les fonctionnalités de ton navigateur soit un proxy http qui fait ce que tu lui demande (et qui est capable d'aller inspecter le contenu si tu en a besoin).

Tous les firewalls peuvent faire plus ou moins de l'inspection de paquet aussi (cf les hacks ftp par exemple)., je ne vois pas particulièrement l’intérêt de passer par un proxy http. Y'a même des choses en dehors de http dans la vie.

Quand aux autres problématiques que tu évoqués, le Michu moyen (ne soyons pas sexiste), il n'y comprend de toute façon rien, donc soit réponds oui à tout, soit désactive juste tout.

Pour les fonctionnalités du navigateur, elles font surtout doublon avec un tas de trucs qui existent déjà dans ton système d'exploitation. Mais bon, un navigateur c'est moderne, c'est cool et au diable l'esprit unix !!!

ça pointe vers des jeux flash, c'est normal?

Et on a pas attendu les applications dans le navigateur pour filtrer ce qui entre et ce qui sort d'une application ("firewall applicatif", "systrace", "selinux",…). Évidemment, si tu as un contenu bien chiffré et qui passe tout par un proxy, il n'y a pas grand chose à faire, mais je ne vois pas bien ce que le navigateur peut faire de mieux.

Et tu peux évidemment utiliser des logiciels libres, ce qui évite tout déboire (on pourrait dire la même chose sur le web évidemment, même si par définition, on a beaucoup moins de contrôle sur ce qui est téléchargé puis exécuté).

on nous a déjà vendu ça avec un langage avec vm, bytecode et dont le nom commence pareil.

Ce n'est pas forcément le nombre de ligne de code qu'ils ont écrit en 68 jours, c'est le nombre de ligne de code qui sont rentrés dans le noyau de linus :). Certains patchs peuvent être à priori plus vieux, tout dépend combien de temps / étapes ils ont mis avant d'arriver dans le noyau mainstream.

Y'a des langages modernes, typées fortement (avec inférence de type) et compilés aussi tu sais.

A priori, c'est un noyau Freebsd. Mais j'ai du mal à voir l'intérêt quand même, la ludothèque de FreeBSD est riche, la documentation est bonne, et je pense que le principe de simplicité sont déjà au coeur de l'approche. Il me semble plus efficace à ce niveau d'apporter de la main d'oeuvre et des améliorations à port. Mais il y'a peut être quelquechose que j'ai raté (ou probablement juste "we can do it").

Pour information, NetBSD utilise les plist pour certaines choses, aussi bien dans le noyal que dans l'userland, entre autre pour échanger les données via une méthode standard. Divers outils proposent des sorties plist xml directement, en plus des sorties traditionnelles "line based".

Dans le labo où je travaille, on paye un certain nombres de licence de matlab pour le labo, avec des jetons. Mais bon, souvent, les thèsards qui l'utilisent finissent par installer une version crackée plutôt que d'attendre désespérément qu'un jeton se libère.

Après, on est d'accord, 90% des trucs qu'ils font, ils pourraient le faire avec scilab. Mais bon, la majorité ne savent même pas que ça existe. Pour le reste, ils utilisent des toolbox pour matlab qui coûte un bras, et qui sont certainement plus difficilement à 'porter' pour des systèmes concurrents libres.

Quatre ans donc pour sortir une version mineure. C'est vachement dynamique comme développement.

La numérotation ça ne veut pas dire grand chose. Il y'a quand même un paquet de modifications importantes, même si évidemment ça ne révolutionne pas le monde des langages de programmation. Mais un modèle objet + une réécriture du modèle d'exécution + une gestion des exceptions, ce n'est pas "mineur", même si ça reste très 20e siècle :D On peut noter qu'il y 'a encore un paquet de langages "modernes" qui ne sont pas foutu de faire du TCO. L'approche concurrente parait consistante avec le reste du modèle TCL.

Après, à savoir si les personnes qui développent 'activement' en tcl sont vraiment intéressé par un modèle objet, j'ai quelques doutes (dans ceux que je connais en tout cas).

Est-ce que tu as ouvert un problem report ?

Marrant, l'installateur de vlc pour Windows disponible un peu partout ne marche que sur x86. Si on cherche un peu, on finit par trouver un installateur expérimental (qui en pratique à fonctionner) pour x86_64. Mais c'est loin d'être complètement trivial (et à mon avis pas mal d'utilisateur de 7 sur x86_64 sont soit passé à autre chose, soit rester à la v1 vu que c'est bien un des rares softs qui ne marchent pas via la compatibilité x86).

En dehors du man associé qui m'a l'air plutôt bien fait, on peut trouver un papier présenté à AsianBSD sur les motivations / choix / limitations (http://www.openbsd.org/papers/asiabsdcon2010_sndio.pdf). Il y'a aussi les slides de la présentation (http://www.openbsd.org/papers/asiabsdcon2010_sndio_slides.pdf) et la vidéo associée (http://www.youtube.com/watch?v=Wcro3UliMZ4). Depuis le papier, il semble entre autre qu'ils aient implémenté la partie réseau.

En plus de savoir faire la même chose que date(1) et/ou TZ, il sait faire la même chose que hostname(1). Whoot, j'en suis ébahi :). Et sérieusement, dire que ce ne sont pas des outils standards, c'est un peu se foutre de la gueule du monde, c'est quand même un poil plus ``standard'' que la nouvelle API freedesktop implémentée par un seul fournisseur.

Faudrait que vous vous mettiez en phase, car vous dites tout et votre contraire dans les idées que vous avez. C'est illisible comme position.

Le FdG veut une démocratie plus parlementaire (+ de pouvoir à l'assemblée, - au président donc) et développer la démocratie participative (vrais référendum d'initiatives populaires, proposition de lois directement par des groupements citoyens …).

Après c'est comme dans tous les partis, chacun comprend un peu ce qu'il veut comprendre des discours du parti auquel il adhère. Tu as encore plus de cacophonie dans des gros partis comme l'UMP ou le PS, où des gens de sensibilité, plutôt de gauche ou plutôt de droite (par rapport à leur parti) verront soit noir, soit blanc (pour une même déclaration). Critique le FdG uniquement sur cet angle, c'est, à mon avis, complètement non constructif.

Comment définis tu ce qui est extrême de ce qui ne l'est pas ? Parce que si c'est sur la capacité au dialogue et au compromis, je pense que tu peux classer l'UMP dans extrême aussi.

Quand à savoir si le FG peut faire des compromis, je ne saurai dire, je ne fais pas parti des dirigeants. Après, vu ce qu'il y'avait en commun entre le PS et le FG, je vois mal comment on aurait pu faire un compromis sur les programmes (à la rigueur sur la partie sociétal). Se proclamer de gauche ne change pas un programme économique ``libéral'' en un programme socialiste (au sens premier du terme).

Ecrire des specifications comme par exemple celle d'opengl ou du c99 pour TTM/GEM/KMS ... n'a aucun sens. Fondamentalement le coeur de TTM/GEM/KMS n'a pas cesse de changer. Mais l'interface expose est toujours la meme. Un simple uint32_t (et voila je peux meme plus faire le feignant et utiliser u32) qui identifier de maniere unique un buffer pour TTM/GEM et un moyen de mmap a partir de cette uint32_t. C'est tout ce que demande l'userspace.

Parfait, je veux bien te croire, je n'ai parcouru que très superficiellement le code de drivers/gpu/... Mais connaissant quelques développeurs X, et vu comment les projets BSD ont du mal à arriver à merger un driver pour une carte graphique moderne, j'ai quand même tendance à penser qu'il y'a un problème quelque part (évidemment, on peut supposer que les développeurs BSD sont des gros nuls, mais je ne suis pas convaincu par cette hypothèse).

Par ailleur je tiens a preciser que tout le code TTM/GEM/KMS est double license GPL/BSD. Donc oui vous pouvez regarder le code et meme le copier.

C'est vrai :) C'était une pique gratuite pour les fois où j'essayé de debugger les drivers des cartes wifi intel. Dans le cas des interfaces gpu, ils ont eu le bon goût de garder un peu de cette bonne vieille license BSD.

Sinon, la doc des interfaces noyal mémoire de NetBSD est sur http://netbsd.gw.com/cgi-bin/man-cgi?memoryallocators+9+NetBSD-current (et ses copains uvm(9), pmap(9), vmem(9) ...). C'est clairement pas aussi précis que ce qu'on pourrait espérer mais c'est toujours bien mieux que "rien" ("prendre un uint32_t et magie" :)).