thoasm a écrit 9634 commentaires

Et peut être un jour on arrêteras de ce taper dessus pour rien ...

Le jour ou il y aura plus de troll, ce sera la mort du libre ;)
Le problème c'est juste qu'il y en a un certain nombre pour se prendre pour des Dieux parce qu'ils utilisent telle distro d'homme, d'autres qui prennent les trolls au sérieux, qui trollent pas avec les bonnes personnes, ...

c'est pas très nombreux, deux ...

"Avant de transférer un message de ce type, on vérifie sa validité... "

C'est pas en balancant des leçons de morales aux gens dès la première phrase qu'on se fait aimer ... ;)

Mouarf, l'avis d'un étudiant :)

Non pas pour te dénigrer, mais en tant qu'étudiant qui fait du Ocaml depuis un an, qui est énervé par les contraintes de typages, t'as pas forcément beaucoup de recul sur ce qui est bien ou mal dans un typage si fort. Surtout si t'as fait du PHP avant. C'est bien, c'est facile, peu de contraintes, mais une horreur à debugger (c'est que mon avis, mais j'ai pratiqué, et je le partage).

Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément

C'est AMHA juste une histoire des gestion d'événement, qu'un logiciel qui utilise gconf n'a pas forcément à utiliser : avec gconf, on doit pouvoir garder l'ancien comportement si on veut. Quand à savoir si c'est une mauvaise idée, ça m'a l'air très subjectif comme avis ;). Perso je pense que ça peut être bien pratique.

Sur la communication entre les processus : en pratique, le partage de paramètres (pas de données, en l'occurence) peut se justifier. C'est parfois agacant de devoir mettre en oeuvre des usines à gaz rien que pour pouvoir changer un pauvre paramètre dans deux processus, ce qui peut être un besoin, en pratique : quand tu changes ta config, tu n'as pas forcément envie de relancer tous tes logiciels, avec tout ce que ça implique.

Sur le D-BUS : AMHA gconf doit l'utiliser ... gconf gère des paramètres, comme une lib dynamique pourrait le faire, certe, mais à aussi plus de fonctionnalités. Si tu mettais en oeuvre un autre programme pour gérer aussi des paramètres, mais permettre de les échanger, et si tu voulais partager des paramètres entre plusieurs programmes, il faudrait faire communiquer gconf avec cet autre programme, ce qui est à priori déja le cas ...

En l'occurence je pensais à un utilisateur lambda non assisté, qui veut un peu d'autonomie et de liberté pour personaliser son bureau, chez lui par exemple.

Sinon, pour l'histoire des variables globales, j'attends toujours un argument qui me montre en quoi c'est plus global qu'un fichier de conf ;)

Simple, c'est ton point de vue, celui d'un utilisateur "normalement constitué" (lambda si tu préfère) est sans doute différent.

C'est bien tenté le troll gconf mais ça a un peu rien à voir : tu peux très bien faire une interface qui génère un fichier de conf tout ce qu'il y a de plus classique.

Enfin, sur les variables globales, je vois pas ce qu'il y a de plus global dans gconf que dans un fichier de config. Au pire, si tu veux plusieurs config possibles, des solutions avec gconf : mettre les clés ailleurs dans l'arborescence, et spécifier au logiciel ou il doit aller les chercher (équivalent d'avoir plusieurs fichiers de config alternatifs), permettre de lancer plusieurs instances de gconf, ...

Ca s'apelle la légitime défense : tu as le droit de tuer si c'est toi ou lui, par exemple.

Il y a pas une execption à la GPL dans le cas de composants "de base" du système, typiquement INTEGER, BOOLEAN c'est vraiment des trucs de base ?

Enfin, peut être que l'exception c'est uniquement les libs de base du système d'exploitation. A vérifier, donc, à mon avis.

Plus d'effets, j'en doute pas, mais ça n'en sera pas moins inutile.

Choisir un OS spécialement pour une appli "cliente" je veux bien, mais dans le cas d'une appli serveur, genre une BDD, j'ai plus de mal à comprendre : on migre pas d'OS pour ce genre de trucs tous les matins, les applis clientes tournent généralement pas sur le serveurs (c'est administrable à distance pour les tâches courantes).

