Généraliser le modèle à des systèmes basés sur Linux avec des propos radicaux (oui j'ai bien conscience qu'ils sont humoristiques, ils n'en restent pas moins radicaux) comme le fait Matthew Garret est une erreur, car le système s'adresse selon le niveau aussi bien à des end users sur une plateforme matérielle (quasi) inconnue, auquel cas le système aura bien du mal à prendre les meilleurs décisions pour cause de méconnaissance de la machine et de son environnement (sauf dans un cas futur hypothétique ou les pilotes Linux auraient gagné d'un ordre de grandeur en qualité + les constructeurs de laptop mettraient parallèlement le paquet sur le support des systèmes à base de Linux par leur matos) et l'utilisateur peut réussir à obtenir de meilleurs résultats - d'autre part Linux peut aussi s'adresser à un ingé en train de concevoir un système embarqué auquel cas les capacités de mise au point de l'aspect économie d'énergie devront être le plus souple possible et facile d'accès.
Bref son discours radical me fait un peu peur car je crains qu'il ne reste valable que sur un faible nombre d'ordinateurs portables high end et très modernes (et sous Linux...), dont probablement le sien.
Ça représente vraisemblablement une très faible proportion de tous les systèmes Linux intéressés par les économies d'énergies (cad par les temps qui cours presque tous)
Son raisonnement dépend en plus d'un trop grand nombre de variables et sa vérité actuelle peut donc s'inverser à tout moment, avec alors un risque de laisser les utilisateurs dans la merde s'il n'y a rien pour adapter facilement le soft dans ce cas là.
La grande majorité de son article n'est pas sujette à polémique mais tout n'est pas aussi tranché qu'il veut bien le faire croire.
D'abord cela dépend bien évidemment du processeur (et oui, il existe encore des gens vaguement sensés qui ne changent pas de laptop une fois tous les deux mois) et donc il faut conserver la possibilité dans le soft d'avoir d'un comportement différent sur secteur et sur batterie.
Ensuite il ne prend pas en compte la consommation d'un ventilateur. Si on la prend en compte, maintenir la température suffisamment basse pour éviter qu'il ne se déclenche peut être avantageux dans le bilan calculs effectués / énergie consommées.
On pourrait résumer en disant que le droit d'auteur permet au détenteur, heureusement, de choisir ce qu'il fait de l'oeuvre.
Chacun choisira en son âme et conscience les conditions sous lesquels il souhaite contribuer.
Le logiciel libre permet, ne l'oublions pas, le fork.
Concernant le multi-licensing copyleft + (libre non copyleft ou proprietaire), je crois pour ma part que refuser sans conditions ce modèle ferait plus de mal que de bien au Logiciel Libre. Par contre je suis assez contre le modèle de logiciel distribué bridé ou en retard en libre et complet ou en premier en propriétaire, aussi bien pour des raisons pratiques que parce que le Logiciel Libre ne doit pas se transformer en simple argument commercial d'appel.
Ouai enfin bon la base de code que gère MS est quand meme grande, et le fait est qu'ils _ont_ découvert le problème avant la sortie officielle. Donc sur ce coup la je crois qu'il faut dire bravo ! Je préfère les logiciels qui ont le moins de bug possible, et je crois que c'est le cas de beaucoup de monde...
Je pense qu'il faut voir le code C produit par Lisaac comme une étape de précompilation
Un compilateur ne produit pas forcément de l'assembleur. Le compilateur Lisaac est un compilateur de plein droit.
Et effectivement le code C produit n'est plus le source, et si quelqu'un s'amusait à rajouter des blobs en C issues d'une compilation Lisaac dans la distribution d'un programme GPL et qu'il distriburait le résultat sans fournir les sources Lisaac, il violerait clairement la GPL.
Je pense que son "tu ne comprends pas ce que je dis" s'adressait uniquement à la question de l'assembleur, qui effectivement ne permet pas la concision (sauf cas extrèment particulier)
En fait la concision n'est pas tant liée aux nombre de symboles et de paramètres des opérations élémentaires d'un langage qu'à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes. Le cerveau humain étant ce qu'il est, la concision est souvent souhaitable afin de permettre au programmeur d'avoir plus de choses en tête à un instant T, le langage influant à mon avis fortement sur la manière de penser pendant un développement. La possibilité de concision est fortement liée aux abstractions fournies par un langage.
Alors évidemment on peut faire du concis qui ne soit pas particulièrement clair (à la one liner Perl qui descramble du CSS :D ), mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.
Je suis plutôt d'accord. Néanmoins la verbosité n'est pas complètement décorrelée du niveau du langage, surtout d'un point de vue pratique : il est beaucoup plus difficile (généralement...) d'être concis en utilisant un langage de bas niveau, et les abstractions fournies par les langages de haut niveau n'auraient en pratique pas beaucoup d'interêt s'il fallait au final écrire 10x plus de code qu'en ASM (sauf si on ne documente pas son code ASM :)
Disons que si les abstractions ne permettent pas la concision, elles sont moins intéressantes en terme de productivité.
En ce qui concerne les bench d'alioth, les programmes sont très courts et à mon avis on ne peut pas vraiment estimer et comparer les concisions des langages sans prendre en compte certaines caractéristiques comme le niveau du typage. Sans compter que le paradigme peut jouer énormement selon le type de problème posé (penser à du backtracking en logique versus en impératif ... :)
Et dire que sur mon pauvre vieux laptop de l'an de grâce 2003, il me suffit d'appuyer sur deux touches depuis n'importe quel OS pour basculer sur la sortie VGA (ou du dual screen VGA + LCD)...
Les gens voient souvent du "retard" là où ne se trouve que du mauvais matériel et du mauvais logiciel (ACPI, ...), et pire que tout, de vilaines régressions dues à d'horribles absences de documentation.
Vu l'absence total d'exigence des moutons^W^W du grand public pour qui ça ne passe même plus par la tête d'aller faire un scandale pas possible au SAV en exigeant d'avoir un système qui fonctionne correctement dans la minute (je parle pas de l'auteur du journal qui en a plus ou moins rien à foutre de Windows, mais de l'acheteur moyen qui s'est fait simultanément retourné le cerveau par MS, ce dernier ayant finalement réussi à lui inculquer que tous les dysfonctionnement de l'ordinateur même neuf était de sa faute (à l'utilisateur) et que "c'est normal que ca bug, c'est de l'informatique!") car il est inadmissible qu'en 2008 on puisse vendre impunément des systèmes sur lesquels le son promis ne fonctionne pas, et qui ne sont même pas foutu de pouvoir utiliser les périphériques USB les plus courant (lesquels ne sont même pas foutu de fonctionner sur les-dits ordinateurs), il n'est pas étonnant que le niveau de qualité général des machines à bas coût baisse.
Donc en fait, il y a un truc sur lequel je ne suis pas mais alors pas en phase du tout avec l'auteur du journal, c'est ce paragraphe :
De retour chez moi, je déballe la chose comme un gamin à Noël, et note au passage, que le rapport qualité/prix des ordinateurs de marque s'est nettement amélioré, à un tel point d'ailleurs que le marché de l'assemblé, qui je crois représente encore la moitié des ventes, pourrait bien y perdre des plumes à l'avenir.
J'ai du mal à comprendre en quoi un produit qui ne fonctionne pas du tout à sa sortie du carton (visiblement il est affecté par de multiples défauts de conception dont certains sont probablement irréparables à l'heure actuelle) peut constituer un progrès en terme de rapport qualité prix, alors qu'un système équivalent construit from scratch ou modifié à partir du premier directement par le consommateur est exempt des mêmes défauts : autrement dit, les constructeurs auront bon tenter de faire du matériel plus ou moins fonctionnel (et je suis là encore très réservé sur la qualité de ce que les "marques" concoivent), au moment où ils cèdent à l'Empire (qui certes, les tiens par les couille et serre très fort) et foutent du soft pourri, ils se condamnent à vendre un produit pourri (qui de plus engage leur responsabilité)
Décidément j'admire Microsoft qui réussi le tour de force d'imposer ses logiciels infects en disant aux constructeurs : donnez moi plein d'argent et en retour vous n'arriverez même pas à mettre des produits fonctionnels sur le marché.
En même temps des gens qui mettent Windows à toutes les sauces (même les plus inadaptées), ça existe. Même chose pour Linux d'ailleurs, sauf que ce dernier s'assaisonne plus facilement.
D'autant que s'ils sont désactivés c'est très probablement que le réseau n'est plus là
Si mes souvenirs sont bons les XO permettent de créer des réseaux meshés.
C'est justement ce type de réseaux qui est extrêmement utile après une catastrophe ayant détruit les infras.
Ceci étant pour que les infras restent détruites pendant 21 jours et qu'aucun autre réseau de secours n'ait pu être créé entre temps, faut probablement un énorme cataclysme.
C'est une vision bien au chaud, depuis un pays démocratique. Je ne suis pas sûr que si on expose les risques aux populations de certains pays moins démocratique, la population réagisse comme ça. Tout ton post occulte totalement les problèmes exposés par le papier. Tu dis "ensuite, le XO n'est PAS la potion magique de la démocratie et de l'épanouissement de tous" là encore tout le monde est d'accord, mais c'est prendre les choses à l'envers : le XO n'a jamais prétendu être ça, mais il risque d'être l'inverse et je maintiens que c'est inquiétant. On est aussi tous d'accord que le XO pourrait être un outil d'éducation et qu'il ne se fera pas sans les gouvernement ; ce qu'on traite ici c'est son modèle de sécurité qui est sujet à caution, et ce n'est pas parcequ'il ne se fera pas sans les gouvernements qu'il faut obligatoirement choisir ce modèle de sécurité précisemment.
Sans compter que les risques de détournement totalitaires ne sont pas les seuls exposés par le papier.
PHP et hal j'ai un énorme doute, mais Python est plutôt mieux spécifié que la moyenne des softs libres...
Mais les gouvernements n'ont pas besoin de ça s'ils veulent assurer un contrôle sur les citoyens.
Hm, peut-être mais je sens que ça va bien en arranger certains.
Le côté pervers est due selon moi au fait que les enfants ne seront justement pas au courant des risques induits par le modèle choisi de sécurités/confidentialités dans leur contexte politique, et qu'ils ne pourront donc pas refuser d'utiliser le XO à cause de ça.
Sauf que c'est de la rhétorique qui ne fait rien de plus que de jouer sur le sens des mots. Dans la citation de Benjamin Franklin, le sens qu'il donne à liberté n'a strictement rien à voir avec le fait d'entreprendre toutes les actions malfaisante qui pourraient nous passer par la tête.
Si tu estimes que tes "futur employeurs potentiels" risquent de se facher contre toi à cause de ça, je pense que tu dois d'urgence chercher d'autres futur employeurs potentiels un peu plus intelligents.
Il y a aussi des bugs dans les microprocesseurs (surtout ceux avec l'ISA toute pourrie qui c'est répandu pour la même raison que Windows), quelque fois extrêmement graves et pas du tout contournables par le soft sans diviser les perfs par 3.
Tu ne peux pas non plus patcher le microcode de ton processeur avec des trucs perso (et des fois je me dis "tant mieux, sinon j'ose pas imaginer la puissance que les rootkits pourrait avoir et le bordel que ca induirait encore plus sur le net")
Je pense qu'il faut voir les choses en tant que "ça serait vraiment génial si on avait des tonnes de docs et ptet même pleins de sources du constructeur pour faire mumuse ou faire des trucs plus sérieux genre transformer du matos bon marché en un truc super robuste à force de travailler dessus."
Mais on ne peut pas prétendre que quand ça n'est pas le cas ça empiète sur les libertés dans le plan OS ou applicatif.
En fait il n'y a, à ma connaissance, que gNewSense qui cherche à pousser le principe du libre jusqu'à virer les firmwares.
Après tout, les gens ont le droit de faire ce qui les intéresse et si créer des repos, des galettes et des miroirs dans lesquels le moindre "bit" respectera les 4 principes du LL est leur passion, c'est leur "problème" ; mais de mon point de vue extérieur à leur combat je trouve ça bien trop excessif. En effet dans 99% des cas, une carte/puce utilisant un firmware donné est équivalent à un ASIC ; simplement la solution programmable peut être reconfigurée, typiquement pour corriger une anomalie. Au final, sauf à se refuser d'utiliser la moindre puce fondue n'ayant pas une conception diffusée selon des termes satisfaisant les quatre libertés du logiciel libre (et là on voit déjà qu'il y a un problème : les libertés en question font certes référence en matière de logiciel, mais en aucun cas concernant quelque chose qui n'en est pas), j'estime que c'est bien présomptueux que de refuser d'héberger le moindre bit libre sur un support qui lui même est sans aucun doute le résultat de l'intégration de 3 tonnes de technologies 300% propriétaires.
La distinction "tourne sur le CPU ou non" est totalement censée (à la fois techniquement et aussi de part ses implications philosophiques), et ne pas la prendre en compte relève probablement d'un extrémisme ayant une part d'irréfléchi.
Pourquoi serait-il plus acceptable d'utiliser une carte disposant d'une ROM ou d'une flash stockant exactement les mêmes bits que ceux que refusent d'approcher les mainteneurs de gNewSense quand il s'agit de disque dur ou de CD-ROM. Qu'elle est la valeur ajouté d'une telle suppression de firmware vis-à-vis des quatre libertés pour l'utilisateur ? Négative, puisque l'on perd sans rien gagner ! Il est pour lui encore plus difficile de reverse le FW contenu dans une Flash/ROM, voir la structure d'un ASIC, que si un FW est stocké sur un CD / HD et est librement diffusable.
gNewSense procède donc à mon sens plus à la redéfinition "sauvage" du concept de LL qu'à autre chose, et j'ai du mal à comprendre pourquoi Stallman les soutient.
Sauf qu'il faut avoir une vision bien réductrice de la notion de coût pour croire que le logiciel libre est complètement "gratuit", dans tous les sens du terme.
Il est certes d'un coût monétaire négligeable à l'acquisition, dans bien des cas. Dans d'autres domaines, il est très loin d'être gratuit face à la concurrence. Prétendre le contraire n'est que se voiler la face.
Ce coût monétaire négligeable courant peut et doit servir d'attraction, pour faire découvrir les vrais intérêts du LL. Mais quelqu'un pour qui cela reste simplement comme le seul critère avantageux du LL risque vite de se rendre compte qu'il se fait malheureusement exploser dans d'autres domaines, et s'il n'a pas compris l'intérêt intrinsèque du LL, n'ayant rien d'autre à opposer à ses inconvénients (hormis le coût monétaire, mais qui dans le contexte n'aura plus la même valeur à ses yeux), il s'en retournera malheureusement vers ses horizons initiaux, plus obscures.
Bref ces personnes qui, pour un temps, voient le LL comme intéressant car ne leur faisant pas débourser d'argent dans une situation donnée risquent fort de ne pas constituer un vivier fiable de défenseurs et contributeurs du LL à long terme. Ils risquent d'être beaucoup trop sensibles à la propagande des opposants extrémistes au LL.
Si l'on veut que le logiciel libre perdure, il faut leur faire découvrir les autres avantages ; comprendre que les biens immatériels sont non-rivaux - par le porte-monnaie ! - est certes un début, mais il ne faut surtout pas s'arrêter là. La prise de conscience de tous les aspects philosophiques et économiques des logiciels libres est, je crois, la seule façon de les convertir durablement.
Honnêtement si tu fais pas de relationnel, je vois mal l'intérêt de stocker ta conf dans un fichier binaire... Faire chier le monde ?
(et je suis pas fan du tout du XML non plus pour de la conf)
Pour des chunks de binaires, c'est déjà plus intéressant.
Concernant la qualité de la biblio, si quelqu'un a envie d'y contribuer je lui suggère amicalement de commencer par réduire la complexité de la fonction _eet_data_descriptor_decode(), qui est vraiment totalement inabordable.
Heureusement elle fait un peu exception et la plupart du code semble assez bon.
Si la stratégie de MS c'est juste d'énerver ses plus farouches adversaires à longueur de journée au lieu de 1) leur opposer des arguments fins et 2) remonter les vrais problèmes dénoncés à longueur de temps par les utilisateurs et aussi des techniciens compétents (voir les deux à la fois), afin d'améliorer leurs produits, alors non seulement ils continueront à faire de la merde mais en plus ils n'ont aucune chance de faire changer d'avis la moitié de la planète qu'ils se sont mis à dos. Drôle de stratégie.
hm en fait j'oubliais que quand on abuse de sa situation monopolistique pour bloquer tout le marché, on peut faire un peu tout ce qu'on veut : de la merde et se mettre à dos le plus de monde possible - ça n'influe pas sur les ventes.
[^] # Re: gnu/linux
Posté par Guillaume Knispel . En réponse au journal Sur la philosophie de M. Stallman. Évalué à 5.
Quand à Linux sans GNU (ou du moins avec très très peu de GNU), c'est très courant dans l'embarqué.
[^] # Re: Pas à l'utilisateur de deviner
Posté par Guillaume Knispel . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 8.
Généraliser le modèle à des systèmes basés sur Linux avec des propos radicaux (oui j'ai bien conscience qu'ils sont humoristiques, ils n'en restent pas moins radicaux) comme le fait Matthew Garret est une erreur, car le système s'adresse selon le niveau aussi bien à des end users sur une plateforme matérielle (quasi) inconnue, auquel cas le système aura bien du mal à prendre les meilleurs décisions pour cause de méconnaissance de la machine et de son environnement (sauf dans un cas futur hypothétique ou les pilotes Linux auraient gagné d'un ordre de grandeur en qualité + les constructeurs de laptop mettraient parallèlement le paquet sur le support des systèmes à base de Linux par leur matos) et l'utilisateur peut réussir à obtenir de meilleurs résultats - d'autre part Linux peut aussi s'adresser à un ingé en train de concevoir un système embarqué auquel cas les capacités de mise au point de l'aspect économie d'énergie devront être le plus souple possible et facile d'accès.
Bref son discours radical me fait un peu peur car je crains qu'il ne reste valable que sur un faible nombre d'ordinateurs portables high end et très modernes (et sous Linux...), dont probablement le sien.
Ça représente vraisemblablement une très faible proportion de tous les systèmes Linux intéressés par les économies d'énergies (cad par les temps qui cours presque tous)
Son raisonnement dépend en plus d'un trop grand nombre de variables et sa vérité actuelle peut donc s'inverser à tout moment, avec alors un risque de laisser les utilisateurs dans la merde s'il n'y a rien pour adapter facilement le soft dans ce cas là.
# un peu trompeur
Posté par Guillaume Knispel . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 5.
D'abord cela dépend bien évidemment du processeur (et oui, il existe encore des gens vaguement sensés qui ne changent pas de laptop une fois tous les deux mois) et donc il faut conserver la possibilité dans le soft d'avoir d'un comportement différent sur secteur et sur batterie.
Ensuite il ne prend pas en compte la consommation d'un ventilateur. Si on la prend en compte, maintenir la température suffisamment basse pour éviter qu'il ne se déclenche peut être avantageux dans le bilan calculs effectués / énergie consommées.
# hm
Posté par Guillaume Knispel . En réponse au journal La GNU GPL est-elle suffisante?. Évalué à 3.
Chacun choisira en son âme et conscience les conditions sous lesquels il souhaite contribuer.
Le logiciel libre permet, ne l'oublions pas, le fork.
Concernant le multi-licensing copyleft + (libre non copyleft ou proprietaire), je crois pour ma part que refuser sans conditions ce modèle ferait plus de mal que de bien au Logiciel Libre. Par contre je suis assez contre le modèle de logiciel distribué bridé ou en retard en libre et complet ou en premier en propriétaire, aussi bien pour des raisons pratiques que parce que le Logiciel Libre ne doit pas se transformer en simple argument commercial d'appel.
À part ça attention tu te répètes un peu... ( https://linuxfr.org/~GPL/26461.html )
[^] # Re: Oups, j'ma gourré...
Posté par Guillaume Knispel . En réponse au journal Victoire de RMS sur Microsoft. Évalué à 2.
S'ils doivent faire le portage pour l'occasion, la petite fortune qu'ils demandent est ptet justifiée ?
[^] # Re: Oups, j'ma gourré...
Posté par Guillaume Knispel . En réponse au journal Victoire de RMS sur Microsoft. Évalué à 3.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Guillaume Knispel . En réponse au journal Lisaac plus rapide que le C !. Évalué à 5.
Un compilateur ne produit pas forcément de l'assembleur. Le compilateur Lisaac est un compilateur de plein droit.
Et effectivement le code C produit n'est plus le source, et si quelqu'un s'amusait à rajouter des blobs en C issues d'une compilation Lisaac dans la distribution d'un programme GPL et qu'il distriburait le résultat sans fournir les sources Lisaac, il violerait clairement la GPL.
[^] # Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
En fait la concision n'est pas tant liée aux nombre de symboles et de paramètres des opérations élémentaires d'un langage qu'à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes. Le cerveau humain étant ce qu'il est, la concision est souvent souhaitable afin de permettre au programmeur d'avoir plus de choses en tête à un instant T, le langage influant à mon avis fortement sur la manière de penser pendant un développement. La possibilité de concision est fortement liée aux abstractions fournies par un langage.
Alors évidemment on peut faire du concis qui ne soit pas particulièrement clair (à la one liner Perl qui descramble du CSS :D ), mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.
[^] # Re: Langage de "très haut niveau"?
Posté par Guillaume Knispel . En réponse au journal Lisaac plus rapide que le C !. Évalué à 4.
Disons que si les abstractions ne permettent pas la concision, elles sont moins intéressantes en terme de productivité.
En ce qui concerne les bench d'alioth, les programmes sont très courts et à mon avis on ne peut pas vraiment estimer et comparer les concisions des langages sans prendre en compte certaines caractéristiques comme le niveau du typage. Sans compter que le paradigme peut jouer énormement selon le type de problème posé (penser à du backtracking en logique versus en impératif ... :)
[^] # Re: 3615 Ma vie
Posté par Guillaume Knispel . En réponse au journal Die Hard : une journée en enfer. Évalué à 10.
Les gens voient souvent du "retard" là où ne se trouve que du mauvais matériel et du mauvais logiciel (ACPI, ...), et pire que tout, de vilaines régressions dues à d'horribles absences de documentation.
Vu l'absence total d'exigence des moutons^W^W du grand public pour qui ça ne passe même plus par la tête d'aller faire un scandale pas possible au SAV en exigeant d'avoir un système qui fonctionne correctement dans la minute (je parle pas de l'auteur du journal qui en a plus ou moins rien à foutre de Windows, mais de l'acheteur moyen qui s'est fait simultanément retourné le cerveau par MS, ce dernier ayant finalement réussi à lui inculquer que tous les dysfonctionnement de l'ordinateur même neuf était de sa faute (à l'utilisateur) et que "c'est normal que ca bug, c'est de l'informatique!") car il est inadmissible qu'en 2008 on puisse vendre impunément des systèmes sur lesquels le son promis ne fonctionne pas, et qui ne sont même pas foutu de pouvoir utiliser les périphériques USB les plus courant (lesquels ne sont même pas foutu de fonctionner sur les-dits ordinateurs), il n'est pas étonnant que le niveau de qualité général des machines à bas coût baisse.
Donc en fait, il y a un truc sur lequel je ne suis pas mais alors pas en phase du tout avec l'auteur du journal, c'est ce paragraphe :
De retour chez moi, je déballe la chose comme un gamin à Noël, et note au passage, que le rapport qualité/prix des ordinateurs de marque s'est nettement amélioré, à un tel point d'ailleurs que le marché de l'assemblé, qui je crois représente encore la moitié des ventes, pourrait bien y perdre des plumes à l'avenir.
J'ai du mal à comprendre en quoi un produit qui ne fonctionne pas du tout à sa sortie du carton (visiblement il est affecté par de multiples défauts de conception dont certains sont probablement irréparables à l'heure actuelle) peut constituer un progrès en terme de rapport qualité prix, alors qu'un système équivalent construit from scratch ou modifié à partir du premier directement par le consommateur est exempt des mêmes défauts : autrement dit, les constructeurs auront bon tenter de faire du matériel plus ou moins fonctionnel (et je suis là encore très réservé sur la qualité de ce que les "marques" concoivent), au moment où ils cèdent à l'Empire (qui certes, les tiens par les couille et serre très fort) et foutent du soft pourri, ils se condamnent à vendre un produit pourri (qui de plus engage leur responsabilité)
Décidément j'admire Microsoft qui réussi le tour de force d'imposer ses logiciels infects en disant aux constructeurs : donnez moi plein d'argent et en retour vous n'arriverez même pas à mettre des produits fonctionnels sur le marché.
[^] # Re: Coder pour linux
Posté par Guillaume Knispel . En réponse à la dépêche Le noyau Linux 2.6.25 est disponible. Évalué à 6.
[^] # Re: grosseur
Posté par Guillaume Knispel . En réponse à la dépêche Le noyau Linux 2.6.25 est disponible. Évalué à 4.
Nan ça pourrait pas.
[^] # Re: Mouais
Posté par Guillaume Knispel . En réponse à la dépêche Effets pervers du modèle de sécurité BitFrost de OLPC. Évalué à 2.
Si mes souvenirs sont bons les XO permettent de créer des réseaux meshés.
C'est justement ce type de réseaux qui est extrêmement utile après une catastrophe ayant détruit les infras.
Ceci étant pour que les infras restent détruites pendant 21 jours et qu'aucun autre réseau de secours n'ait pu être créé entre temps, faut probablement un énorme cataclysme.
[^] # Re: Effets pervers ?
Posté par Guillaume Knispel . En réponse à la dépêche Effets pervers du modèle de sécurité BitFrost de OLPC. Évalué à 8.
Sans compter que les risques de détournement totalitaires ne sont pas les seuls exposés par le papier.
[^] # Re: Effets pervers ?
Posté par Guillaume Knispel . En réponse à la dépêche Effets pervers du modèle de sécurité BitFrost de OLPC. Évalué à 10.
Mais les gouvernements n'ont pas besoin de ça s'ils veulent assurer un contrôle sur les citoyens.
Hm, peut-être mais je sens que ça va bien en arranger certains.
Le côté pervers est due selon moi au fait que les enfants ne seront justement pas au courant des risques induits par le modèle choisi de sécurités/confidentialités dans leur contexte politique, et qu'ils ne pourront donc pas refuser d'utiliser le XO à cause de ça.
[^] # Re: Éternel problème
Posté par Guillaume Knispel . En réponse à la dépêche Effets pervers du modèle de sécurité BitFrost de OLPC. Évalué à 10.
[^] # Re: Re:
Posté par Guillaume Knispel . En réponse au journal Corpus des fonctionnaires contre les étudiants. Évalué à 7.
[^] # Re: Je crois pas que ca soit si grave...
Posté par Guillaume Knispel . En réponse au journal OpenBSD et Richard Stallman. Évalué à 4.
Tu ne peux pas non plus patcher le microcode de ton processeur avec des trucs perso (et des fois je me dis "tant mieux, sinon j'ose pas imaginer la puissance que les rootkits pourrait avoir et le bordel que ca induirait encore plus sur le net")
Je pense qu'il faut voir les choses en tant que "ça serait vraiment génial si on avait des tonnes de docs et ptet même pleins de sources du constructeur pour faire mumuse ou faire des trucs plus sérieux genre transformer du matos bon marché en un truc super robuste à force de travailler dessus."
Mais on ne peut pas prétendre que quand ça n'est pas le cas ça empiète sur les libertés dans le plan OS ou applicatif.
[^] # Re: Je crois pas que ca soit si grave...
Posté par Guillaume Knispel . En réponse au journal OpenBSD et Richard Stallman. Évalué à 3.
Après tout, les gens ont le droit de faire ce qui les intéresse et si créer des repos, des galettes et des miroirs dans lesquels le moindre "bit" respectera les 4 principes du LL est leur passion, c'est leur "problème" ; mais de mon point de vue extérieur à leur combat je trouve ça bien trop excessif. En effet dans 99% des cas, une carte/puce utilisant un firmware donné est équivalent à un ASIC ; simplement la solution programmable peut être reconfigurée, typiquement pour corriger une anomalie. Au final, sauf à se refuser d'utiliser la moindre puce fondue n'ayant pas une conception diffusée selon des termes satisfaisant les quatre libertés du logiciel libre (et là on voit déjà qu'il y a un problème : les libertés en question font certes référence en matière de logiciel, mais en aucun cas concernant quelque chose qui n'en est pas), j'estime que c'est bien présomptueux que de refuser d'héberger le moindre bit libre sur un support qui lui même est sans aucun doute le résultat de l'intégration de 3 tonnes de technologies 300% propriétaires.
La distinction "tourne sur le CPU ou non" est totalement censée (à la fois techniquement et aussi de part ses implications philosophiques), et ne pas la prendre en compte relève probablement d'un extrémisme ayant une part d'irréfléchi.
Pourquoi serait-il plus acceptable d'utiliser une carte disposant d'une ROM ou d'une flash stockant exactement les mêmes bits que ceux que refusent d'approcher les mainteneurs de gNewSense quand il s'agit de disque dur ou de CD-ROM. Qu'elle est la valeur ajouté d'une telle suppression de firmware vis-à-vis des quatre libertés pour l'utilisateur ? Négative, puisque l'on perd sans rien gagner ! Il est pour lui encore plus difficile de reverse le FW contenu dans une Flash/ROM, voir la structure d'un ASIC, que si un FW est stocké sur un CD / HD et est librement diffusable.
gNewSense procède donc à mon sens plus à la redéfinition "sauvage" du concept de LL qu'à autre chose, et j'ai du mal à comprendre pourquoi Stallman les soutient.
[^] # Re: pas tout à fait d'accord
Posté par Guillaume Knispel . En réponse au journal de la destruction de l'éducation nationale en France.... Évalué à 6.
Il est certes d'un coût monétaire négligeable à l'acquisition, dans bien des cas. Dans d'autres domaines, il est très loin d'être gratuit face à la concurrence. Prétendre le contraire n'est que se voiler la face.
Ce coût monétaire négligeable courant peut et doit servir d'attraction, pour faire découvrir les vrais intérêts du LL. Mais quelqu'un pour qui cela reste simplement comme le seul critère avantageux du LL risque vite de se rendre compte qu'il se fait malheureusement exploser dans d'autres domaines, et s'il n'a pas compris l'intérêt intrinsèque du LL, n'ayant rien d'autre à opposer à ses inconvénients (hormis le coût monétaire, mais qui dans le contexte n'aura plus la même valeur à ses yeux), il s'en retournera malheureusement vers ses horizons initiaux, plus obscures.
Bref ces personnes qui, pour un temps, voient le LL comme intéressant car ne leur faisant pas débourser d'argent dans une situation donnée risquent fort de ne pas constituer un vivier fiable de défenseurs et contributeurs du LL à long terme. Ils risquent d'être beaucoup trop sensibles à la propagande des opposants extrémistes au LL.
Si l'on veut que le logiciel libre perdure, il faut leur faire découvrir les autres avantages ; comprendre que les biens immatériels sont non-rivaux - par le porte-monnaie ! - est certes un début, mais il ne faut surtout pas s'arrêter là. La prise de conscience de tous les aspects philosophiques et économiques des logiciels libres est, je crois, la seule façon de les convertir durablement.
[^] # Re: Non, pas du tout, efface !
Posté par Guillaume Knispel . En réponse au journal Etudes sur les sociétés s'impliquant le plus dans le développe du noyau Linux. Évalué à 6.
[^] # Re: C'est gonflé ...
Posté par Guillaume Knispel . En réponse au journal Etudes sur les sociétés s'impliquant le plus dans le développe du noyau Linux. Évalué à 4.
[^] # Re: Euh... Première page???
Posté par Guillaume Knispel . En réponse à la dépêche Eet passe en 1.0 alpha. Évalué à 4.
(et je suis pas fan du tout du XML non plus pour de la conf)
Pour des chunks de binaires, c'est déjà plus intéressant.
Concernant la qualité de la biblio, si quelqu'un a envie d'y contribuer je lui suggère amicalement de commencer par réduire la complexité de la fonction _eet_data_descriptor_decode(), qui est vraiment totalement inabordable.
Heureusement elle fait un peu exception et la plupart du code semble assez bon.
[^] # Re: Re:
Posté par Guillaume Knispel . En réponse au journal Prédiction du jour: OOXML sera accepté comme norme ISO. Ou pas.. Évalué à 3.
hm en fait j'oubliais que quand on abuse de sa situation monopolistique pour bloquer tout le marché, on peut faire un peu tout ce qu'on veut : de la merde et se mettre à dos le plus de monde possible - ça n'influe pas sur les ventes.
# nomachine
Posté par Guillaume Knispel . En réponse au journal Encore un GPL peu connu mais intéressant. Évalué à 1.