Benjamin a écrit 796 commentaires

... et le prêter ...

a, on me souffle dans mon oreillette que cela sera bientôt interdit, et l'est déjà via les DRM (et hop, la boucle avec le journal est bouclée ...)

Salut,

bein l'action de La Quadrature du Net est détaillée là, sur la page de soutien ;)

http://www.laquadrature.net/soutien2010

- La mission de La Quadrature du Net

- Le travail effectué en 2008/2009

- Les dossiers pour 2010

;) bonne lecture ;)

ah :) et c'est Bayart ;)

oui

Si c'est du raid 1 linux, tu peux prendre le disque A2, le mettre dans ton serveur B, et mettres tes disques B1 et B2 dans les emplacements libre des serveurs A et B

Ainsi, tu obtiens 2 serveurs bootable, mais en raid dégradé, et là tu reconstruit les 2 avec

mdadm --add /dev/md0 /dev/sdb1 (ce n'est qu'un exemple hein)

après c'est pas forcément un truc d'admin novice hein ...

et je pars de l'idée que ton raid en A est bien fait (à savoir que A2 a été aussi marqué bootable ;) )

Probablement : j'utilisais, à une autre époque, le binaire "scsiadd" : -p pour "print" l'état des disques, et -s suivi de 4 nombres pour "scanner" un lun.

J'imagine qu'il doit y avoir d'autres outils similaires.

Là je propose la méthode "2.6" ;)

En effet, Jimmie m'avait dit être passé sur Make, mais je n'avais pas été voir : en effet sa vidéo est là-bas ;)

(on est abonné à Make au boulot ...)

et le numéro qui vient de sortir est justement celui de la 3D printer de MakerBots : http://benjamin.sonntag.fr/a72-26C3_Day1_Imprimante_3D_a_mon(...) aussi présents au 26C3 ... ;)

Je suis assez persuadé que Google offre ce service, (qui doit lui coûter à peu près que dalle par rapport à son budget annuel) ... en toute bonne foi et sans aucune des arrière-pensées évoquées plus haut

Je ne vois pas le besoin pour Google de mesurer les requêtes et de les consolider dans une belle base de données des requêtes DNS des internautes (ce qu'ils annoncent ne pas faire pour l'instant d'ailleurs)

En effet, l'intérêt de Google dans cet histoire est bien plus pragmatique : ils fournissent des services en ligne, un grand nombre d'entre eux. Si les internautes ont des DNS de FAI qui bagottent (ce qui est hélas encore mondialement souvent le cas), ces services peuvent apparaître fort lent voire tout à fait défectueux.

C'est donc surement dans l'intérêt de tous les services de google qu'ils ont ouvert un tel service.

J'appuie cet argument sur le fait que des pontes de google annoncent assez fréquemment que tel ou tel site ferait mieux d'être plus rapide à répondre ses pages s'il veut s'en sortir, et qu'avoir un Internet lent ou bagottant n'est pas leur tasse de thé

Apparemment, pour le DNS, ce problème fut suffisamment patent et la solution suffisamment facile à apporter par eux pour qu'ils ne s'en privent pas ...

Enfin, tout cela ne parle bien entendu que d'aujourd'hui, personne ne sait ce que le demain d'un tel service sera fait. J'invite donc quand même les utilisateurs de linux à

aptitude installer bind (your mileage may vary, use urpmi or other if needed)

et à modifier /etc/dhclient/dhclient.conf pour y

supersede domain-name-server "127.0.0.1";

Le problème est justement de connaître à l'avance (donc sur l'affichage en magasin) le prix de l'OS, et d'avoir la possibilité de ne pas l'acheter avec (pour pleins de raisons aussi bien légales que pratiques)

par ailleurs, si windows préinstallé est à 2€, ils ne pourraient pas longtemps tenir avec des versions boites à énormément plus :)

Que les boites puissent acheter des PC sans licence c'est tout à fait normal : microsoft propose des programmes de licence en masse pour leurs OS et leurs autres logiciels.

Ainsi, telle grosse boite achète un tas de licence windows + office par exemple, et les installe comme bon lui semble sur des machines achetées (surement en tas elles aussi) sans licence.

Je plussoie violemment.

Certes ça n'est pas libre, mais je n'ai jamais trouvé mieux en rapport puissance de l'appareil / ergonomie / fonctionnalités.

