Joris Dedieu a écrit 1610 commentaires

C'est l'exemple suprême de la manière de se faire de l'argent sans travail

Je ne vois pas le rapport entre le fait de se faire de l'argent et la valeur. Il faut quand même savoir ce que parler veut dire. Si par valeur tu entends le prix alors tu as sans doute raison, mais la valeur me semble-t-il est ce qui fait qu'un bien matériel ou immatériel est digne d'être échangé.

Le prix est la modalité de l'échange. Mais il n'est possible que parce qu'il y a valeur.
Le prix n'est pas correllé à la valeur. Quelque chose peut avoir une valeur mais pas de prix. Tout simplement parce qu'on ne souhaite pas le vendre. Quelque chose peut avoir un prix élevé mais une valeur faible. Tout simplement parce qu'il est bien vendu ...

Je persiste, sans travail, il n'y a pas de bien et donc pas de valeur. Un billet de loto est imprimé, enregistré, des gens organisent la loterie, font de la publicité et toutes ces choses qui permettent au loto d'exister.

Un autre exemple: les intérêts. Tu gagnes de l'argent sans travailler.

Ou tu gagnes de l'argent parce que d'autres travaille et qu'avec ce travail ils te payent de interêts et des dividendes. La génération spontanée d'argent à beau être une idée relativement répandue, on peut toutefois avec un minium d'esprit critique la remettre en cause . Et se demander par quel subtil mécanisme 1 devient 2.

Bref, la valeur et le travail sont donc décorellé, contrairement à ce qu'on essaie de nous faire croire afin de nous faire travailler plus.

Je n'ai pas dit que c'est en travaillant qu'on devient riche. Produire de la valeur ( des biens digne d'être échangés) n'a aucun rapport avec la richesse. On peut même empiriquement constater que c'est plutôt l'inverse qui se produit. Les plus riches sont généralement ceux qui travaillent le moins.

Ben non. Si tu engages 1000 ouvriers pour creuser un gigantesque trou pendant un an

Personne n'a jamais dit que tout travail produisait de la valeur. Par contre je ne pense pas que tu puisse trouver quelque chose qui ait une valeur sans travail ou travail potentiel (on pense ici aux ressources naturelles).

Donc la question c'est, pourquoi avoir /usr/home, puisqu'il suffit de monter dans /home à la place et on peut le faire assez tard (et on peut le faire avant que /usr/ soit monté).

Le coup du /usr/home (avec un lien /home), je pense que c'est un truc historique de l'installateur que personne n'a pris le temps de changer.

Par défaut pw crée les $HOME dans /home


