C'est vrai que le cache est local à un shell mais je ne pense pas que ce soit un problème. En effet je pense qu'en dehors des commandes "systèmes" (grep, find, cut, etc.) il n'y a finalement pas des masses de commandes que l'on utilise souvent.
Pour les commandes systèmes il n'y aurait pas de problème car elles seraient naturellement dans /usr/bin qui serait en début de PATH. Pour le reste (les appli qui auraient leur propre répertoire) je pense que l'impact serait en négligeable (passer 2 secondes de plus dans la lancement de gimp) et nul (si on les lance à partir d'un desktop manager qui aura la path complet).
Pour le man et les lib il faudrait effectivement faire qq chose mais c'est assez simple d'ajouter en perl une ligne dans un fichier de conf ...
Pour ma part, le choix est vite fais, mais quels arguments autres que "je code avec emacs ou vi, parce que c'est plus rapide et que j'aime pas perdre mon temps" peut-on ammener à un employeur ?
La légèreté d'Emacs par rapport aux IDE poids lourds et puis les fonctions sympa d'Emacs comme les différents diff (arf) qui sont ce que j'ai vu de meilleurs actuellement sous Unix mais aussi sur NT (enfoncé Windiff, UltraEdit et Continuus).
Bref sauf lorsque l'utilisation d'un IDE particulier est imposé pour de bonnes raisons je pense que Emacs n'est en rien dénué d'avantages par rapport à d'autres IDE.
Java est plus propre que Perl pour certains concepts tels que la POO qui marche très bien en Perl mais qui fait un poil bricolage ;
La syntaxe de Java est moins rebutante pour un débutant que celle de Perl sans même parler de maintenabilité il est clair que présenter du code Java à des décideurs est nettement plus facile que présenter du code Perl ;
Perl est un langage très permissif (typage faible, etc.) ce qui combiné avec le point précédent permet de faire du code inmaintenable plus facilement qu'en Java (attention en Java on peut aussi faire du code illisible et inmaintenanble par exemple avec des instanciations d'objets qui comportents des méthodes anonymes de plusieurs centaines de lignes, pas de séparation entre graphique, traitement et données, etc.) ;
Certains concepts comme les interfaces n'existent pas en Perl ;
il n'y a pas pour Perl l'équivalent des IDE Java (Netbeans, JBuilder, Visual Age, etc.) ;
Java est probablement un peu plus portable que Perl surtout parce qu'une bonne partie des modules de CPAN ne compilent pas sous Windows.
Avantages Perl sur Java
Perl est nettement plus rapide à programmer que Java ;
Perl intégère des types comme les hash ce qui permet de simplifier pas mal de chose (on peut faire la même chose en Java mais comme le type hash ne fait pas partie du langage c'est lourd) ;
Le JRE est sympa pas souvent il est d'une lourdeur incommensurable (par exemple ça me gonfle de devoir instancier trois objets pour écrire un fichier de passwd pour Apache) ;
À mon avis les API de CPAN sont souvent plus sympa à utiliser que leurs équivalents Java c'est à mon avis la différence en des modules écrits par ceux qui les utilisent des des modules qui sont magnifiques théoriquement mais pas nécessairement pratique à utiliser ;
Il y a en Perl plein de trucs sympa faisable grâce à l'aspect interprété du langage ou autre (Class::MethodMaker par exemple) ;
Perl est "libre" et non imprégné par le discours des markétoïdes qui a convaincu nombre de société que n'importe qu'il n'était pas nécesssaire d'être expérimenté pour faire du code de qualité en Java (arf) et qui ont ainsi convaincu des sociétés entières de passer à Java alors qu'elles n'avaient aucune compétence (arg). Là je ne rigole pas car c'est ce qui s'est passer dans ma boîte.
Ah bon ? Ce n'est pas mon impression. Les APIs java couvrent un spectre suffisament large pour que tu puisses faire beaucoup de choses avant d'en arriver à utiliser JNI.
Tout à fait d'accord. Mais à partir du moment où l'on utilise JNI on sort de l'aspect multiplateforme séduisant (et à fort potentiel marketting) de Java.
- c'est de l'orienté objet, ce qui permet une réutilisation du code ainsi que la modification de celui-ci sans devoir changer tout le reste. (et tous les autres avantages de la POO)
Cette possibilité de réutilisation du code n'a rien de propre à Java (comme tu le dis) et si un langage objet facilite les choses il reste possible de le faire en bête C (par exemple Gtk, ou toute autre bibliothèque).
Pour ce qui est de la possibilité de modification sans devoir tout changer cela tiens plus de l'idéalisme que de la réalité. Java permet de le faire, certes mais n'empêche de se planter sur sa conception et d'avoir au final un truc impossible à maintenir.
- c'est multi-plateforme. Le programme que j'ecris pour linux, tournera aussi sur windows ou sur tout os ayant une JVM.
Mouais c'est assez vrai sauf qu'en pratique il faut toujours s'interfacer avec un truc qui nécessite de faire du code natif.
- Il est génial pour tout ce qui touche le réseau et internet (que ce soit un « bete » programme comme jcoincoin ou une applic applet/servlet)
À mon avis pour ce qui est réseau et internet Perl et nettement au dessus de Java mais bon on rentre là dans un domaine hautement subjectif.
Pourquoi comparer de Java et du C++ ? Les applis C++ peuvent t'elles se lancer dans le navigateur du lambda ?
Quel est l'intérêt de pouvoir lancer une appli à partir d'un navigateur ? Pour les applis installées en local il est nettement plus simple de taper mon_appli_ki_tue à partir d'un shell, ou de cliquer sur une icône que de lancer au préalable un navigateur.
Certes cela permettrait d'exécuter l'application directement à partir du serveur sans installation en local mais je ne me vois pas attendre le téléchargement de Gimp à chaque fois que je souhaite le lancer (et pourtant j'ai le cable).
Reste les applets qui sont utilisées uniquement au sein de pages web pour passer outre les limites de HTML. Java a alors un gros avantage sur les langages compilés mais j'ai plutôt tendance à penser que ce genre de chose est de moins en moins utilisé : les applets de sécurisation utilisées un temps par les banques ont été remplacées SSL 128bits et les animations, jeux, etc. sont plus souvent en flash qu'en Java.
C'est quoi le rapport entre la baguette de pain et les films américains ?
C'était de l'humour tendant à souligner les ramifications des différentes sociétés impliquées dans la production à Hollywood.
D'ailleurs, y'a pas mal de DVD vidéos non crypté. Si tu l'ignorais, c'est qu'effectivement, tu n'achetes que des produits MPAA - ca te regarde - mais ne vient pas raconter qu'ils n'y a qu'eux !
Il y a effectivement pas mal de DVD non CSSisés en gros tout ce qui n'ai pas édité par une filiale d'une major Hollywoodienne.
Cependant la MPAA est avant tout une association de studios cinématographiques. Ce sont donc les films en eux mêmes qui constituent le produit principal de la MPAA. Si je pense que ne pas acheter de DVD crypté est une bonne chose cela n'a rien à voir avec ne pas acheter les produits MPAA puisque cela reviendrait à boycotter quasiment tous les films. Même lorsque le DVD n'est pas crypté (par exemple dans les éditions Criterion de films Hollywoodiens, le studio touche de l'argent sur chaque DVD vendu).
Un bémol. Pour mettre sur un CD de 650Mo un film de 90 minutes (pas très long) il faut un débit global image+son de 986kb/s. Or une piste AC3 en 5.1 est généralement encodé à 448kb/s ce qui sera probablement insuffisant pour garantir une qualité d'image correct en plein écran.
Le MPAA est une association regroupant les professionnels du cinéma aux USA et en particulier les grand studios. Le DVD n'est donc pas le seul produit du MPAA. Boycotter les produits MPAA revient à ne plus voir (au cinéma, à la télé, en vidéo) de film, de téléfilms ou de séries produit par les grands studios US (Columbia, Fox, Paramount, MGM, Universal et Warner).
Et si l'on trouve que ça ne fait pas assez on peut aussi ajouter les filiales ou les actionnaires de ces studios. Sachant que Columbia et propriété de Sony, Universal de Vivendi et Warner d'AOL il va falloir faire attention en achetant sa baguette.
Pour résoudre les problèmes de "goreterie" est-ce qu'il ne serait pas intéressant de ne pas rendre la reprise du commentaire précédent obligatoire mais accessible par l'intermédiaire d'un bouton "citer le message précédent" à côté du bouton suite dans la première étape ?
Ainsi ceux qui veux s'appuyer sur le message précédent aurait la possibilité d'échapper à un copier/coller/blockquotiser et ceux qui n'ont que faire du message précédent n'oublieraient pas de le virer.
Certes certes. Si la démocratie directe me semble viable dans le cas de la "busherie" en Afghanistan je doute vraiment que cela soit le cas dans les autres exemples dont tu parles.
Dans le cas des brevets logiciels la situation est simple mais probablement hors de portée du commun de citoyens qui seraient probablement à la merci des campagnes de communication des lobbies. Mais bon là encore je veux bien admettre que la démocratie directe puisse fonctionner.
En revanche si idéalement j'aimerai pouvoir intervenir sur des sujets qui me tiennent à coeur comme la santé et les services publics je pense que dans la pratique ce ne serait pas faisable. En effet, ces thèmes sont rarement abordés sous des angles aussi directs. Dans la pratique qui aurait le temps et les compétences pour éplucher un épais projet d'une loi de finances ; qui pourrait faire des contre propositions et enfin qui pourrait les défendre. Dans un sujet aussi complexe et technique que le financement de la santé et des services publics, on assisterait à mon avis à des débats à côtés desquels ceux que même les fufeurs prêteraient à rire. Bref au final on se retrouverait dans une situation proche de fufe dès que les sujets abordés deviendraient trop absconts ou trop polémiques.
Le problème du vote est nettement plus complexe que celui de l'identification. Dans le cryptogram de février 2001 (http://www.counterpane.com/crypto-gram-0102.html#10(...)) Bruce Schneier fait un parallèle entre le e-commerce et le e-vote. En résumé et en français :
Dans le cas d'une transaction financière un nom est attaché à la transaction or dans le cas d'un vote il ne doit pas être possible à partir d'un suffrage de remonter jusqu'à son auteur.
Les transactions financières peuvent être "défaites" lorsque l'on découvre une fraude. Dans le cas d'un vote on ne peut pas refaire le vote car il est impossible de se retrouver dans la même situation que lors du vote initial.
Enfin j'aime beaucoup le dernier point de l'article. Dans le cas d'une transaction financière, les apparences ne comptent pas. Si un script kiddy déclare qu'il a détourné 1 millions de dollars et que ce million ne manque à personne, cela n'aura aucun effet. En revanche dans le cas d'un vote le brave script kiddy risquerait par déclarations de nuire à la crédibilité du vote.
Concernant la démocratie directe je ne pense pas que cela soit applicable aux sociétés occidentales. Usenet est un exemple de démocratie directe. Si je me restreint à usenet-fr on se rend compte que les votants sont ultra minoritaires par rapport à l'ensemble des usenautes. Pis encore, tous les débats préalables se déroulent sur fr.usenet.forums.evolution (fufe pour les intimes). Or très peu de gens ont la disponibilité et l'envie de suivre les débats qui se déroulent sur ce groupe. Au final ce n'est finalement qu'une minorité (non élue) qui préside aux évolutions de usenet-fr.
Je doute aussi malgré les dires de FTC que le passage à pppoe améliore les perfs. Je vois deux choses qui pourraient amener FTC à passer à pppoe :
passer à un business model à la ADSL dans lequel FTC ne serait plus que le transporteur ;
empêcher les connexions multiples avec un hub
Concernant ce dernier point si c'est une pratique trop répandue il est clair que cela doit coûter des sous à FTC puisqu'il faut alors une adresse IP par machine.
Mouais c'est peut être oublier un peu que ADSL (même sans FT) n'est pas sans défaut : le passage par ppp, la déconnexion toutes les 24 heures par FT et les drivers pour les modems USB.
Certes on arrive à faire le faire fonctionner (dfivers à installer, scripts pour remonter automatiquement la connexion) mais comparé au cable dans lequel une distrib standard suffit et pour lequel il n'est nécessaire que de brancher et de déclarer l'interface en IP dynamique avec DHCP, je trouve que l'ADSL fait usine à gaz.
D'après un article de transfert il semblerait qu'il y ait un logo indiquant plus ou moins clairement que le disque ne fonctionne pas sur un ordinateur. Je me pose malgré tout une ch'tite question. Certains lecteurs de DVD de salon bas de gamme sont construit à partir de DVDRom. Comment se passe alors la lecture des disques protégés sur ces lecteurs là ? S'il s'avère impossible de lire les disques protégés sur ces lecteurs je me demande bien comment l'utilisateur pourrait bien savoir que son lecteur de salon et en fait un DVDRom.
de plus aux states, les différentes privacy policy ne tiennent pas en cas de faillite et les fichiers clients sont alors immédiatemment vendus.
Bah oui les fichiers clients font partie des actifs de la société. Concernant les pricacy policy je me demande quel est leur statut légal. Est-ce qu'elles peuvent être assimilées à des contrats et en cas de non respect par l'entreprise donner lieu à un procès avec dommage et intérêt pour les utilisateurs ? Je doute que ceci ait été intégrés (aux USA au moins) dans une loi fédérale et je ne pense pas qu'il y ait eu sur ce sujet un procès suffisamment important pour faire jurisprudence.
J'aurai tendance à penser qu'il s'agit au mieux d'une politique de bonne conduite de l'entreprise et au pire d'un argument marketting. D'ailleurs même dans le cas d'une politique de bonne conduite rien n'interdit à l'entreprise de changer du jour au lendemain sa politique (voir le cas d'Amazon). Au mieux les utilisateurs seront prévenus qu'ils peuvent se déinscrirent et au pire rien ne leur dira que leurs informations personnelles peuvent être vendues.
Sûrs, oui, mais objectif et digne de confiance, hmmm ...
Et digne tout court, n'en parlons pas !
Sûrs ? Bof. Mis à part Le canard enchaîné qui vérifie ses infos avant de les publier je ne suis pas sûr que la course au scoop et au sensationnel à laquelle se livre les médias traditionnels leur permette de toujours vérifier leurs sources avant publication.
Lundi matin un collègue dont la famille est à Toulouse m'a raconté l'anecdote suivante. Lorsque l'explosion de l'usine a eu lieu, le bruit était tellement fort que beaucoup pensaient, psychose des attentats aidant, que l'explosion avait eu lieu dans leur bâtiment. Immédiatement le téléphone a fonctionné et des rumeurs ont circulées (de bonne foi) comme quoi il y avait eu un explosion à la poste, à la préfecture, etc. Le problème est qu'il semble que dans son premier flash France Info a colporté ces rumeurs et a donc parlé d'attentats à Toulouse sans avoir fait de vérification.
Un système d'éthique du scoreur ? Pourquoi pas mais j'ai tendance à penser que cela implique alors l'obligation de mettre en place un système de métamodération afin de vérifier que cette éthique est bien respectée.
Une idée en passant est-ce que les notations effectuées sur les commentaires anonymes ne devraient pas influencer les XP de l'auteur. Je vois plusieurs avantages :
on éviterait la tentation de commenter en anonyme pour ne pas risquer une perte d'XP ;
conséquence de la phrase précédente il deviendrait dans la pratique possible de perdre des XP ;
les personnes qui, sous couvert de l'anonymat, poste régulièrement des trolls pourraient voir dès le départ leurs commentaires noté plus bas que les messages anonymes actuels ;
quelqu'un connu pour ses commentaires intéressant décidant de commenter en anonyme pourrait avoir un score initial plus haut que les messages anonymes actuels.
Bien sûr il faudrait veiller à ce que l'on ne puisse pas retrouver l'auteur d'un commentaire anonyme. On pourrait décider de supprimer le lien entre un commentaire anonyme et son auteur lorsqu'il n'est plus possible de noter le commentaire et, pourquoi pas, raccourcir ce délai dans le cas des commentaires anonymes.
Sous Linux aussi
/etc/init.d/iptables {start,stop,restart}
Suffit de faire un script shell, c'est bien compliquer
Je sais bien que l'on peut faire un script mais cela ne change rien.
Dans le cas de pf/ipf la configuration s'effectuant avec une seule commande le firewall passe immédiatement de l'état avant configuration à l'état après configuration (pour couper les cheveux en 4 on peut aussi ajouter un état pendant).
Avec iptables même si l'on utilise un script, il y aura des états intermédiaires après chaque ajout de règle. Pour être vraiment paranoïaque il faudrait dans la conception de son firewall prendre en compte les états intermédiaires pour s'assurer que quelque soit la situation la machine ne se retrouve pas dans un état bizarre ou que ces états intermédiaires ne peuvent pas être utilisés par des méchants.
[^] # Re: Y'a pas 50 solutions
Posté par gabuzo . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 6.
Pour les commandes systèmes il n'y aurait pas de problème car elles seraient naturellement dans /usr/bin qui serait en début de PATH. Pour le reste (les appli qui auraient leur propre répertoire) je pense que l'impact serait en négligeable (passer 2 secondes de plus dans la lancement de gimp) et nul (si on les lance à partir d'un desktop manager qui aura la path complet).
Pour le man et les lib il faudrait effectivement faire qq chose mais c'est assez simple d'ajouter en perl une ligne dans un fichier de conf ...
[^] # Re: Oui, mais...
Posté par gabuzo . En réponse à la dépêche Test Eclipse. Évalué à 3.
La légèreté d'Emacs par rapport aux IDE poids lourds et puis les fonctions sympa d'Emacs comme les différents diff (arf) qui sont ce que j'ai vu de meilleurs actuellement sous Unix mais aussi sur NT (enfoncé Windiff, UltraEdit et Continuus).
Bref sauf lorsque l'utilisation d'un IDE particulier est imposé pour de bonnes raisons je pense que Emacs n'est en rien dénué d'avantages par rapport à d'autres IDE.
[^] # Re: Opinion
Posté par gabuzo . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Avantages de Java sur Perl :
Avantages Perl sur Java
[^] # Re: Opinion
Posté par gabuzo . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Tout à fait d'accord. Mais à partir du moment où l'on utilise JNI on sort de l'aspect multiplateforme séduisant (et à fort potentiel marketting) de Java.
[^] # Re: Opinion
Posté par gabuzo . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 1.
Cette possibilité de réutilisation du code n'a rien de propre à Java (comme tu le dis) et si un langage objet facilite les choses il reste possible de le faire en bête C (par exemple Gtk, ou toute autre bibliothèque).
Pour ce qui est de la possibilité de modification sans devoir tout changer cela tiens plus de l'idéalisme que de la réalité. Java permet de le faire, certes mais n'empêche de se planter sur sa conception et d'avoir au final un truc impossible à maintenir.
- c'est multi-plateforme. Le programme que j'ecris pour linux, tournera aussi sur windows ou sur tout os ayant une JVM.
Mouais c'est assez vrai sauf qu'en pratique il faut toujours s'interfacer avec un truc qui nécessite de faire du code natif.
- Il est génial pour tout ce qui touche le réseau et internet (que ce soit un « bete » programme comme jcoincoin ou une applic applet/servlet)
À mon avis pour ce qui est réseau et internet Perl et nettement au dessus de Java mais bon on rentre là dans un domaine hautement subjectif.
[^] # Re: Opinion
Posté par gabuzo . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 4.
Quel est l'intérêt de pouvoir lancer une appli à partir d'un navigateur ? Pour les applis installées en local il est nettement plus simple de taper mon_appli_ki_tue à partir d'un shell, ou de cliquer sur une icône que de lancer au préalable un navigateur.
Certes cela permettrait d'exécuter l'application directement à partir du serveur sans installation en local mais je ne me vois pas attendre le téléchargement de Gimp à chaque fois que je souhaite le lancer (et pourtant j'ai le cable).
Reste les applets qui sont utilisées uniquement au sein de pages web pour passer outre les limites de HTML. Java a alors un gros avantage sur les langages compilés mais j'ai plutôt tendance à penser que ce genre de chose est de moins en moins utilisé : les applets de sécurisation utilisées un temps par les banques ont été remplacées SSL 128bits et les animations, jeux, etc. sont plus souvent en flash qu'en Java.
[^] # Re: Opinion
Posté par gabuzo . En réponse à la dépêche C# et Java, une étude comparée. Évalué à -3.
[^] # Re: Pourquoi ?
Posté par gabuzo . En réponse à la dépêche Encoder un DivX sous Linux. Évalué à 1.
C'était de l'humour tendant à souligner les ramifications des différentes sociétés impliquées dans la production à Hollywood.
D'ailleurs, y'a pas mal de DVD vidéos non crypté. Si tu l'ignorais, c'est qu'effectivement, tu n'achetes que des produits MPAA - ca te regarde - mais ne vient pas raconter qu'ils n'y a qu'eux !
Il y a effectivement pas mal de DVD non CSSisés en gros tout ce qui n'ai pas édité par une filiale d'une major Hollywoodienne.
Cependant la MPAA est avant tout une association de studios cinématographiques. Ce sont donc les films en eux mêmes qui constituent le produit principal de la MPAA. Si je pense que ne pas acheter de DVD crypté est une bonne chose cela n'a rien à voir avec ne pas acheter les produits MPAA puisque cela reviendrait à boycotter quasiment tous les films. Même lorsque le DVD n'est pas crypté (par exemple dans les éditions Criterion de films Hollywoodiens, le studio touche de l'argent sur chaque DVD vendu).
[^] # Re: Pourquoi ?
Posté par gabuzo . En réponse à la dépêche Encoder un DivX sous Linux. Évalué à 3.
[^] # Re: Pourquoi ?
Posté par gabuzo . En réponse à la dépêche Encoder un DivX sous Linux. Évalué à 10.
Et si l'on trouve que ça ne fait pas assez on peut aussi ajouter les filiales ou les actionnaires de ces studios. Sachant que Columbia et propriété de Sony, Universal de Vivendi et Warner d'AOL il va falloir faire attention en achetant sa baguette.
[^] # Re: Pourquoi ?
Posté par gabuzo . En réponse à la dépêche Encoder un DivX sous Linux. Évalué à 10.
[^] # Re: Cool
Posté par gabuzo . En réponse à la dépêche LaTeX Fr. Évalué à 2.
# Association GUTenberg
Posté par gabuzo . En réponse à la dépêche LaTeX Fr. Évalué à 10.
[^] # Re: kernel 2.4.30
Posté par gabuzo . En réponse à la dépêche Noyau 2.4.14 out. Évalué à 2.
[^] # Re: Notification des reponses aux commentaires
Posté par gabuzo . En réponse à la dépêche Mise à jour de LinuxFr. Évalué à 2.
Ainsi ceux qui veux s'appuyer sur le message précédent aurait la possibilité d'échapper à un copier/coller/blockquotiser et ceux qui n'ont que faire du message précédent n'oublieraient pas de le virer.
[^] # Re: Cyber elections
Posté par gabuzo . En réponse à la dépêche Liberty Alliance Project. Évalué à 3.
Dans le cas des brevets logiciels la situation est simple mais probablement hors de portée du commun de citoyens qui seraient probablement à la merci des campagnes de communication des lobbies. Mais bon là encore je veux bien admettre que la démocratie directe puisse fonctionner.
En revanche si idéalement j'aimerai pouvoir intervenir sur des sujets qui me tiennent à coeur comme la santé et les services publics je pense que dans la pratique ce ne serait pas faisable. En effet, ces thèmes sont rarement abordés sous des angles aussi directs. Dans la pratique qui aurait le temps et les compétences pour éplucher un épais projet d'une loi de finances ; qui pourrait faire des contre propositions et enfin qui pourrait les défendre. Dans un sujet aussi complexe et technique que le financement de la santé et des services publics, on assisterait à mon avis à des débats à côtés desquels ceux que même les fufeurs prêteraient à rire. Bref au final on se retrouverait dans une situation proche de fufe dès que les sujets abordés deviendraient trop absconts ou trop polémiques.
[^] # Re: Cyber elections
Posté par gabuzo . En réponse à la dépêche Liberty Alliance Project. Évalué à 10.
Dans le cas d'une transaction financière un nom est attaché à la transaction or dans le cas d'un vote il ne doit pas être possible à partir d'un suffrage de remonter jusqu'à son auteur.
Les transactions financières peuvent être "défaites" lorsque l'on découvre une fraude. Dans le cas d'un vote on ne peut pas refaire le vote car il est impossible de se retrouver dans la même situation que lors du vote initial.
Enfin j'aime beaucoup le dernier point de l'article. Dans le cas d'une transaction financière, les apparences ne comptent pas. Si un script kiddy déclare qu'il a détourné 1 millions de dollars et que ce million ne manque à personne, cela n'aura aucun effet. En revanche dans le cas d'un vote le brave script kiddy risquerait par déclarations de nuire à la crédibilité du vote.
Concernant la démocratie directe je ne pense pas que cela soit applicable aux sociétés occidentales. Usenet est un exemple de démocratie directe. Si je me restreint à usenet-fr on se rend compte que les votants sont ultra minoritaires par rapport à l'ensemble des usenautes. Pis encore, tous les débats préalables se déroulent sur fr.usenet.forums.evolution (fufe pour les intimes). Or très peu de gens ont la disponibilité et l'envie de suivre les débats qui se déroulent sur ce groupe. Au final ce n'est finalement qu'une minorité (non élue) qui préside aux évolutions de usenet-fr.
[^] # Re: ET...
Posté par gabuzo . En réponse à la dépêche Chez Noos, finie la limitation d'upload. Évalué à 2.
Concernant ce dernier point si c'est une pratique trop répandue il est clair que cela doit coûter des sous à FTC puisqu'il faut alors une adresse IP par machine.
[^] # Re: ET...
Posté par gabuzo . En réponse à la dépêche Chez Noos, finie la limitation d'upload. Évalué à 3.
Mouais c'est peut être oublier un peu que ADSL (même sans FT) n'est pas sans défaut : le passage par ppp, la déconnexion toutes les 24 heures par FT et les drivers pour les modems USB.
Certes on arrive à faire le faire fonctionner (dfivers à installer, scripts pour remonter automatiquement la connexion) mais comparé au cable dans lequel une distrib standard suffit et pour lequel il n'est nécessaire que de brancher et de déclarer l'interface en IP dynamique avec DHCP, je trouve que l'ADSL fait usine à gaz.
[^] # Re: CD audio sur ordinateur
Posté par gabuzo . En réponse à la dépêche La RIAA relance l'offensive. Évalué à 1.
[^] # Re: ... et pour Linux ?
Posté par gabuzo . En réponse à la dépêche L'avenir de FreeBSD menacé ?. Évalué à 7.
Bah oui les fichiers clients font partie des actifs de la société. Concernant les pricacy policy je me demande quel est leur statut légal. Est-ce qu'elles peuvent être assimilées à des contrats et en cas de non respect par l'entreprise donner lieu à un procès avec dommage et intérêt pour les utilisateurs ? Je doute que ceci ait été intégrés (aux USA au moins) dans une loi fédérale et je ne pense pas qu'il y ait eu sur ce sujet un procès suffisamment important pour faire jurisprudence.
J'aurai tendance à penser qu'il s'agit au mieux d'une politique de bonne conduite de l'entreprise et au pire d'un argument marketting. D'ailleurs même dans le cas d'une politique de bonne conduite rien n'interdit à l'entreprise de changer du jour au lendemain sa politique (voir le cas d'Amazon). Au mieux les utilisateurs seront prévenus qu'ils peuvent se déinscrirent et au pire rien ne leur dira que leurs informations personnelles peuvent être vendues.
[^] # Re: Et la confiance
Posté par gabuzo . En réponse à la dépêche un pirate falsifie une info de Yahoo. Évalué à 10.
Et digne tout court, n'en parlons pas !
Sûrs ? Bof. Mis à part Le canard enchaîné qui vérifie ses infos avant de les publier je ne suis pas sûr que la course au scoop et au sensationnel à laquelle se livre les médias traditionnels leur permette de toujours vérifier leurs sources avant publication.
Lundi matin un collègue dont la famille est à Toulouse m'a raconté l'anecdote suivante. Lorsque l'explosion de l'usine a eu lieu, le bruit était tellement fort que beaucoup pensaient, psychose des attentats aidant, que l'explosion avait eu lieu dans leur bâtiment. Immédiatement le téléphone a fonctionné et des rumeurs ont circulées (de bonne foi) comme quoi il y avait eu un explosion à la poste, à la préfecture, etc. Le problème est qu'il semble que dans son premier flash France Info a colporté ces rumeurs et a donc parlé d'attentats à Toulouse sans avoir fait de vérification.
[^] # Re: bilan du système d'XP
Posté par gabuzo . En réponse à la dépêche Un script pour récupérer son XP. Évalué à 2.
[^] # Re: bilan du système d'XP
Posté par gabuzo . En réponse à la dépêche Un script pour récupérer son XP. Évalué à 2.
Bien sûr il faudrait veiller à ce que l'on ne puisse pas retrouver l'auteur d'un commentaire anonyme. On pourrait décider de supprimer le lien entre un commentaire anonyme et son auteur lorsqu'il n'est plus possible de noter le commentaire et, pourquoi pas, raccourcir ce délai dans le cas des commentaires anonymes.
[^] # Re: Portage Linux?
Posté par gabuzo . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 1.
Je sais bien que l'on peut faire un script mais cela ne change rien.
Dans le cas de pf/ipf la configuration s'effectuant avec une seule commande le firewall passe immédiatement de l'état avant configuration à l'état après configuration (pour couper les cheveux en 4 on peut aussi ajouter un état pendant).
Avec iptables même si l'on utilise un script, il y aura des états intermédiaires après chaque ajout de règle. Pour être vraiment paranoïaque il faudrait dans la conception de son firewall prendre en compte les états intermédiaires pour s'assurer que quelque soit la situation la machine ne se retrouve pas dans un état bizarre ou que ces états intermédiaires ne peuvent pas être utilisés par des méchants.