ErrTu a écrit 108 commentaires

Cette semaine, c'est la fête du compilateur !

- libjingle pour la VoIP peut-être (support google toussa) mais pourquoi Ekiga ne s'y associe pas ? quelle est la vraie divergence de vue ? c'est incompréhensible du point de vue utilisateur (kineveupacomprendre inside). Et la vidéo dans tout ça /o\

Je ne connais pas le développement d'Ekiga mais je crois que tu ne poses pas la bonne question, si question il y a. En fait ça serait plutôt une affirmation du genre : vivement que quelqu'un ressente suffisant le besoin de la prise en charge de libjingle dans Ekiga pour bosser dessus. Je pense que les développeurs d'Ekiga ont d'autres chats à fouetter en ce moment mais qu'ils seraient heureux de recevoir des patchs.

Arrête d'insulter l'intelligence des développeurs du libre s'il-te-plaît.

Vouloir forcer les développeurs à travailler sur des projets communs alors qu'ils ont des besoins et objectifs différents, cela ne marchera jamais. Oui, la plupart travaillent sur des projets pour leur plaisir ; si tu leur enlèvent ce plaisir, je pense que tu te priverais de pas mal de bons clients.

"Proof of concept" est probablement l'expression appropriée pour l'implémentation de fortran 77 dans PCC. Il n'y a pas d'autre langages supportés car personne n'en a suffisamment besoin pour mettre les mains dans le cambouis... ce qui n'est pas le cas pour le C99

Au niveau de la modularité, si on veut porter PCC vers une nouvelle architecture, on peut le faire en environ 5 000 lignes de codes. Chaque tâche de la compilation a bien été séparée de sorte que l'on puisse facilement échanger le backend (la partie qui produit le code machine) et le frontend (la partie qui analyse et traite la syntaxe du langage). Enfin bon ce disgn n'est pas nouveau puisqu'il date d'il y a 30 ans, pour en savoir plus : la présentation de l'architecture de PCC au NYCBSDCon 2008 : http://www.nycbsdcon.org/2008/files/magnusson_pcc.pdf

Bien évidement ce petit compilateur n'a pas du tout pour but de concurrencer LLVM car il ne répond pas au même besoin.

C'est surtout que PCC est limité au C alors que LLVM et GCC ont une architecture beaucoup plus modulaire et ont pour but de compiler beaucoup plus de langages.

C'est faux. PCC est très modulaire, ce qui lui permet de supporter "facilement" de nouveaux langages et de nouvelles architectures. D'ailleurs PCC est capable de compiler du fortran 77.

Au niveau des performances, voilà ce qu'en dit Anders Magnusson :
http://undeadly.org/cgi?action=article&sid=2008110813583(...)

C'est dommage que je sois en Corée, sinon j'aurais pu faire un peu de provoc' en me pointant avec un beau T-shirt OpenBSD.

OpenBSD ne supporte que le WPA/WPA2 en mode "pre-shared key" (PSK). Donc pas de EAP (ou "WPA Enterprise") et rien en vue à ce propos dans le CVS du projet.

Plus d'info sur cet article d'undeadly :
http://undeadly.org/cgi?action=article&sid=2008041619515(...)

wpa_supplicant est dans l'arbre des ports, mais ne marchera que sur un réseau filaire (Ethernet) et pas sur du wifi WPA.

Si comme moi vous avez essayer d'installer DotClear avec le "back-end" sqlite, il faut mettre le chemin vers votre fichier de base de donnée dans la variable DC_DBNAME et non pas dans DC_DBHOST, dans votre fichier inc/config.php.

C'est très bête comme erreur (surtout que c'est indiqué dans la documentation), mais ça m'a fait perdre une bonne heure en me retrouvant avec l'erreur suivante : "safe_mode/open_basedir prohibits opening" (qui venait du fait qu'il n'arrivait pas à ouvrir un fichier avec un chemin vide... ce qui est tout à fait normal en soit mais le message d'erreur aurait pu être plus clair).

Maintenant ça marche impeccable ; les développeurs m'ont l'air d'avoir fait du bon boulot.

Je vous invite à lire le billet "Source Wars" sur les blogs d'O'Reilly. C'est un entretien avec pas moins de 27 développeurs d'OpenBSD qui parlent des améliorations qui ont été faites dans la version 4.4 :

http://broadcast.oreilly.com/2008/11/source-wars---return-of(...)

(en Anglais par contre)

Lorsque l'on voit ce qui nous attend dans la version développement d'OpenBSD (-current), on se dit que la version 4.5 (à venir dans 6 mois) va être tout aussi bonne que celle-ci.

Une sélection en vrac :

- on a le droit au DRM d'activé par défaut pour les cartes radeon d'ATI et les cartes d'intel (ça veut dire de l'accélération 3D pour jouer à openarena qui est maintenant dans les ports), d'ailleurs le développeur à l'origine du port de l'infrastructure DRI sur OpenBSD en parle ici : http://undeadly.org/cgi?action=article&sid=2008102916422(...)

