nud a écrit 906 commentaires

Non, car le contournement de la protection est légalement interdit (cf DADVSI)

Ceci contredit la première réponse... sauf si on considère que le téléchargement d'une oeuvre déjà crackée fait partie de la copie priée, ce qui m'étonnerait assez...

Donc, au moins dans le cas de la France, il y a une taxe sur quelque chose qui n'est pas permis. Un peu comme si on avait une taxe prévisionnelle sur le vol ou le meurtre... Ah mais ça existe (sur base volontaire, pas obligatoire), ça s'appelle une assurance...

Il y a une chose que je ne comprends pas bien.

1. Dans la mesure où on paie déjà les droits d'auteurs sur les disques durs, les cartes flash, les lecteurs MP3, les supports optiques vierges et peut-être bientôt sur les connexions internet, pourquoi devrait-on les payer en plus sur les oeuvres proprement dites? Est-ce que cela signifie que, comme l'on a déjà payé les droits d'auteurs, on peut télécharger librement tout contenu protégé sur le net?

2. Ceci n'est pas nouveau, mais la protection des DVD et autres, déjà difficilement défendable juridiquement, est-elle caduque du fait que quoi que l'on fasse, si l'on copie celui-ci on le copie sur un media "right-proof" sur lequel on a déjà payé une redevance ?

3. Suis-je en droit de réclamer de la SABAM ma part des droits d'auteurs sachant que les cartes flashs et les disques durs que j'achète me servent à stocker des photos, du code et des documents que j'ai créés moi-même, et pour lesquels je suis donc le titulaire exclusif des droits d'auteurs ?

http://forensicscontest.com/

J'ai également proposé des corrections, ainsi que des améliorations aux script contribs, tout a été pris en compte, comme quoi la communauté n'est pas mise de côté.

Tu en as de la chance. Le fait que Digium fasse du double-licensing et distribue une version propriétaire prétendument améliorée d'Asterisk, et surtout le fait qu'ils recquièrent une copyright attribution pour accepter un patch rend tout simplement impossible la contribution à Asterisk autre que le report de bugs pur et simple. Alors c'est vrai, même si on contribue à plein de projets, on ne contribue pas à Asterisk. C'est domage mais c'est comme ça que fonctionne le logiciel libre en entreprise.

avez-vous versé un seul centime à Digium pour l'utilisation d'Asterisk ?

Je trouve cette attaque gratuite et déplacée. Ça doit faire 10 ans que je contribue au logiciel libre, en tant que développeur hobbyiste, je n'ai jamais reçu le moindre centime pour la chose alors que d'autres font ou ont fait des sous sur mon code, et je ne viens pas pleurer sur dlfp pour autant.

Il est clair que ce n'est pas simple.

Les problèmes auxquels je faisais allusion sont principalement liés à des problèmes de deadlocks intempestifs et des corruptions de mémoire.

Je suis assez familier avec la complexité d'asterisk vu que je travaille avec "tout nu" depuis la 1.0, donc de ce côté là merci, ça va. Mais je n'oserais pas mettre un 1.8 chez un client comme une zone de police qui se mange des milliers d'appels par jours alors que j'arrive à le faire deadlocker chez moi en quelques heures juste en sip avec du dialplan...

Le problème, c'est qu'avec un programme aussi complexe, un petit changement innocent qui n'a pas été suffisemment testé peut vite avoir des effets de bords inatendus et foutre la merde en bloquant tout... Et il faut avoir confiance en la bête. Je ne nie pas qu'il y ait des fonctionnalités hyper-intéressantes dans 1.8, à commencer par le CEL par exemple, mais pour l'instant la confiance n'y est définitivement pas encore. Il suffit de voir le nombre de correctifs de deadlocks et de problèmes de mémoire dans le changelog de la dernière version "stable" pour s'en rendre compte.

Sauvez des compilos, utilisez sizeof().

En fait ça ne veut rien dire, si le binaire est présent/symlinké dans /sbin et /bin, ça dépend de l'ordre de ton $PATH.

udev n'a pas vraiment remplacé hald... c'est un peu comme si tu disais que alsa a remplacé arts. Il n'y a pas remplacement, il y a juste "cette couche intermédiaire ne sert à rien".

udev a plutôt remplacé devfs et hotplug, et le problème est identique avec sysvinit.

Sauf que le problème principal ici ce sont les règles udev, et que udev prédate systemd. Et tu as besoin de udev pour trouver tous tes disques. Et sans /usr tu ne peux pas trouver les disques USB ou les controleurs PCI vu que c'est là que se trouvent les bases de données. Systemd proprement dit n'a pas de dépendances dans /usr. Comme il le dit sur la page, systemd est ici uniquement le messager, pas le problème.

On pourrait peut-être désemberlificoter tout cela, mais apparemment tout le monde s'en fout, ou en tout cas personne ne s'y intéresse suffisemment que pour corriger le problème.

Si tu lis les liens que j'ai mis (ce que tu n'as visiblement pas fait), tu verras que le problème ne se situe pas au niveau de systemd proprement dit mais d'autres services très communs qui sont invoqués au début du processus de boot principalement via des règles udev. Les problèmes sont liés aux locales, aux libs (notamment dbus), aux bases de données USB/PCI et autres trucs liés.

• Systemd incompatible with mounted /usr
• Booting Without /usr is Broken

Je n'ai pas d'opinion forgée sur le sujet, mais je suppose que c'est la raison pour laquelle Lennart est pour la fusion de /bin et /usr/bin.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ?

Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?

Sauf pour systemd qui fout ses trucs dans /bin au lieu de /sbin

$ ls -l /etc/mtab 
lrwxrwxrwx 1 root root 17 Apr  5  2011 /etc/mtab -> /proc/self/mounts