static struct userconf config =
{
0, /* Default password for new users? (nologin) */
0, /* Reuse uids? */
0, /* Reuse gids? */
NULL, /* NIS version of the passwd file */
"/usr/share/skel", /* Where to obtain skeleton files */
NULL, /* Mail to send to new accounts */
"/var/log/userlog", /* Where to log changes */
"/home", /* Where to create home directory */
0777, /* Home directory perms, modified by umask *

Ceci dit c'est un OS pour lequel tu n'as pas franchement besoin de monter /usr

Tous les logiciels hors système de base étant dans /usr/local, c'est plutôt lui qu'il faut monter à part.

Du coup :
/
/usr/local/
/usr/home
/tmp
/var

Ça fait un partitionnement cohérent.

je n'ai jamais vu la moindre application tourne avec ca

Le client dofus
https://aur.archlinux.org/packages.php?ID=11950

C'est parce que actuellement on juge la valeur d'un bien par sa rareté

Ce qui fait la valeur n'est pas la rareté mais le travail (attention la valeur n'est pas le prix).

http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_valeur_%28marxisme%29

Si c'est bien rattrapé, tu perds pas de données uniques

/usr/home par défaut sous FreeBSD

Faut croire que la première branlée (648 voix CONTRE et 14 voix POUR) n'a pas été suffisamment claire ou convaincante...

Oh tu sais si on s'arrête à ce que pensent les gens ...

Dernière chose : vous dites encore utiliser CVS ? L'âge de l'outil ne se fait-il pas sentir ? Une migration vers quelque chose d'autre est-elle prévue ?

L'utilisation de cvs dans les BSD est historiquement liée au protocole cvsup qui sert à maintenir l'arbre des sources à jour sur les machines.

OpenBSD utilise une version largement modifiée de cvs. Net BSD également me semble-t-il. FreeBSD utilise svn et cvs conjointement (afin de maintenir cvsup). Je pense que seul DragonFly à fait le choix radical de migrer totalement vers git.

Au niveau de l'utilisateur final le changement n’apporte pas grand chose. J'ai même le sentiment que git est plus lent que csup lors de l'initialisation de l'arbre des sources.

s/console/xterm/

s/xterm/urxvt/

Le bon sens est la chose du monde la mieux partagée : car chacun pense en être si bien pourvu, que ceux même qui sont les plus difficiles à contenter en toute autre chose, n’ont point coutume d’en désirer plus qu’ils en ont.

Descartes (Discours de la méthode)

N'est pas impossible que cela soit déjà prévu pour les box.

En fait dans la livebox il semble que tout fonctionne avec des vlans. Donc il suffit qu'ils déclarent n vlan auxquels ils appliquent une Qos différente et qu'ils te collent le bon en fonction de ce que tu payes. De ce que j'en ai compris c'est déja comme cela que fonctionne les chaines à péage.

Je trouve qu'orange a raison d'engager des bras de fer avec les fournisseurs de contenu.

En l’occurrence ce qu'ils font c'est de brider l'accès de leurs clients à une partie de l'Internet.

En passant par cogent :
>> ping 194.2.0.20
PING 194.2.0.20 (194.2.0.20): 56 data bytes
64 bytes from 194.2.0.20: icmp_seq=0 ttl=54 time=44.156 ms
64 bytes from 194.2.0.20: icmp_seq=1 ttl=54 time=43.709 ms

...
--- 194.2.0.20 ping statistics ---
11 packets transmitted, 10 packets received, 9.1% packet loss
round-trip min/avg/max/stddev = 41.590/44.279/46.227/1.333 ms

En passant par level3 :
>> ping 194.2.0.20
PING 194.2.0.20 (194.2.0.20): 56 data bytes
64 bytes from 194.2.0.20: icmp_seq=0 ttl=58 time=2.111 ms
64 bytes from 194.2.0.20: icmp_seq=1 ttl=58 time=1.799 ms
...
^C
--- 194.2.0.20 ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.695/1.953/2.409/0.193 ms

Vivement le temps ou ce seront les gros consommateurs de BP et pourvoyeurs de pub qui fourniront l'accès gratuit au grand ternet

Ce n'est absolument pas de ça qu'il est question. Le but est de faire payer les deux bouts. Un peu comme si un pécheur te payait pour que tu vende ses poissons. C'est plutôt à mettre en parallèle avec les pires heures de la grande distribution.

Je te recommande la lecture de ce débat^w troll sur le FRnOG http://www.mail-archive.com/frnog@frnog.org/msg07320.html

Je cite l'article de numerama :

Est-ce qu'ils vont payer pour investir à nos côtés dans les capacités de réseau ? Non.

Tu parles. Ils vont essayer de faire payer aux internautes ce qu'ils n'ont pas réussie à arracher à tata, cogent et d'autres. Leurs peerings.

Pour mémoire FT est l'un des derniers opérateur réseau qui fait payer aux deux bouts (le client final et le fournisseur de contenue). Manque de bol certains de ces fournisseurs de contenu n'en ont cure et préfèrent se passer de leur clientèle négligeable que de céder à leur chantage.

Nous desservons un milliard d'internautes et gérons 17 % du trafic Internet mondial. Alors, sans méchanceté, si 24 millions d'abonnés Orange ne peuvent pas accéder aux données de mes clients, cela ne m'empêche pas de dormir

affirmait par exemple le pdg de cogent [1]

Pour orange il ne s'agit donc pas de chantage mais bien de justice (sic). Ainsi dans le Point on peut lire cette affirmation délirante [2]

Selon vous, Cogent devrait payer pour accéder aux abonnés haut débit d'Orange ?

Ce n'est pas exactement cela : il s'agit de rémunérer non pas l'accès à l'abonné mais l'utilisation plus intensive de notre réseau. Cogent entraîne une surcharge sur l'ensemble de notre réseau, il y a un déséquilibre notoire. Nous souhaitons discuter des compensations correspondantes.

Finalement on se rends compte qu'il s'agit bien de la même chose. On veut bien que les internautes paye pour accéder au réseau mais encore faut-il qu'ils ne l'utilisent pas.

En attendant cogent fournie de l'ip en France à qui le demande y compris dans des villes de taille modeste, là ou chez FT tu n'arrives même pas à contacter un commercial pour la même problématique.

Voila donc comment un staff de gens dont la compétence technique doit être au niveau de leur compétence managériale est en train de transformer l'une des boite Française qui avait le plus de chance d'être un opérateur réseau de poids en un vague proxy que même aux heures les plus sombres d'aAOL on n'aurait osé imaginer.

[1] http://www.numerama.com/magazine/17886-orange-poursuit-cogent-en-justice-dans-l-affaire-megaupload.html
[2] http://www.lepoint.fr/high-tech-internet/interview-orange-se-defend-face-a-megaupload-et-cogent-25-01-2011-131231_47.php

Je suis d'accord avec toi. Il est très probable qu'IBM pousse pour plus de java et que finalement les deux projets prennent des directions différentes.
Ceci dit vu la monstruosité du code, ce serait très étonnant qu'ils n'en profitent pas pour coller une bonne partie du code dans des libs indépendante sous une licence compatible avec les deux
projets.

Finalement le problème de Ooo est que le code n'est pas structuré pour permettre une évolution rapide. Je pense que ce travail là au moins, les deux projets le partageront.

Pourquoi choisir au hasard ? On prend le SHA1 du tar.gz de la release.

Dans ce cas, autant faire du md5, qu'on s'amuse un peu en cas de collision.

Par exemple chez moi named :

#named est linké avec quelques lib
 ldd /usr/sbin/named
/usr/sbin/named:
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x800806000)
        libthr.so.3 => /lib/libthr.so.3 (0x800aa6000)
        libc.so.7 => /lib/libc.so.7 (0x800bbf000)

#named est chrooté dans /var/named
grep named /etc/defaults/rc.conf 
...
named_chrootdir="/var/named"
...

find /var/named/ -name "*.so*"
#rien
#et pourtant elle tourne
ps www `cat /var/named/var/run/named/named.pid`
  PID  TT  STAT      TIME COMMAND
12867  ??  Is     0:00.02 /usr/local/sbin/named -u bind -c /etc/namedb/named.conf -t /var/named -u bind

En chroot, /usr/lib/libgcc_s.so.1 n'est probablement pas accessible.

C'est tout l’intérêt de LD_PRELOAD. Au moment du chroot ta lib est déja chargé donc plus besoin d’accéder au système de fichier.

Pour contenter pound, il m'a alors suffi de copier

export LD_PRELOAD=/usr/lib/libgcc_s.so.1 ne marche pas ?

spa firefox le fautif ; c'est pulseaudio

Purifions le monde mes frères, pendons Lennart Poettering avec les tripes d'Eric Raymond

L'annonce dans le texte.
http://www.microsoft.com/Presspass/press/2011/may11/05-10CorpNewsPR.mspx

Microsoft will continue to invest in and support Skype clients on non-Microsoft platforms.

Ouf quelle frayeur ! J'ai cru devoir cesser de ne pas utiliser skype :)

Alors soit ils ne changeront pas un système qui marche et ça n'affectera pas postgre.

On par de microsoft là

On ne migre pas d'une base à une autre comme ça, il y a une grosse expertise derrière mêlant les besoins de Skype et les arcanes de PGSQL.

Mon hypothèse est que tout ça sera vite intégré à live/machin. Qu'est-ce qui les intéresse finalement ? La techno ou les utilisateurs ? Telle est la question ...

Au final, j'ai fini par choisir HTTP.

Je comprends bien ce choix de HTTP. Par contre le pingback que tu proposes montre a quel point il est inadapté à ce type d'échanges.

Ce n'est pas spécifique à ton projet.

Sans même parler de sa mauvaise utilisation (requêtes get a effet de bord, sous utilisation de mime), de ses bidouilles (keepalive ...), on voit clairement qu'on passe son temps a faire des requêtes http dans tous les sens en se demandant si petit scarabée est bien celui qu'il dit qu'il est ; côté serveur (auth bypass, vols de sessions ...) comme côté client (phishing ...).

La solution n'est pas de commencer par réfléchir a un protocole fiable pour ouvrir des sessions chiffrées et authentifiés. Puis transporter le reste après.

Pour mémoire skype est une gros utilisateur de postgresql. Je ne sais pas exactement
ce qu'ils contribuent (deux contributeurs officiels) mais il me semble qu'ils ont bien poussé sur les solutions de clustering et certaines problématiques.

Justement, quel type de concessions ?

Il faut penser que c'est un OS principalement serveur. Il y aura plus de travail sur le support des cartes raid que des dungle dvb.

Le support du materiel est relativement uniforme sur l'ensemble des *BSD. Il y a une façon d'écrire le code, un soucie de stabilité dans les appels systèmes, une tradition qui fait que le code est porté facilement (y compris vers d'autres OS qui n'ont rien a voir).

DragonFlyBSD est plutot stable (je l'utilise en production sur des machines bien critiques et elles me foutent un paix royale). Par contre les devs veulent avancer vite sur certains points et ont des priorités bien claires. Tu peux donc avoir un truc annexe qui pète d'une version a l'autre sans prevenir (exemple http://bugs.dragonflybsd.org/issue1848 )

Ça c'est un de mes vieux rêves,
Sous DragonFlyBSD ça s'appelle swapcache. L'idée est de faire du ssd un espace de cache rapide et fiable. Des tests ont été fait avec du postgresql dans une configuration forçant volontairement beaucoup d'io. Les performances sont multipliées par 5.

Voir :
http://www.dragonflybsd.org/docs/howtos/swapcache/
http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache&section8
http://www.shiningsilence.com/dbsdlog/2011/04/12/7586.html