Surtout pas du côté des windows mobile (comment on dit "bloated" en français :) )

et encore moins du côté des "touch screen" des modernes iPhones et autres sans claviers

Treo ro><or !

et inversement :) pour que les infos du site soient à jour, il faut des membres motivés, et l'info disponible ;)

... FDN fonctionne surtout sur le principe de la do-ocratie ... et comme on n'a pas trop avancé récemment sur le projet FTTH ...

bein on attend un peu d'aide des linuxfriens (nombreux chez FDN par ailleurs, logique ...) pour faire avancer ce projet ;)

c'est marrant de dire que l'arme ultime en démocratie est le bulletin de vote :)

aux États-Unis, qui sont, je rappelle, aussi une démocratie, on dit souvent : "Ballot, Soap, Jury, Ammo. Please use in that order." L'arme ultime de la démocratie serait donc la balle (ammo = munition), là où le bulletin de vote (Ballot) le savon (Soap) et le tribunal (Jury) n'auraient pas suffi... Le bulletin de vote est la première arme à utiliser, avant toutes les autres.

En France (en fait en Europe) où cela est interdit, l'arme ultime serait donc Jury : La justice ...

Finalement je trouve dommage que personne ne se dise : je vais me lancer en politique et me présenter à une élection locale, peut-être ne pas me faire élire de suite, mais au moins me retrouver face à un élu local, à en estimer le bien et le mal de ses décisions, bref, tenter par ma propre personne d'influencer l'évolution politique de notre société ;)

Par ailleurs, je conseille plus que hyper vivement l'utilisation du rsync de backports de lenny sur etch : rsync 3 avec son protocole en version 30 apporte quelques améliorations notables, comme le fait de ne plus avoir à transférer toute la liste des fichiers avant de commencer les transferts ...

ce backport requiert les packages de lenny base-file et rsync. très léger.

Je ne veux pas faire le rabat-joie, mais c'est justement à cela que sert la classe PDO de PHP, qui permet, non seulement de faire (dans la plupart des cas et si bien développé) une relative abstraction du sgbd sous-jacent, mais qui, Ô miracle, lève une exception en cas d'erreur :)

Je préfère de loin cela à une modification de l'API de php qui rendrait incompatible 99% des applis un peu vieillottes ;)

ou plutôt Pari de Pascal ( http://fr.wikipedia.org/wiki/Pari_de_Pascal ) (excellent article de surcroit)

principe de Pascal ;)

ce n'est pas un droit d'auteur que la bible "violerait" mais un droit divin, ...

c'est une nuance importante ...

On pense surement utiliser cela sur Lautre Net, l'hébergeur associatif autogéré...

C'est à ce jour le seul serveur jabber que j'ai pu trouver où l'on peut ajouter un nom de domaine à chaud sans devoir stopper le service ;)

et j'ai regretté à l'époque l'absence de doc sur le wiki de jabberfr ...

Je n'hésiterais pas à vous tenir au courant. En tout cas, facile à installer et à configurer le Tigase. Fonctionnel en quelques minutes.

Bon, très bon même cet openfire, où comment se monter un serveur jabber en moins de 5 minutes sur une debian !

Génial

Juste ... Il ne correspond pas à mes besoins : j'ai besoin d'un serveur jabber qui sache gérer plusieurs domaines, et qui puisse ajouter / supprimer des domaines à chaud sans redémarrage (donc sans jeter tous les clients connectés)

Donc ça attendra une prochaine version. En attendant je teste tigase qui semble savoir faire ça :

http://www.tigase.org

juste mes 2 cents comme ça : c'est marrant : tu dis "on mélange les codec, protocole et." et ...

"flv est typiquement dérivé de h263" BOUM! : flv est le conteneur ;) (comme avi, mkv, mpg etc.)

flv est un conteneur qui supporte 3 codecs : screen capture (façon mjpeg), sorenson spark et on2vp6, point.

c'est plutôt sorenson spark qui est dérivé de h.263. on2vp6, quand à lui, est un truc totalement proprio.

quelques petites pages de formation à la base en la matière sur le site de ma boite (pour des clients qui voulaient comprendre tout ce barda ...) :

http://www.octopuce.fr/Video-Internet-et-FFMPEG

Pour les habitués de Linux & Gnu, tout est dans le titre ...

