thoasm a écrit 9456 commentaires

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)

J'en ai marre des gens qui se contredisent dans un même commentaire !

Tu dis que tu te plains jamais, mais qu'est-ce que tu fais là ? hun ? n'importe quoi !

C'est quoi ce discours moralisateur à deux balles ? Les étrangers pensent ce qu'ils veulent de la France, et ils nous emmerdent !

(on me souffle dans mon oreilette que c'était de l'humour. Rien a foutre, l'humour c'est pas drôle, marre de l'humour)

Ils ne profitent pas de leurs libertés par méconaissance des autres possibilités.

C'est un raccourci un peu facile, à mon avis. Avoir un producteur et un distributeur pour un artiste, c'est quand même s'éviter un paquet d'emmerdes, payer du matos de qualité, un matos de qualité, trouver des dates pour les concerts, ques sais-je encore. Pouvoir se concentrer sur auter chose, quoi. Peut être est-ce même l'inverse : ils profitent du circuit parce qu'ils conaissent les emmerdes et les aléas qu'ils auraient s'ils s'autoproduisaient, par exemple.

Même si c'est de plus en plus facile de s'autoproduire, on est d'accord, ca doit pas non plus être évident de se faire connaître, d'avoir du son de qualité, etc, donc ceux qui ont la chance d'être produits, ils doivent pas forcément tous hésiter longtemps ...

résumé de la situation : on parlait de droit de contourner le procédé macrovision.

Question : qu'est-ce qui pourrait légalement empêcher de contourner ce procédé ?

Réponse qu'attends yeupou : rien. Réponse que tu donnes : Le procédé Macrovision. Le procédé Macrovision dégrade la copie. Qu'est-ce qui empêche de le contourner ? (le procédé Macrovision, pas la copie ...) Bah, dans la loi, rien. Donc si tu trouves un moyen, t'es pas attaquable à priori si tu l'utilises ...