Ou j'ai loupé un truc, ou j'ai du mal à comprendre pourquoi elle devrait forcément tourner sous les deux OS ?

Tu trouves peut être ça nul, mais peut être que ça aura des conséquences inattendues :

-> Ca éveille la curiosoté d'un paquet de monde, qui fantasme à tout va
-> le truc sort. Il est révolutionnaire, ou pas. Tout le monde le teste. Il y a des retours de malade sur son utilisation, des trolls dans tous les sens.
-> la beta 2 sort, en ayant tenu compte de pas mal des retours. Ca donne un truc bien à l'arrivée.
-> l'effet de mode, la qualité du truc concurence ubuntu sur le marché des gens qui veulent une distrib simple et/ou qui suivent la mode.

Le tout parce qu'à l'origine la com à été bien pensée !!

En vrai, j'en sais rien. Mais ce qui est sûr c'est que visiblement dans la stratégie de Gael la com a été importante sur Mandriva (les débuts, le club, ...), et que c'est donc pas forcément un clown dans ce domaine, et qu'il veut vivre de ce qu'il fait. Alors, que tu trouves ça nul, à mon avis si ça marche il s'en contrebalance ;)

Indice : aller sur la version anglaise, page d'acceuil, et chercher "francais" ;)

Sur le debuggage : on déplace le problème. Dans l'idéal, j'entend un système réellement utilisable, le code généré est forcément conforme à la spec : si erreur il y a, elle n'est plus à chercher dans le code, mais dans la spec. Il n'y a donc pas à toucher au code généré directement. Multiplier la taille des spec par 10, est-ce un problème si on supprime l'étape codage ?

Dans ce cas, le boulot du codeur serait toujours de remplir les blancs, donc de partir d'une spec vague et en faire une spec complète et correcte, sans avoir à se préoccuper du code.

Après, sur les perfs, c'est un autre problème, sur la faisabilité aussi, les problèmes à résoudre étant souvant indécidables ... Ce que je dis est plus de l'ordre d'un fantasle idéaliste, d'autant plus que je suis pas spécialiste du domaine.

Pas tout a fait d'accord. En général, quand on code, on le fait (au moins implicitement) d'après une spécification. Quand tu codes un truc tu sais à peu prêt ou tu vas. Si tu te rend compte en cours de codage que ce que tu fais c'est n'importe quoi, même si ton code est correct, il faut jeter.

Si on a un bon langage de spec, de niveau relativement haut disons, qui permet de pondre plus ou moins automatiquement du code, ca permet de se concentrer plus sur la spec elle même, et moins sur le code. Alors certe, tu peux faire des erreurs de spec, mais dans ce cas, au moins, t'as plus à tout recoder. D'autant plus que, t'étant à priori plus concentré sur la spec, t'as moins de chance d'avoir fait une erreur fondamentale.

Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.

Après, on en est pas encore là ^^

Je pense que c'est une tendance logique, et de long terme.
C'est nécessaire pour pouvoir faire des raisonnements éléborés d'abstraire les structures. Plus on se rapproche du niveau sémantique, et plus il est facile de faire de déductions, et donc de faire des déductions efficace. Optimiser au niveau de l'algorithme et non plus de la boucle. Une idée qui m'est venu comme ça : un langage ou le compilo choisit lui même la structure de donnée adaptée pour stocker une collection d'objet, en fonction de ce qu'on en fait : optimisation des accès si il y en a beaucoup, ... Au lieu de préciser 'vecteur', 'liste', 'arbre de recherche', on dit 'collection de' et on laisse le compilo se débrouiller en fonction de l'utilisation qu'on en fait.