Yet Another Php Framework ;)

C'est précisément ce dont se plaignaient les auteurs de php (et du Zend Framework), et je trouve qu'ils ont bien raison sur ce point.

Les paradigmes développés par chaque framework sont sûrement très intéressants ...

Mais pourquoi diantre faut-il 42 frameworks en PHP ?

Donc 30 de non maintenus, et aussi 18 d'infiniment compliqués ? (cake/symfony) et 22 qui multiplient en moyenne par 8 la consommation de CPU par page, et 20 qui multiplient par 7 la consommation moyenne de RAM par page (utilisez Java 1.4 dans ce cas les gars hein ;) )

J'en ai longtemps douté, mais c'est finalement peut-être sa facilité d'utilisation et de développement qui risque vraiment de perdre PHP : trop de diversité médiocre (je ne dit pas que Sloth l'est, mais est-il nécessaire ? pourquoi ne pas juste apporter les paradigmes inventés par leurs auteurs dans Zend par exemple ...)

C'est toutes ces raisons qui m'ont fait choisir Zend et aussi les dernières :

- une doc d'API parfaite (doc brute type phpdoc, complète et requise pour entrer dans le framework et doc utilisateur avec des phrases et des exemples, des use cases et la façon dont les auteurs utilisent la ou les classes décrites...)
- un framework 'relativement léger' pour éviter de transformer l'avantage de PHP en un inconvénient
- un suivi de projet très serré : n'importe quoi ne rentre pas dans ce Framework, et les raisons écrites (code bien écrit, bonne intégration dans l'existant, doc exhaustive etc.) suffisent bien souvent pour bloquer l'entrée de trucs dangereusement écrits ...
- le point précédent n'empêche pas pour autant qu'il reste facilement extensible (façon Java...) on a par exemple développé nos propres classes et notre propre générateur autour de Zend très facilement ...

Moi ce qui m'épate c'est de savoir que des gens se tapent des A/R Paris Londres sur le thème "je bosse à l'un et vit à l'autre" ...

C'est un symbole d'un monde étrange.

Sur la route (juste à côté de la gare TGV Haute Picardie, la "gare aux betteraves") y'a mes parents, qui ne prendront surement jamais le tunnel, qui se plaignaient de devoir faire 30 bornes pour aller au boulot ...

c'est très intéressant des fois de penser aux mondes parallèles qui cohabitent au sein d'un même espace ...

Non, il ne voulais pas parler de Freenet, il envisageait quelque chose d'utilisable.

s'pèce d'hérétique, on dit [[bûcher]]

sinon je trouve dommage que le commentaire de smc ne soit pas en 4 parties, puisqu'il apporte 4 arguments sur des sujets différents ... j'aurais surement pu cliquer "pertinent" sur l'un d'entre eux, là il est déjà à 10 ;)

> On peut penser à un problème d'upstream

Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique

Donc non, pas d'inquiétude côté upstream apparemment

> Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.

Peut-être, mais même si elle connaît seule les paquets, toute organisation est finalement monolithique.

Pour cette idée de la vérification de signature, je signalais juste qu'il était possible de mettre en ligne une copie (donc sur des serveurs non gérés par la distribution) des signatures de packages, copie elle-même signée par un tiers (celui qui gère ces serveurs hors distribution), copie qui ne mettrait à jour sa signature locale d'un package que lorsque celui-ci a été observé par un humain (de la même organisation qui gère ces serveurs hors distribution) et que l'humain à constaté que cette mise à jour a été annoncée d'une manière ou d'une autre : soit sur les listes de sécurité de la distribution, soit via le processus habituel (genre le développeur qui renseigne proprement un changelog, le patch associé, le mail sur la liste devel etc.)

D'ici à ce qu'un pirate puisse passer ce _processus_ qui fait finalement appels aux habitudes de la communauté, il faudra de véritables bourdes majeures, et cela peut donc rendre plus robuste l'infrastructure de distribution.

Cela reprend le classique paradigme : pirater un système au hasard est très facile, pirater un système particulier infiniment plus difficile.

Donc pirater un jour quelque chose dont il advient qu'il s'agit d'un serveur principal de distribution, c'est une chose, pirater ensuite l'infrastructure tierce qui co-valide les signatures, c'est une toute autre paire de manches.