Pas besoin d'être parano, suffit juste de mettre les bonnes règles (a grand coup de drops et de resets), et un portscan qui prendrait normalement 30 secondes se retrouve ralentis au point de durer une heure... au final, ça décourage les petits amateurs de continuer à scanner car trop couteux en temps et les résultats sont bidons...
Avec un bon iptables, il y a moyen de rendre fou les logiciels tentant de faire un portscan, de même, il est possible de faire du "port knocking" pour garder le port ssh invisible aux personnes ne disposant pas de la bonne séquence.
En tant que simple connecté, de toutes façons, un bon firewall reste un bon moyen de rester invisible.
Alors lorsqu'un grand nombre attendait impatiement la sortie de Sarge à l'époque, l'excuse invoquée (et justifiée comme indiqué sur le site de Debian) pour le retard c'était : "ça sort quand c'est prêt".
Ben ça changera peut-être le modèle du "ça sort quand c'est prêt" en "ça sort quand on (les release managers) aura reçu assez de sous" ...
Je crois que cela ferait beaucoup de bien à Debian d'avoir un noyau de permanents dont l'une des tâches pourrait être de rendre le projet plus accueillant pour les volontaires.
Seulement si la question du "qui reçoit quoi et pourquoi" est gérée au sein du projet debian et non par une magouille externe. C'est malsain d'avoir un club externe, indépendant et non sollicité qui distribue les points et les salaires au nom du projet Debian...
Tu peux voir ça comme de la jalousie, c'est exactement ça. Pourquoi je continuerais à contribuer, alors que j'en fais autant qu'eux, si moi je ne suis pas payé par le projet ? Le boulot que je fais moi est donc moins valable ?
Totalement d'accord avec toi sur ce point, commencer à lever des fonds pour payer certains et pas d'autres dans un projet normalement basé sur le volontariat et le bénévolat, c'est effectivement injuste pour les personnes ne touchant rien.
De plus, si une organisation B commence à payer de manière arbitraire des personnes clef d'une organisation A pour que celles-ci posent des actes en tant que membres de cette organisation A, ça commence à sentir sérieusement mauvais, et on pourrait parler d'une forme de corruption, de prise de contrôle.
Y a t'il quelque-chose dans les règlements de Debian qui permettent de contrôler les dons visant des individus? Il y a un véritable problème déontologique qui mériterait d'être adressé.
là où je travailles, c'est RedHat parceque:
- obligatoire pour le support SAN
- obligatoire pour le support HP qui fournis les serveurs, le système de déploiement, ... (enfin, ça se joue entre redhat et suse sur ce coup)
- de toutes façons, les applications tierces sont uniquement certifiées sous RedHat, voir un peu SuSE, et que donc si on veut mettre du Linux, ce sera du RedHat car si l'OS n'est pas certifié, on peut dire adieu au support du fournisseur applicatif et que comparé au coût galactique d'une interruption de service, le coût d'une cinquantaine de licenses redhat est totalement insignifiant.
Parce qu'en milieu professionnel, on doit parfois s'intégrer dans des choix plus vastes que la distribution elle-même, être capable de faire tourner le client backup standard de l'entreprise, d'intégrer les outils de monitoring, d'update, ... et être aussi capable de faire tourner des applications non-libres tout en étant supportée par les fournisseurs...
A ce jeu là, malheureusement, il n'y a pas beaucoup de choix, ...
Parceque toi, tu as une preuve formelle qu'il n'y a pas de gains à, par exemple, à compiler une distribution en spécifiant que le processeur a une toute petite cache et qu'il faut donc éviter de dérouler les boucles parceque le coût d'une branche est moins élevé que le coût d'un accès à la ram? Ou que justement, comme le processeur a une grande cache, autant dérouler dans la limite du raisonnable pour réduire les branchements?
Jusque là je n'ai vu aucun article montrant que gentoo peut permettre un gain signigicatif de perfs.
Tout d'abord, ce n'est pas gentoo qui fait grimper ou baisser les performances, mais les options de GCC, gentoo est juste un outil pour passer les paramètres lors de la compilation et compiler de manière automatique.
Et des benchs concernant gcc et ses options, il y en a déjà eu pas mal, il suffit de se baisser pour en trouver.
Par contre j'ai vu beaucoup d'utilisateurs déclencher des bugs de gcc en utilisant des paramètres d'optimisation ridicules.
moi j'ai vu des utilisateurs lancer des commandes débiles sous linux qui ont provoqué des pertes de données ou la corruption de l'OS, est-ce que pour autant ça fait de linux un système inutile?
L'argument du "les utilisateurs ne sont pas compétents, ça ne marche donc pas" est l'argument que microsoft a reservi aux chefs d'états pendant des années à propos de linux pour décourager les migrations.
Si tu sais identifier correctement le bon profil pour ton cpu, les instructions supportées, la quantité de cache, ... tu peux gagner au niveau des performances. C'est particulièrement vrai quand on s'attaque à des processeurs ayant des petites caches comme les VIA C3. En quelques ajustements de paramètres, il est aisé de faire regénérer un os complètement adapté au hardware.
De même, recompiler tout en ne spécifiant que ce dont on a besoin permet de garder un os léger et particulièrement adapté pour les systèmes embarqués.
Pour ma part Gentoo m'a quelques fois servi pour faire des systèmes compacts pour de l'informatique embarquée (client léger, client multimedia, ...)
Je ne faisais que réagir au fait qu'il est interdit par la Charte de dépendre de non-free depuis main.
Bien entendu... maintenant, on pourrait débattre aussi sur le fait que les firmwares appartiennent à non-free ou si une classification alternative serait nécessaire (par exemple, faire une distinction entre applications/librairies non-libres et ressources non-libres, définir si les firmwares sont ou ne sont pas des ressources plutôt que des applications, si le fait de dépendre d'une ressource non-libre est un motif suffisant pour aller dans contrib, ...) mais bon, débattre de celà ici aurait peu de sens, mais clairement, il y a matière à débat et à amélioration puisqu'il y a problème, et ce n'est pas en faisant des hacks grossiers qui ne respectent pas le modèle actuel qu'on arrangera les choses.
<mode_yaka>Ce qu'il faudrait peut-être, c'est un projet ayant pour objectif d'évaluer s'il y a besoin d'une réforme du modèle, pour ensuite si nécessaire, faire une véritable analyse pour trouver un nouveau modèle répondant aux attentes, au cas où on se heurterait effectivement à une limite du modèle. </mode_yaka>
Un paquet libre (au sens DFSG) qui dépend d'un paquet de non-free doit être dans contrib.
Certainement, le tout est d'avoir un système d'installation permettant d'exploiter correctement cette réalité... c'est pour celà qu'il vaut mieux attendre que le système d'installation soit adapté plutôt que d'essayer de "trancher" et de ne pas faire les choses dans les règles de l'art.
Si les questions relatives aux firmwares sont une perte de temps, pourquoi en faire perdre à Debian en prônant la solution conduisant à sortir les firmwares de main (chose qui n'est pas avare en temps et en heure puisque ça menace la sortie de la prochaine version d'au moins 6 mois et encore, ce n'est qu'une estimation...) ?
La compartimentation des diférents dépôts est une méthode pour garder des logiciels groupés par license, mode de support, ... et main est un dépôt normalement réservé aux éléments de base 100% libres et supportés par les devs de debian.
Mettre du contenu qui n'est pas libre dans main, c'est mélanger des éléments qui n'ont ni la même méthode de gestion, ni la même méthode de support, ni les mêmes licenses.
Par contre, mettre les firmwares non-libres hors de main, mais permettre éventuellement que des éléments de main puissent dépendre de ces éléments non-libres serait peut-être une solution.
Ok, c'est un peu moins élégant qu'une belle structure en oignon des dépôts, mais je pense qu'avant tout, les firmwares non-libres sont une question organisationnelle, et qu'il faut une solution organisationnelle pour permettre aux utilisateurs de profiter au moins des fonctionnalités de base de leur hardware sans pour autant mélanger des éléments qu'il vaudrait sans doutes mieux garder séparés.
Le problème, c'est que vraissemblablement il y a urgence. Du coup, des deux côtés certains prônent le bâclage: certains préfèrent qu'on sacrifie la structure et qu'on mélange les torchons et les serviettes, et d'autres préfèrent tout virer sous couvert de pureté philosophique pour ne pas avoir à se poser de questions... la bonne solution se trouve sans doutes dans un petit report et une approche à tête reposée du problème.
Si, au contraire, debian se plie au "c'est non libre, utilisons le quand même", c'est comme un gros feu vert aux fabriquants pour continuer à développer des firmwares propriétaires...
Les fabriquants de matos n'ont pas besoin de l'autoriastion de la communauté du libre pour continuer à faire des firmwares proprio. Ensuite, par leur nature véritablement liée au matos, ceux-ci n'interfèrent aucunement avec le logiciel libre.
Au lieu de perdre du temps à courrir derrière les firmwares, il serait bien plus intéressant de faire du lobbying pour obtenir les spécifications et/ou des pilotes libres pour les différents périphériques dont les seuls pilotes sont encore proprios.
Un firmware proprio n'empèche pas d'utiliser du matériel avec un noyau 100% libre, un firmware proprio n'empèche pas d'utiliser un périphérique sur une machine avec une autre architecture, un firmware proprio ne donne pas le pouvoir à un constructeur de stopper artificiellement la vie commerciale d'un produit.
Par contre, un pilote proprio teinte le noyau avec des éléments non contrôlables, un pilote proprio empèche de changer d'architecture si la nouvelle n'est pas supportée, un pilote proprio permet à un constructeur de décider qu'à partir de la version x du noyau, les gens n'ont qu'à acheter la nouvelle version du matos.
Faire du lobbying pour libérer les firmwares est une perte de temps.
Le plus important en ce qui concerne le matériel, c'est de libérer les pilotes.
Le plus important en ce qui concerne les firmwares, c'est d'avoir la permission de les redistribuer de manière illimitée lorsque ceux-ci sont indispensables pour pouvoir initialiser du matériel vital au bon fonctionnement de la machine.
En ce qui concerne les firmwares proprio dans debian, il est clair que leur place n'est pas dans main, il faut les mettre ailleurs.
Appeler les firmwares "cochonneries" est totalement stupide.
Le vrai problème n'est pas idéologique mais signalétique: mettre des éléments non-libres dans un dépôt qui a pour vocation de ne contenir que du 100% libre est un transgression des règles d'organisation des dépôts, et est donc peu judicieux car une fois ces éléments non-libres dans le dépôt, celà risque d'être difficile de les retirer.
Il y a des dépôts pour les éléments non-libres, et ces dépôts doivent pouvoir être invoqués lorsque l'utilisation des éléments non-libres est incontournable.
Pour moi, il ne faut pas mélanger des éléments non-libres à main, mais en revanche, il faut assurer que le système soit en mesure de faire le minimum syndical lors de l'installation et de l'utilisation.
Pourquoi cherche-t-on absolument à niveler par le bas la liberté de nos distributions ?
En aucun cas l'utilisation de firmwares non-libres n'altère tes libertés par rapport aux logiciels libres de la distribution, le tout est de pouvoir les garder séparés du reste de la distribution afin que ceux-ci ne compliquent l'exercice du droit à la redistribution des éléments libres.
d'après ce texte, attaquer la redevance, c'est armer les adversaires de la copie privée.
Maintenant que ceux-ci ont les pleins pouvoirs pour bloquer la copie privée par le biais des DRM, y a t'il encore une raison valable de ne pas attaquer cette redevance?
Vu dans le texte...
La raison étant l'injustice supposée du prélèvement appliqué de façon uniforme à tous les possesseurs d'ordinateurs, que leur disque dur soit gavé de fichiers MP3, ou rempli de tableaux de comptes familiaux.
Cette opposition de principe est une erreur absolue. Les adversaires de la rémunération oublient qu'elle est le fruit d'un compromis entre les ayants droit et la société : le libre accès contre un prélèvement. En s'y attaquant, les consommateurs arment les adversaires de la copie.
Je trouve que cette portion du texte est tout simplement lamentable: si c'était vraiment donnant-donnant, on ne se retrouverait pas avec ET la taxe qui est supposée ET le DADVSI.
De plus, les droits d'auteur sont bel et bien des droits offerts par la société dans un désir de rémunérer ceux qui la font avancer culturellement. En aucun cas il ne s'agit d'un droit divin.
Le comportement actuel de l'industrie est "ce qui est à moi est à moi, et ce qui est à vous est négociable", et je ne vois pas au nom de quoi il faudrait continuer à l'accepter.
<alerte récupération politique>
... formidable d'avoir un porte drapeau de poids comme lui dans la lutte contre le dadvsi, là, maintenant, on se sent sauvé... Bon, c'est vrai que sa prise de position remonte à ... août 2006, mais il a su comprendre l'importance du débat et la nécessité de rallier tous les mécontents de cette loi à sa cause: les présidentielles de 2007...
Même pas un mot à propos des députés PS qui se sont battus contre le DADVSI...
Il reste bien démago le fafa...
</alerte récupération politique>
c'est vrai, et c'est là qu'on se rend compte que le problème est bien plus large qu'une question de drm, de brevets, ...
Je pense que nos sociétés occidentales sont occupées à sombrer dans l'obscurantisme, le fascisme, et qu'il va falloir serrer les dents car on est partis pour un bout de temps avant que les gens ne se resaisissent.
en effet, le modèle .net est un peu en opposition avec l'apporche VB "quick & dirty", mais il est aussi en contradiction avec les habitudes de développement des développeurs c/c++ et oblige souvent à prendre des chemins très détournés pour pouvoir faire quelque-chose qui aurait été fait de manière très simple en utilisant directement les api win32, com, dcom, ... bref, résultat mitigé car perte d'efficacité et de fonctionnalité pour les bons développeurs, mais gain de temps sur toute une série d'opérations...
Le mieux, si tu es condamné au wep, c'est d'utiliser un système vpn au dessus (ou au pire du ssh avec port forwarding), mais il faut que ton access point le supporte (si c'est un access point maison, pas de problèmes, sinon, c'est plus dur)... dès lors, la personne désireuse de pirater ta connexion est coincée car seules les sessions encapsulées dans le vpn ou le tunnel ssh sont autorisées.
et la plupart de ces pc sont équipés d'une carte graphique intel intégrée à la carte mère.
Pour laquelle j'avais naïvement cru bon de préciser les combinaisons les plus fréquentes de combinaisons proc/chipset dans les pc's visant les grandes entreprises et administrations.
De là on en est arrivé à l'étape où tu déclares
tu sais, fournisseurs ou pas, ils ont déja du mal à changer de marque de stylo...alors de cpu !
Alors, à part le cas où tu me montres un appel d'offre spécifiant explicitement que l'administration exige des processeurs de marque Intel (ce qui serait sans doutes illégal), impose qu'une technologie comme l'hyperthreading soit présente (meilleur moyen de virer amd en douce dans un appel d'offre biaisé), ou des exemples d'offres qui ont été refusées sur base du fait que le processeur proposé dans l'offre était un amd, tes déclarations sont non-fondées.
tu sais, le mieux est de vérifier avant de dire n'importe quoi...
Non seulement les amd sont présents dans les gammes des constructeurs, mais ils se vendent... la preuve, au boulot (institution financière assez conservatrice avec env 30.000 pc's), toutes les nouvelles machines de bureau sont des amd64, et les thin clients sont à base Athlon XP-M.
la plupart des administrations ne font même pas confiance en AMD
Les administrations et grandes entreprises croient surtout leurs fournisseurs. Si HP ou IBM dit que les amd sont bons, et offrent de bonnes conditions, les entreprises achètent amd. L'important, ce n'est pas la marque de cpu (sauf pour certains religieux), mais leurs possibilités et surtout l'intégration dans une plateforme orientée entreprise.
[^] # Re: Mandridows ?
Posté par ragoutoutou . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 4.
Pas besoin d'être parano, suffit juste de mettre les bonnes règles (a grand coup de drops et de resets), et un portscan qui prendrait normalement 30 secondes se retrouve ralentis au point de durer une heure... au final, ça décourage les petits amateurs de continuer à scanner car trop couteux en temps et les résultats sont bidons...
[^] # Re: Mandridows ?
Posté par ragoutoutou . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 6.
Avec un bon iptables, il y a moyen de rendre fou les logiciels tentant de faire un portscan, de même, il est possible de faire du "port knocking" pour garder le port ssh invisible aux personnes ne disposant pas de la bonne séquence.
En tant que simple connecté, de toutes façons, un bon firewall reste un bon moyen de rester invisible.
[^] # Re: Mauvaise idée...
Posté par ragoutoutou . En réponse à la dépêche Dunc-tank: comment aider à la publication de Etch en décembre. Évalué à 4.
Ben ça changera peut-être le modèle du "ça sort quand c'est prêt" en "ça sort quand on (les release managers) aura reçu assez de sous" ...
[^] # Re: planet.debian.net
Posté par ragoutoutou . En réponse à la dépêche Dunc-tank: comment aider à la publication de Etch en décembre. Évalué à 5.
Seulement si la question du "qui reçoit quoi et pourquoi" est gérée au sein du projet debian et non par une magouille externe. C'est malsain d'avoir un club externe, indépendant et non sollicité qui distribue les points et les salaires au nom du projet Debian...
[^] # Re: Dunc Tank
Posté par ragoutoutou . En réponse à la dépêche Dunc-tank: comment aider à la publication de Etch en décembre. Évalué à 3.
Totalement d'accord avec toi sur ce point, commencer à lever des fonds pour payer certains et pas d'autres dans un projet normalement basé sur le volontariat et le bénévolat, c'est effectivement injuste pour les personnes ne touchant rien.
De plus, si une organisation B commence à payer de manière arbitraire des personnes clef d'une organisation A pour que celles-ci posent des actes en tant que membres de cette organisation A, ça commence à sentir sérieusement mauvais, et on pourrait parler d'une forme de corruption, de prise de contrôle.
Y a t'il quelque-chose dans les règlements de Debian qui permettent de contrôler les dons visant des individus? Il y a un véritable problème déontologique qui mériterait d'être adressé.
# DADVSI
Posté par ragoutoutou . En réponse au message Lire un DVD protégé par RCE. Évalué à 8.
et oui, désolé, on l'a dans l'os...
# Quel est le contexte?
Posté par ragoutoutou . En réponse au message mplayer + vidéo de conférence = vitesse à x0.63. Évalué à 2.
Quel est le protocole utilisé?
[^] # Re: [x] l'intégration en entreprise.
Posté par ragoutoutou . En réponse au sondage La raison principale à l'origine du choix de ma distribution est :. Évalué à 2.
- obligatoire pour le support SAN
- obligatoire pour le support HP qui fournis les serveurs, le système de déploiement, ... (enfin, ça se joue entre redhat et suse sur ce coup)
- de toutes façons, les applications tierces sont uniquement certifiées sous RedHat, voir un peu SuSE, et que donc si on veut mettre du Linux, ce sera du RedHat car si l'OS n'est pas certifié, on peut dire adieu au support du fournisseur applicatif et que comparé au coût galactique d'une interruption de service, le coût d'une cinquantaine de licenses redhat est totalement insignifiant.
# [x] l'intégration en entreprise.
Posté par ragoutoutou . En réponse au sondage La raison principale à l'origine du choix de ma distribution est :. Évalué à 2.
A ce jeu là, malheureusement, il n'y a pas beaucoup de choix, ...
[^] # Re: Faîtes chauffer les CPU
Posté par ragoutoutou . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 5.
Parceque toi, tu as une preuve formelle qu'il n'y a pas de gains à, par exemple, à compiler une distribution en spécifiant que le processeur a une toute petite cache et qu'il faut donc éviter de dérouler les boucles parceque le coût d'une branche est moins élevé que le coût d'un accès à la ram? Ou que justement, comme le processeur a une grande cache, autant dérouler dans la limite du raisonnable pour réduire les branchements?
Tout d'abord, ce n'est pas gentoo qui fait grimper ou baisser les performances, mais les options de GCC, gentoo est juste un outil pour passer les paramètres lors de la compilation et compiler de manière automatique.
Et des benchs concernant gcc et ses options, il y en a déjà eu pas mal, il suffit de se baisser pour en trouver.
moi j'ai vu des utilisateurs lancer des commandes débiles sous linux qui ont provoqué des pertes de données ou la corruption de l'OS, est-ce que pour autant ça fait de linux un système inutile?
L'argument du "les utilisateurs ne sont pas compétents, ça ne marche donc pas" est l'argument que microsoft a reservi aux chefs d'états pendant des années à propos de linux pour décourager les migrations.
[^] # Re: Faîtes chauffer les CPU
Posté par ragoutoutou . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 1.
C'est une déclaration qui n'engage que toi.
Si tu sais identifier correctement le bon profil pour ton cpu, les instructions supportées, la quantité de cache, ... tu peux gagner au niveau des performances. C'est particulièrement vrai quand on s'attaque à des processeurs ayant des petites caches comme les VIA C3. En quelques ajustements de paramètres, il est aisé de faire regénérer un os complètement adapté au hardware.
De même, recompiler tout en ne spécifiant que ce dont on a besoin permet de garder un os léger et particulièrement adapté pour les systèmes embarqués.
Pour ma part Gentoo m'a quelques fois servi pour faire des systèmes compacts pour de l'informatique embarquée (client léger, client multimedia, ...)
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 3.
Bien entendu... maintenant, on pourrait débattre aussi sur le fait que les firmwares appartiennent à non-free ou si une classification alternative serait nécessaire (par exemple, faire une distinction entre applications/librairies non-libres et ressources non-libres, définir si les firmwares sont ou ne sont pas des ressources plutôt que des applications, si le fait de dépendre d'une ressource non-libre est un motif suffisant pour aller dans contrib, ...) mais bon, débattre de celà ici aurait peu de sens, mais clairement, il y a matière à débat et à amélioration puisqu'il y a problème, et ce n'est pas en faisant des hacks grossiers qui ne respectent pas le modèle actuel qu'on arrangera les choses.
<mode_yaka>Ce qu'il faudrait peut-être, c'est un projet ayant pour objectif d'évaluer s'il y a besoin d'une réforme du modèle, pour ensuite si nécessaire, faire une véritable analyse pour trouver un nouveau modèle répondant aux attentes, au cas où on se heurterait effectivement à une limite du modèle. </mode_yaka>
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 3.
Certainement, le tout est d'avoir un système d'installation permettant d'exploiter correctement cette réalité... c'est pour celà qu'il vaut mieux attendre que le système d'installation soit adapté plutôt que d'essayer de "trancher" et de ne pas faire les choses dans les règles de l'art.
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 3.
La compartimentation des diférents dépôts est une méthode pour garder des logiciels groupés par license, mode de support, ... et main est un dépôt normalement réservé aux éléments de base 100% libres et supportés par les devs de debian.
Mettre du contenu qui n'est pas libre dans main, c'est mélanger des éléments qui n'ont ni la même méthode de gestion, ni la même méthode de support, ni les mêmes licenses.
Par contre, mettre les firmwares non-libres hors de main, mais permettre éventuellement que des éléments de main puissent dépendre de ces éléments non-libres serait peut-être une solution.
Ok, c'est un peu moins élégant qu'une belle structure en oignon des dépôts, mais je pense qu'avant tout, les firmwares non-libres sont une question organisationnelle, et qu'il faut une solution organisationnelle pour permettre aux utilisateurs de profiter au moins des fonctionnalités de base de leur hardware sans pour autant mélanger des éléments qu'il vaudrait sans doutes mieux garder séparés.
Le problème, c'est que vraissemblablement il y a urgence. Du coup, des deux côtés certains prônent le bâclage: certains préfèrent qu'on sacrifie la structure et qu'on mélange les torchons et les serviettes, et d'autres préfèrent tout virer sous couvert de pureté philosophique pour ne pas avoir à se poser de questions... la bonne solution se trouve sans doutes dans un petit report et une approche à tête reposée du problème.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à -1.
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 10.
Les fabriquants de matos n'ont pas besoin de l'autoriastion de la communauté du libre pour continuer à faire des firmwares proprio. Ensuite, par leur nature véritablement liée au matos, ceux-ci n'interfèrent aucunement avec le logiciel libre.
Au lieu de perdre du temps à courrir derrière les firmwares, il serait bien plus intéressant de faire du lobbying pour obtenir les spécifications et/ou des pilotes libres pour les différents périphériques dont les seuls pilotes sont encore proprios.
Un firmware proprio n'empèche pas d'utiliser du matériel avec un noyau 100% libre, un firmware proprio n'empèche pas d'utiliser un périphérique sur une machine avec une autre architecture, un firmware proprio ne donne pas le pouvoir à un constructeur de stopper artificiellement la vie commerciale d'un produit.
Par contre, un pilote proprio teinte le noyau avec des éléments non contrôlables, un pilote proprio empèche de changer d'architecture si la nouvelle n'est pas supportée, un pilote proprio permet à un constructeur de décider qu'à partir de la version x du noyau, les gens n'ont qu'à acheter la nouvelle version du matos.
Faire du lobbying pour libérer les firmwares est une perte de temps.
Le plus important en ce qui concerne le matériel, c'est de libérer les pilotes.
Le plus important en ce qui concerne les firmwares, c'est d'avoir la permission de les redistribuer de manière illimitée lorsque ceux-ci sont indispensables pour pouvoir initialiser du matériel vital au bon fonctionnement de la machine.
En ce qui concerne les firmwares proprio dans debian, il est clair que leur place n'est pas dans main, il faut les mettre ailleurs.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par ragoutoutou . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 3.
Le vrai problème n'est pas idéologique mais signalétique: mettre des éléments non-libres dans un dépôt qui a pour vocation de ne contenir que du 100% libre est un transgression des règles d'organisation des dépôts, et est donc peu judicieux car une fois ces éléments non-libres dans le dépôt, celà risque d'être difficile de les retirer.
Il y a des dépôts pour les éléments non-libres, et ces dépôts doivent pouvoir être invoqués lorsque l'utilisation des éléments non-libres est incontournable.
Pour moi, il ne faut pas mélanger des éléments non-libres à main, mais en revanche, il faut assurer que le système soit en mesure de faire le minimum syndical lors de l'installation et de l'utilisation.
En aucun cas l'utilisation de firmwares non-libres n'altère tes libertés par rapport aux logiciels libres de la distribution, le tout est de pouvoir les garder séparés du reste de la distribution afin que ceux-ci ne compliquent l'exercice du droit à la redistribution des éléments libres.
[^] # Re: Supprimer la redevance ?
Posté par ragoutoutou . En réponse à la dépêche Premières réactions politiques à DADVSI. Évalué à 9.
d'après ce texte, attaquer la redevance, c'est armer les adversaires de la copie privée.
Maintenant que ceux-ci ont les pleins pouvoirs pour bloquer la copie privée par le biais des DRM, y a t'il encore une raison valable de ne pas attaquer cette redevance?
Vu dans le texte...
Je trouve que cette portion du texte est tout simplement lamentable: si c'était vraiment donnant-donnant, on ne se retrouverait pas avec ET la taxe qui est supposée ET le DADVSI.
De plus, les droits d'auteur sont bel et bien des droits offerts par la société dans un désir de rémunérer ceux qui la font avancer culturellement. En aucun cas il ne s'agit d'un droit divin.
Le comportement actuel de l'industrie est "ce qui est à moi est à moi, et ce qui est à vous est négociable", et je ne vois pas au nom de quoi il faudrait continuer à l'accepter.
# Fabius va nous sauver...
Posté par ragoutoutou . En réponse à la dépêche Premières réactions politiques à DADVSI. Évalué à 10.
... formidable d'avoir un porte drapeau de poids comme lui dans la lutte contre le dadvsi, là, maintenant, on se sent sauvé... Bon, c'est vrai que sa prise de position remonte à ... août 2006, mais il a su comprendre l'importance du débat et la nécessité de rallier tous les mécontents de cette loi à sa cause: les présidentielles de 2007...
Même pas un mot à propos des députés PS qui se sont battus contre le DADVSI...
Il reste bien démago le fafa...
</alerte récupération politique>
[^] # Re: C'est con ce que je vais dire mais...
Posté par ragoutoutou . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 2.
Je pense que nos sociétés occidentales sont occupées à sombrer dans l'obscurantisme, le fascisme, et qu'il va falloir serrer les dents car on est partis pour un bout de temps avant que les gens ne se resaisissent.
[^] # Re: Une percée de .NET???
Posté par ragoutoutou . En réponse à la dépêche Un point sur Java et l'Open-Source. Évalué à 3.
[^] # Re: Ma politique WEP
Posté par ragoutoutou . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 3.
Pas efficace...
Le mieux, si tu es condamné au wep, c'est d'utiliser un système vpn au dessus (ou au pire du ssh avec port forwarding), mais il faut que ton access point le supporte (si c'est un access point maison, pas de problèmes, sinon, c'est plus dur)... dès lors, la personne désireuse de pirater ta connexion est coincée car seules les sessions encapsulées dans le vpn ou le tunnel ssh sont autorisées.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à 3.
Pour laquelle j'avais naïvement cru bon de préciser les combinaisons les plus fréquentes de combinaisons proc/chipset dans les pc's visant les grandes entreprises et administrations.
De là on en est arrivé à l'étape où tu déclares
Alors, à part le cas où tu me montres un appel d'offre spécifiant explicitement que l'administration exige des processeurs de marque Intel (ce qui serait sans doutes illégal), impose qu'une technologie comme l'hyperthreading soit présente (meilleur moyen de virer amd en douce dans un appel d'offre biaisé), ou des exemples d'offres qui ont été refusées sur base du fait que le processeur proposé dans l'offre était un amd, tes déclarations sont non-fondées.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à 2.
Non seulement les amd sont présents dans les gammes des constructeurs, mais ils se vendent... la preuve, au boulot (institution financière assez conservatrice avec env 30.000 pc's), toutes les nouvelles machines de bureau sont des amd64, et les thin clients sont à base Athlon XP-M.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à 4.
Les administrations et grandes entreprises croient surtout leurs fournisseurs. Si HP ou IBM dit que les amd sont bons, et offrent de bonnes conditions, les entreprises achètent amd. L'important, ce n'est pas la marque de cpu (sauf pour certains religieux), mais leurs possibilités et surtout l'intégration dans une plateforme orientée entreprise.