Le plus parlant est udev, qui est démarré très tôt (typiquement tu n'as que la partition root qui est montée), et qui, avant l'invention de /run, mettait ses données "runtime" dans /etc/.udev, ce qui n'était pas très propre.

Il y a d'autres services qui faisaient de même à divers endroits, et, bien évidemment, rien de standardisé ou prédictible.

Donc je trouve que /run est plutôt bien venu, même s'il n'était pas utile du temps où le FHS a été créé, le temps béni du mknod.

Ceci dit, dans les voitures modernes (pour l'instant en option, mais probablement bientôt de série) tu as:

• les boites (semi-)automatiques, moins polluantes mais déroutantes pour un européen, et qui risquent de devenir obligatoires;
• les freins à main électroniques
• les systèmes start/stop
• la foultitude d'éléments automatiques (phares, essuie-glaces, etc)
• les systèmes de verrouillage centralisé automatique (anti-car-jacking)
• les systèmes d'aide au démarrage en côte
• sans doute plein d'autres

Changer le volant, c'est comme changer la façon primaire d'interagir avec la machine. Personne ne l'a fait en automobile parce qu'on a pas encore trouvé de meilleure solution.

Mais les systèmes périphériques (mais quand même importants) cités ci-dessus sont amenés à changer inéluctablement parce que l'alternative apporte un '+'. Et certains prennent les bonnes décisions à ta place sans te demander ton avis, et ne sont même pas débrayables (je pense aux aides au démarrage, ou à la boite de vitesse).

Quant tout cela sera généralisé, tu devras changer tes habitudes. Tu seras alors toujours libre de ne pas passer aux nouveaux systèmes, mais alors tu devras:

• prendre une voiture d'occasion
• prendre une voiture "bas de gamme" genre Dacia, Tata...
• ne plus conduire.

Chacune de ces alternatives apporte son lot de points négatifs.

Mais après, moi, je vais te dire autre chose. La dernière fois que tu as changé de voiture, tu as peut-être changé de marque de voiture. Et tu as été dérouté quelques jours par le fait que pas deux marques n'ont des contrôles identiques au niveau des sticks près du volant (phares, essuie-glaces, etc). Et tu t'y es habitué.

C'est un peu bête de dupliquer les efforts sur toutes les applis alors que seuls les éléments du bureau sont intéressants à maintenir dans cette optique... et peuvent être portés sur Qt4.

Y'a un peu des deux. Le minimum vital a quand même dû être implémenté, et des rustines ont été placées par la suite.

Les gens qui ont implémenté clutter (et donc mutter) ont pris le pari de ne pas mettre de rustine et d'obliger à la correction des drivers, ce qui fait que dans un premier temps, ben ça marche pas fort pour les drivers buggés.

D'ailleurs kwin a aussi implémenté quelques rustines (bien que sans doute beaucoup moins que compiz, soyons sérieux), car je me souviens de la râlerie qui avait suivi la correction de je-ne-sais-plus quel bug dans un driver, qui du coup faisait bugger kwin...

Une distribution Linux : je n'ai rien contre les BSDs mais le support matériel est bien meilleur sous une distribution Linux. Pourquoi, il y a des distributions optimisée pour Mutter ou GNOME 3 ?

Non mais y'a tout simplement des distributions qui fournissent des drivers plus à jour. Si gnome-shell ne fonctionne pas c'est peut-être tout simplement que ta carte (ou plus vraisemblablement que ton driver) ne supporte pas une API OpenGL particulière utilisée par mutter mais pas par compiz.

Si tu te souviens de l'époque où compiz a fait son apparition, le support était à peu près aussi catastrophique, mais les gens ont corrigé les drivers vidéo pour que compiz puisse fonctionner. Le même se passe avec gnome-shell. Ce n'est pas que une question de vieillesse de la carte graphique.

Asterisk est réputé pour la mauvaise qualité du logiciel, principalement au niveau de la stabilité, à cause d'un manque criant de tests et d'utilisation du produit par les développeurs principaux.

Ici, professionnnellement, nous utilisons (entre autres) Asterisk, mais nous en sommes toujours à la version 1.4, car les versions 1.6 et 1.8 sont tout simplement inutilisables: pour peu qu'on fasse quelque chose d'un peu compliqué, ça crashe. ET même dans la branche 1.4 il a fallu attendre 1.4.22 pour avoir quelque chose de stable (en passant sous silence certaines des dernières versions qui deadlockaient très vite).

J'espère qu'ils ont redressé la barre pour la (1.)10

Ben il faut que tu fasses tourner tcpdump sur le pc avec les trois cartes réseau et que tu reproduises ton problème. Tu devrais assez vite voir ce qu'il se passe et où disparaissent tes paquets.

# tcpdump -i any -s 1024

On le faisait en 320x200, en 640x480 si tu avais de la chance, en 8 ou 16 bits, en 15 images/secondes, et le rendu se faisait pixel par pixel directement sur le hardware.

Maintenant on voit les choses en grand (le lien du journal parle de 2048x1152), en 24 bits, et on veut du 30 voire du 60 images par secondes. Aussi l'écran est partagé entre plusieurs fenêtres indépendantes, qui veulent pouvoir gérer des zones semi-transparentes, etc. En plus on a une pile d'indirections et de copies intermédiaires dans les pattes (à commencer par X11).

C'est comparer des pommes et des poires.

Y'a EDS, mais il y avait des bruits de couloirs qui parlaient d'utiliser Akonadi également.

Il n'y a pas besoin de faire un fork de tout, il aurait suffi de se proposer pour maintenir tout ce qu'il faut, au sein de gnome ou ailleurs.

Sawfish est toujours maintenu par exemple.