- l'outil aucat(1) peut maintenant faire office de serveur audio transparent grâce à la nouvelle bibliothèque générique d'accès aux matériel audio libsndio (facile à utiliser et puissante). La plupart des ports sont en train d'être patchés pour utiliser cette bibliothèque, après il suffit de lancer aucat en mode serveur pour avoir du multiplexage des différentes sources audio. Alexandre Ratchov en parle ici : http://undeadly.org/cgi?action=article&sid=2008102715134(...)

- un nouveau serveur mail vient de faire son apparition dans l'arbre des sources. Il s'appelle simplement smtpd(8) et sera beaucoup plus simple d'utilisation que sendmail car il emprunte sa syntaxe de fichier de configuration à pf. Pour le moment c'est encore en développement mais presque utilisable. Le commit : http://marc.info/?l=openbsd-cvs&m=122557555124170&w=(...)

Bref plein de choses palpitantes, et ce n'est pas fini...

Pour en revenir à la nouvelle version d'OpenBSD, la chose que j'apprécie peut-être le plus c'est la possibilité d'afficher les clés publiques sous forme d'ASCII art sous OpenSSH 5.1. Comme ça quand je me connecte sur mon serveur je sais que c'est bien mon serveur à qui je parle car sa clé publique est bien "un extraterrestre avec des antennes". Vraiment indispensable ^^

D'ailleurs Jason Dixon a encore frappé au NYCBSDCon 2008 avec ça nouvelle conférence intitulée : "BSD v. GPL".

http://talks.dixongroup.net/nycbsdcon2008/

On y retrouve que des bons ingrédients pour une excellente conf., mais attention ce n'est pas la suite de "BSD is dying".

Ça veut dire que ça lag.

C'est par ici pour envoyer tes patchs :
http://www.gimp.org/bugs/howtos/submit-patch.html

Un détail parmi ceux qui m'emmerdent avec jabber : pour parler à quelqu'un à qui on n'a jamais parlé auparavant, il faut lui demander son autorisation au préalable.

Ah non, cela n'est valable que sur les serveurs configurés pour avoir ce comportement (comme GTalk). C'est selon eux pour prévenir le spam... alors que l'on sait très bien que le spam du message privé est autrement moins dérangeant que le spam dans les requêtes d'autorisations.

Sur la plupart des serveurs, tu peux parler à qui tu veux comme tu veux.

Perso, j'ai vite abandonné mon adresse jabber.fr ...

Pourquoi n'as-tu pas monté ton propre serveur jabber avec les passerelles de ton choix ?

Et si pour certain le port 22 n'est pas assez compréhensible, on peut toujours utiliser les noms des protocoles dans /etc/services. Donc avec le port 22, ça donne :

pass in quick log on $ext_if from port ssh

ou irssi-xmpp dans un screen/dtach pour avoir Jabber.

Après pour du multi-protocole, il doit y avoir moyen de se bricoler un accès vers les autres réseaux via les passerelles jabber. Bon d'accord, un jour je plancherai sur la prise en charge des passerelles dans irssi-xmpp (ça doit marcher actuellement avec l'envoi d'une petite stanza xml via la commande /quote pour certaines passerelles).

Les peaux des typematrix ne servent généralement pas à grand chose si tu décides d'utiliser la disposition bépo par exemple. Elles ne sont alors utiles uniquement en cas de gros plantage pour rattraper l'affaire en QWERTY.

Pour ceux que ça interesse je vends mon TypeMatrix EZ-Reach 2030 sur ebay. Je m'en sépare car je pars à l'étranger et que je n'aurais pas d'ordi fixe sur lequel le brancher.

Si l'option n'est pas activée, c'est que généralement elle produit un comportement qui peut être instable. Il vaut mieux avoir un système stable qui fonctionne tranquillement qu'un système qui plante tout le temps.

Au hasard, tu peux déjà regarder dans les pages de man de pilotes de ton chipset : radeon(4), intel(4), ...

Personnellement j'ai viré l'espace insécable de ma disposition bépo car c'est assez agaçant de les voir apparaître dans le code source de mes programmes que gcc refusera alors de compiler (je les tapais régulièrement et sans y faire attention avant ou après l'appel à une macro en majuscule). Gcc n'aime pas voir des caractères unicode ailleurs que dans le commentaires.

De plus je ne tape les espaces insécables que sous latex, et dans ce cas là, l'espace insécable se représente par "\~".

OpenSSH est compatible GPL, si tu veux tu rajoutes un saut de ligne à chaque ligne de code et tu peux alors mettre OpenSSH sous GPL et tu nous fous la paix .

En fait non, tu ne peux pas changer la license des fichiers du code source d'openssh. Seul les déteneurs des copyrights peuvent le faire. Donc malgrès que ton fork d'openssh soit sous GPL, le code source que le compose restera sous license BSD.

Oui, le clavier bépo, c'est mieux.

Pour wpa_supplicant, d'être sous licence GPL par exemple.