Puisqu'on parle de langage, c'est le genre de chose nécessaire par exemple en traitement du langage, par exemple pour faire des traductions de textes. La technique "de base" c'est de faire du mot à mot. Pour faire plus efficace, il faut extraire les structures, grammaticale, etc. Pour faire plus efficace, ou plus fidèle, il faut carrément essayer de comprendre le sens du message avant de le retranscrire.

Dans le même genre, niveau langage, certains pensent (genre MS) qu'on va de plus en plus vers des langages spécialisés, dans lequel le spécialiste du domaine (plus forcément un informaticien spécialiste) peut exprimer ce qu'il veut, et laisser faire le boulot à des algos spécialisé, le travail de l'informaticien ce recentrant sur la conception des langages et des algos spécialisés.

Bah, si ça change rien pour le programmeur, mais que ça permet de simplifier le compilateur, pour moi ça apporte quelque chose : de la simplicité pour l'un, sans pénaliser l'autre.

Donc, il y a un avantage. CQFD.

La simplicité du compilo, ça apporte quoi ? moins de bug potentiel, code plus concis, sans doute plus facile de faire des compilos prouvés (avantage pour l'embarqué, par ex) ... Quoi que c'est à vérifier, pour le dernier point, la résolution dynamique de méthode virtuelle c'est quand même plus compliqué théoriquement qu'une conditionelle.

C'est dans la lignée du "ce que veulent les Français", ou encore "ce que veulent les travailleurs", "ce que veulent les (whatever)" qu'on entends souvent dans les discours (pas que chez les politiques d'ailleurs).

Et bien moi, je vais vous le dire : il y en a globalement pas un qui veut la même chose que l'autre, globalement ;)

c'est pas le langage qui génère des trucs, c'est le compilo. Le langage génère rien, il permet juste d'écrire un programme.

Après, le compilo il peut le transformer en ce qu'il veut, en général de plus bas niveau (C, assembleur, etc.), mais le langage en lui même, il génère rien, il permet juste d'exprimer des trucs.

Arrêtez avec ce troll, après il y en a qui utilisent "au temps" à chaque fois qu'il faut dire "autant" (pas seulement dans cette expression), genre "Au temps il est fort, au temps il est stupide"

Ouais enfin c'est pas non plus de bons petits soldats qui doivent être prêt à sacrifier leur santé sur l'autel du ll non plus.

Je peux pas m'empêcher de rapprocher ce que t'as dis sur la spéculation pétrolière (déviance du système) et la bonne santé de Total : ça aiderait pas un peu Total dans ce cas, la déviance du système, et les prix du pétrole ?


Certe peut être que c'est vrai en ce moment mais que ça le sera moins demain ... spéculation toujours. (je m'y connais pas assez pour affirmer)

En fait je veux bien répondre aux questions, mais ça me fait chier de les trouver ;)

(Et comme il y a pas beaucoup de nouveaux pour les poser, je crois que je vais rester tranquille un moment )

La différence fondamentale :

interdire -> implications pénales,
empêcher -> pas d'implication pénales.

Si tu veux faire interdire un truc, il faut en avoir le pouvoir, ou faire légiférer.

Si tu veux simplement empêcher, il faut que tu trouves les bonne mesures techniques, sachant que le fait ne sera pas interdit, donc que si quelqu'un fait sauter les mesures d'une manière ou d'une autre, il ne risque rien (sauf si c'est aussi interdit).

Après, tu peux combiner les deux. Donc, AMHA, ton équivalence n'est pas valide.

Après, si tu donne le même sens à interdire et empêcher, effectivement elle est trivialement valable.

La vraie question originale : As-t-on le droit de détourner le procédé Macrovision alors ?

Après, sur le "qui pourrait t'en empêcher", toi tu pense "de copier un truc" tandis que yeupou pense "de (tenter de) contourner le moyen de protection".



(c'est incroyable comme le débat peut tourner en ayant deux partis d'accord sur le fond, et principalement sur des désaccords de forme, ou plutot de sous-entendus)