Beaucoup pensaient que MS-OOXML n'était qu'un format transitoire.
MS à faire n'importe quoi pour obtenir la certification et a accouché d'un monstre qu'il lui est trop coûteux d'implémenter. Il est donc claire que quasi personne n'imprémentera complètement cette merde.
Notons que la "norme" (avec des gros guillemets) ISO MS-OOXML n'est toujours pas sortie ...
Il ne lui reste que quelques jours.
Les dégâts sur la crédibilité de l'ISO sont énormes. L'ISO a été trourné en ridicule.
Mais MS aussi. Les dégâts sur MS sont énormes aussi.
Ma supposition :
- MS-OOXML est mort. Du moins n'est plus un "standard" perenne.
Partant de cette suppostion (qui est peut-être fausse), on peut envisager que MS va bosser plus dure sur son nouveau format (qui n'aura pas les merdes des anciens formats). Es-ce que MS va tenter à nouveau de le ratifier ? Pas sûr. Peut-être que finalement, vu que MS a un quasi monopole, MS ferait mieux de ne rien normaliser. Ceux qui veulent du normalisé passeront par ODF (que supportera réellement MS-Office). Ceux qui veulent MS-Office "full-feature & eye-candy" avec SharePoint et autres lock-in de MS, ben seront totalement verrouillé par MS. M'enfin, ça fait depuis des années qu'ils l'accèptent...
Quoiqu'il en soit, c'est globalement une bonne nouvelle pour ODF.
En passant, l'étude de New York sur ces besoins en stockage de documents bureautiques : http://www.oft.state.ny.us/Policy/ESRA/erecords-study.htm
Contrairement à ce que dit GrokLaw, il y a maintenant les documents aussi sous odf.
J'ai bien ça :
9. Increased numbers of formats for doing the same office tasks do not increase choice in any positive manner. Use of multiple formats increases complexity and ongoing costs. The use of single, standarized formats increases inefficiencies and furthers compatibility and interoperability. Choice comes into play in two ways: (a) the choices made by vendors to directly support accepted standards; and (b) the ability of the State to choose among vendors who support accepted standards.
La "réponse" de Fedora au problème qu'a eu Debian (Fedora n'a jamais nié qu'un problème de ce type puisse lui arriver) : http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamS(...)
All patches in Fedora spec files SHOULD have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example:
> les critiques récurrentes et acerbes des personnes qui n'en ont rien à foutre d'utiliser des firmwares proprios
Fedora-devel est une mailing ouverte. Donc forcément.
> et qui font chier tout le monde en disant que leur travail ne sert à rien
On le voit assez peu dans ce thread.
Alexandre Oliva (qui a fait et proposé kernel-libre, et qui est aussi à l'origine du thread) était un peu têtu ou c'est trop braqué.
En effet, beaucoup ne voit pas l'intérêt de virer les firmware. Par contre, il y a eu plus d'ouverture que tu ne le crois.
Alexandre Oliva veut garder son "fork". Ce qui lui est proposé comme direction, et à plusieurs reprise, est de bosser avec les mainteneurs noyaux, en upstream Linux, afin de trouver une vraie solution.
Même les développeurs qui n'ont rien à foutre des firmwares, accèptent cette démarche. Mais Alexandre Oliva ne veut rien entendre et c'est bien dommage.
L'un des gros problèmes est qu'il faut patcher le paquet upstream.
On pourrait imaginer, et ce directement upstream (sur http://www.kernel.org/), un paquet linux-2.6.28.tar.gz avec à côté et optionnellement linux-firmware-nonfree-2.6.28.tar.gz.
Il faudrait développer un mécanisme pour avoir les firmwares dans le noyau (c'est pour l'embarqué et réalisé à la compilation) ou hors du noyau (typiquement dans /lib/firmware). Le noyau Fedora étant construit que depuis linux-2.6.28.tar.gz. Après libre à chaqu'un de packager linux-firmware-nonfree si ça le chante. Comme d'autres sont libre de packager le driver proprio NVidia.
Cette démarche (dans les très très grandes lignes) est proposée à
Alexandre Oliva mais il fait la sourde oreille. Démarche aussi proposée par des gens qui n'ont rien à foutre des firmwares.
Espérons qu'Alexandre Oliva soit plus ouvert et qu'un consensus s'installe.
> parler d'une application développée avec C ou avec C++ ne voudrait pas dire grand chose ...
Ça veut dire qu'elle est développée en C ou C++. Pas en java ou C# ou python ou perl, etc.
Ça dit quelque chose. Ça dit aussi que ça utilise un language rapide à l'exécution. Il y a des noyaux développés en C, d'autres en C++, en Java, en C#. Ça fait une différence énorme (en empreinte mémoire et en vitesse).
Il y a des développeurs C qui connaissancent gtk+, mais ne savent pas développer en python des interfaces gtk+ (pourtant le binding python existe, il est excellent et très utilisé).
Peut-être que tu peux développer dans n'importe quel language car tu les connais tous, et tu te fous des performance. Mais tout le monde n'est pas comme toi.
> C'est parce que la langue est malléable qu'on a eu de grands auteurs qui ont sû en jouer.
> Je ne comprend pas en quoi cette formulation est une erreur.
Si tu ne connais pas Qt et KDE, "développé en Qt" indique que c'est développé en language Qt.
Je ne connais pas précisément les bindings de Qt, mais il me semble que tu n'es pas obligé de coder en C++ pour utiliser Qt.
Pour venir à un terrain que je connais mieux, dire "développé en gtk+" ne dit pas si c'est codé en C ou C++ ou perl ou python ou java ou vala ou php. Au mieux tu déduit seulement que ça utilise gtk+.
Lemon utilise aussi MySQL. Ça te conviendrait "développé en MySQL" ?
Un site web qui utilise apache/php/Mysql, ça te convient si on dit "développé en apache" ?
Comment tu fais pour les applis qui utilisent plusieurs toolkit (en fonction de la plateforme) ? Tu dis "développé en gtk+ et koala et win32" ?
Être imprécis c'est cool et être rigoureux c'est ringard.
Je suis un ringard.
> Sauf qu'on parle des semaphore kernel ici, pas des semaphores noyau.
???
M'enfin, je crois que je te suis.
J'ai bien compris qu'il y a un truc que ne comprend pas :-)
Il doit me manquer un élément pour que j'ai une vue d'ensemble cohérente.
Enre le semaphore qui est utilisés comme des mutex mais qu'il est super compliqué de remplacé par un mutex sans pertes de perfo car le semaphore est super optimisé mutex, ce n'est pas simple.
J'espérais qu'un commentaire ferait la lumière dans ce "bordel" (pour moi).
Mais j'aurai dû faire plus d'effort pour comprendre et ne pas espérer que l'explication tomberait toute cuite.
Tu tombes mal, j'ai bossé dans la sécurité (pas la sécurité informatique). En fait, plus la qualité, mais il y a plein de points communs.
J'ai bien essayé de faire passer qu'il y a le responsable sécurité (ou l'expert sécurité) et le client. Tu n'as pas voulu remarquer la chose.
L'expert sécurité ne prend pas de risque. Si le client lui commande un treuil qui doit supporter 10 tonnes dans un environnement définit, le treuil doit supporter 10 tonnes et pas 9 car l'expert sécurité on a voulu faire des économies. Le responsable sécurité n'a pas à prendre de risque. S'il le fait, c'est une faute grave.
Le client peut prendre des risques (NB: on ne recommande évidemment pas qu'il en prenne). C'est au client d'avoir conscience des risques et de définir le niveau de sécurité qu'il veut. Si le client veut accrocher des poids de 12 tonnes à son treuil alors qu'il a commandé un treuil de 10 tonnes, c'est lui qui prend les risques, c'est lui qui est responsable s'il y a une catastrophe.
> Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non. Et alors ?
L'évaluation des risques tu la fais tout le temps.
Si tu demandes un risque proche de 0 à un expert sécurité automobile, il va proposer de brider les voitures à 10 km/h maxi. Mais le client (l'état, les citoyens) accèpte de prendre le risque de rouler à 130 km/h, accèpte d'avoir 5000 morts par an. L'expert n'a pas à prendre de risque ni les définir (il peut évidemment les évaluer). Le client peut en prendre (je répète encore...).
Pour un mirroir public, le client va dire, pour faire court, qu'il s'en fout des risques, et l'expert va proposer le minimum.
Ce n'est pas à l'expert de définir le risque à prendre ! Sinon on tombe dans la stupidité où l'expert se donne du boulot.
Le mainteneur d'OpenSSL est un expert sécurité (ou devrait l'être).
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
> Ben alors tu as pris des risques.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
> Ou comment dire tout et son contraire dans le meme post...
Remettre en cause la FSF ?
Rappeler qu'on n'a le droit de na pas être d'accord avec la FSF ?
Diaboliser la FSF ?
Enfoncer des portes ouvertes ?
Contester l'"autorité" de la FSF dans le domaine du logiciel libre ?
Où discuter de ce que vient de faire la FSF et ses crititères pour être une distribution libre ?
Tu peux ne pas être d'accord avec la FSF qui ne veut pas de blob.
Mais les trucs fumeux type :
- "Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante[*], faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ..."
Bien du plaisir pour mettre ça dans un guide...
Et quel est le critière de ce "truc" ? Le libre ? La popularité ? Un "score" (sur quoi?) ? La ménagère de moins de 50 ans ? Les parts de marché ? Le potentiel pognon ? L'indispensabilité ? Nuire à MS ? Coller à la distribution la plus populaire ? Coller aux maximum de distributions ?
Je doute que le critière soit le libre...
> La liberté n'a pas été inventée par la FSF
Merci pour cette précision.
Je croyais que la FSF avais inventé la liberté.
[*] La FSF ne dicte pas la suppression de blob, elle dit seulement qu'elle ne qualifie pas de libre les distributions avec des blobs. Ne t'inquiète pas, il va rester encore plein de distribution avec des blobs, des drivers proprios, et qui d'auto-proclameront libre (la FSF ne l'interdit pas). Démonstration que la FSF ne dicte rien avec ce guide. Elle ne fait que donner son avis.
Je n'avais pas compris :-)
Si c'était "se dépêcher pour ne rien faire" j'aurais peut-être compris.
Les bons jeux de mots ne saute pas aux yeux. Celui-ci est excellent.
> Ah, bah alors le problème est peut-être que je ne comprend pas ce que tu entend par distribution "évoluée"
Très bonne remarque.
Ma notion d'évoluée n'est peut-être pas la tienne et je ne prétend pas que la mienne soit forcément plus pertinente qu'une autre.
> Est-ce que tu pourrais m'en dire plus ?
Si c'est pour partir sur un débat sur ce qui est évolué ou non, je préfère éviter. Ça va être une interminable "bagarre" et rien que de l'envisager ça me fatigue :-)
http://www.gnu.org/philosophy/free-system-distribution-guide(...) Guidelines for Free System Distributions Introduction
The purpose of these guidelines is to help people determine whether or not all the information for practical use in a system distribution (such as a GNU/Linux distribution) is free, and to help people create such distributions. "Information for practical use" includes software, documentation, fonts, and other data that has direct functional applications.
Ça ne t'interdit pas de faire de la pub à Flash.
Ça dit seulement que si tu fais de la pub pour du logiciel proprio (et d'autres bricoles), la FSF ne va pas dire que ta distribution est libre.
La FSF ne t'empêche pas de dire que ta distribution est libre. Mais, la FSF ne dira pas que ta distribution est libre.
T''es totalement libre de dire ce que tu veux avec ta distribution, de faire de la pub à du logiciel proprio, de faire de la pub pour MS, les DRM et MS-OOXML. Pas de problème. Mais si tu dis que ta distribution est libre selon la FSF, ben tu fais un mensonge. C'est tout.
Il y a aussi :
It does not include artistic works that have no immediate practical purpose, or statements of opinion or judgment.
Il suffit de lire le début du document de la FSF pour lever toutes tes intérogations.
Et c'est "marrant" de voir ta critique envers le document de la FSF (document qui n'interdit rien) alors que tu vas (voire veux) installer des programmes proprios qui vont t'interdire de publier des benchs, de faire du reverse engineering, de publier toutes failles dans le système DRM, etc.
Parce que c'est toi qui définit ce qui est libre ou non...
C'est la FSF qui est le mieux placé pour le faire.
Mais peut-être que tu te crois plus balaise que la FSF dans ce domaine.
Et si on suis ton raisonnement, à l'époque où on pouvait faire tourner un système 100 % GNU mais que sur un noyau proprio, on arrait dit que l'ensemble est libre...
Même pas besoin de faire Linux.
Formidable.
[^] # Re: MS-OOXML est mort(-né) ?
Posté par IsNotGood . En réponse au journal Tout ca pour ca. Évalué à 2.
> increases inefficiencies
increases efficiencies
C'est une erreur chez GrokLaw.
# MS-OOXML est mort(-né) ?
Posté par IsNotGood . En réponse au journal Tout ca pour ca. Évalué à 7.
MS à faire n'importe quoi pour obtenir la certification et a accouché d'un monstre qu'il lui est trop coûteux d'implémenter. Il est donc claire que quasi personne n'imprémentera complètement cette merde.
Notons que la "norme" (avec des gros guillemets) ISO MS-OOXML n'est toujours pas sortie ...
Il ne lui reste que quelques jours.
Les dégâts sur la crédibilité de l'ISO sont énormes. L'ISO a été trourné en ridicule.
Mais MS aussi. Les dégâts sur MS sont énormes aussi.
Ma supposition :
- MS-OOXML est mort. Du moins n'est plus un "standard" perenne.
Partant de cette suppostion (qui est peut-être fausse), on peut envisager que MS va bosser plus dure sur son nouveau format (qui n'aura pas les merdes des anciens formats). Es-ce que MS va tenter à nouveau de le ratifier ? Pas sûr. Peut-être que finalement, vu que MS a un quasi monopole, MS ferait mieux de ne rien normaliser. Ceux qui veulent du normalisé passeront par ODF (que supportera réellement MS-Office). Ceux qui veulent MS-Office "full-feature & eye-candy" avec SharePoint et autres lock-in de MS, ben seront totalement verrouillé par MS. M'enfin, ça fait depuis des années qu'ils l'accèptent...
Quoiqu'il en soit, c'est globalement une bonne nouvelle pour ODF.
Rob Weir fait d'excellentes analyses de la merde MS-OOXML.
Voici son dernier billet (sur les dates) :
http://www.robweir.com/blog/2008/05/fractured-yearfrac-and-d(...)
En passant, l'étude de New York sur ces besoins en stockage de documents bureautiques :
http://www.oft.state.ny.us/Policy/ESRA/erecords-study.htm
Contrairement à ce que dit GrokLaw, il y a maintenant les documents aussi sous odf.
L'entrée GrokLaw
http://www.groklaw.net/article.php?story=20080520200012132
J'ai bien ça :
9. Increased numbers of formats for doing the same office tasks do not increase choice in any positive manner. Use of multiple formats increases complexity and ongoing costs. The use of single, standarized formats increases inefficiencies and furthers compatibility and interoperability. Choice comes into play in two ways: (a) the choices made by vendors to directly support accepted standards; and (b) the ability of the State to choose among vendors who support accepted standards.
[^] # Re: je ne comprends pas
Posté par IsNotGood . En réponse au journal Tout ca pour ca. Évalué à 3.
Ben non. C'est un problème connu.
C'est du presque MS-OOXML.
[^] # Re: Autres méthodes plus "généralistes"
Posté par IsNotGood . En réponse au journal Firefox Portable pour Linux. Évalué à 2.
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Voir ici pour d'autres infos :
http://www.kerneldrivers.org/KernelDrivers.org
[^] # Re: Et les micro noyaux type HURD ?
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 1.
Ce n'est pas ce que j'ai voulu dire.
Ce qui m'énerve c'est qu'on donne trop d'importance au temps de boot.
J'en est rien à foutre que mon PC boote en 10 ou 30 ou 120 secondes.
[^] # Re: Pfuuu
Posté par IsNotGood . En réponse au journal Ubun^H^H^H^HIndiana Jones 4, sa pu. Évalué à 2.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamS(...)
All patches in Fedora spec files SHOULD have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example:
# http://bugzilla.gnome.org/show_bug.cgi?id=12345Patch0: gnome-panel-fix-frobnicator.patch
Ça vient d'être approuvé par le FESCo.
Notons que Fedora a toujours insisté pour bosser en upstream :
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
Il y a une réflexion pour mettre certains paquets critiques dans une catégorie spéciale.
Pour Debian ?
Ben j'imagine que ça doit encore parlementer.
[^] # Re: Une position claire
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 3.
Fedora-devel est une mailing ouverte. Donc forcément.
> et qui font chier tout le monde en disant que leur travail ne sert à rien
On le voit assez peu dans ce thread.
Alexandre Oliva (qui a fait et proposé kernel-libre, et qui est aussi à l'origine du thread) était un peu têtu ou c'est trop braqué.
En effet, beaucoup ne voit pas l'intérêt de virer les firmware. Par contre, il y a eu plus d'ouverture que tu ne le crois.
Alexandre Oliva veut garder son "fork". Ce qui lui est proposé comme direction, et à plusieurs reprise, est de bosser avec les mainteneurs noyaux, en upstream Linux, afin de trouver une vraie solution.
Même les développeurs qui n'ont rien à foutre des firmwares, accèptent cette démarche. Mais Alexandre Oliva ne veut rien entendre et c'est bien dommage.
L'un des gros problèmes est qu'il faut patcher le paquet upstream.
On pourrait imaginer, et ce directement upstream (sur http://www.kernel.org/), un paquet linux-2.6.28.tar.gz avec à côté et optionnellement linux-firmware-nonfree-2.6.28.tar.gz.
Il faudrait développer un mécanisme pour avoir les firmwares dans le noyau (c'est pour l'embarqué et réalisé à la compilation) ou hors du noyau (typiquement dans /lib/firmware). Le noyau Fedora étant construit que depuis linux-2.6.28.tar.gz. Après libre à chaqu'un de packager linux-firmware-nonfree si ça le chante. Comme d'autres sont libre de packager le driver proprio NVidia.
Cette démarche (dans les très très grandes lignes) est proposée à
Alexandre Oliva mais il fait la sourde oreille. Démarche aussi proposée par des gens qui n'ont rien à foutre des firmwares.
Espérons qu'Alexandre Oliva soit plus ouvert et qu'un consensus s'installe.
[^] # Re: Un nouveau pas !
Posté par IsNotGood . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à 1.
[^] # Re: Un nouveau pas !
Posté par IsNotGood . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à 0.
Développé en C++ et utilisant Qt et KDE.
> parler d'une application développée avec C ou avec C++ ne voudrait pas dire grand chose ...
Ça veut dire qu'elle est développée en C ou C++. Pas en java ou C# ou python ou perl, etc.
Ça dit quelque chose. Ça dit aussi que ça utilise un language rapide à l'exécution. Il y a des noyaux développés en C, d'autres en C++, en Java, en C#. Ça fait une différence énorme (en empreinte mémoire et en vitesse).
Il y a des développeurs C qui connaissancent gtk+, mais ne savent pas développer en python des interfaces gtk+ (pourtant le binding python existe, il est excellent et très utilisé).
Peut-être que tu peux développer dans n'importe quel language car tu les connais tous, et tu te fous des performance. Mais tout le monde n'est pas comme toi.
> C'est parce que la langue est malléable qu'on a eu de grands auteurs qui ont sû en jouer.
Si tu prends pour Molière...
[^] # Re: Un nouveau pas !
Posté par IsNotGood . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à -2.
Si tu ne connais pas Qt et KDE, "développé en Qt" indique que c'est développé en language Qt.
Je ne connais pas précisément les bindings de Qt, mais il me semble que tu n'es pas obligé de coder en C++ pour utiliser Qt.
Pour venir à un terrain que je connais mieux, dire "développé en gtk+" ne dit pas si c'est codé en C ou C++ ou perl ou python ou java ou vala ou php. Au mieux tu déduit seulement que ça utilise gtk+.
Lemon utilise aussi MySQL. Ça te conviendrait "développé en MySQL" ?
Un site web qui utilise apache/php/Mysql, ça te convient si on dit "développé en apache" ?
Comment tu fais pour les applis qui utilisent plusieurs toolkit (en fonction de la plateforme) ? Tu dis "développé en gtk+ et koala et win32" ?
Être imprécis c'est cool et être rigoureux c'est ringard.
Je suis un ringard.
[^] # Re: Sémaphore et mutex
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 3.
???
M'enfin, je crois que je te suis.
J'ai bien compris qu'il y a un truc que ne comprend pas :-)
Il doit me manquer un élément pour que j'ai une vue d'ensemble cohérente.
Enre le semaphore qui est utilisés comme des mutex mais qu'il est super compliqué de remplacé par un mutex sans pertes de perfo car le semaphore est super optimisé mutex, ce n'est pas simple.
J'espérais qu'un commentaire ferait la lumière dans ce "bordel" (pour moi).
Mais j'aurai dû faire plus d'effort pour comprendre et ne pas espérer que l'explication tomberait toute cuite.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Tu dis que je suis de mauvaise fois...
T'es culotté.
Toi tu dis que pour le "merdier" fait par Debian tu peux tout automatiser.
Foutaise !
http://www.debian.org/security/key-rollover/
http://wiki.debian.org/SSLkeys
Juste un petit passage :
OpenSSH (both server and user keys)
Tu vas regénérer automatiquement les clés des utilisateurs ?
T'es balaise toi. A oui, j'oubliais que tu as fait plein de truc ronflant et blink blink EAL7 optique tunnel et toussa.
Si on te confie la réalisation de la machine infernale, tu nous la garantiras sûr à 100 % ...
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
J'ai bien essayé de faire passer qu'il y a le responsable sécurité (ou l'expert sécurité) et le client. Tu n'as pas voulu remarquer la chose.
L'expert sécurité ne prend pas de risque. Si le client lui commande un treuil qui doit supporter 10 tonnes dans un environnement définit, le treuil doit supporter 10 tonnes et pas 9 car l'expert sécurité on a voulu faire des économies. Le responsable sécurité n'a pas à prendre de risque. S'il le fait, c'est une faute grave.
Le client peut prendre des risques (NB: on ne recommande évidemment pas qu'il en prenne). C'est au client d'avoir conscience des risques et de définir le niveau de sécurité qu'il veut. Si le client veut accrocher des poids de 12 tonnes à son treuil alors qu'il a commandé un treuil de 10 tonnes, c'est lui qui prend les risques, c'est lui qui est responsable s'il y a une catastrophe.
> Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non. Et alors ?
L'évaluation des risques tu la fais tout le temps.
Si tu demandes un risque proche de 0 à un expert sécurité automobile, il va proposer de brider les voitures à 10 km/h maxi. Mais le client (l'état, les citoyens) accèpte de prendre le risque de rouler à 130 km/h, accèpte d'avoir 5000 morts par an. L'expert n'a pas à prendre de risque ni les définir (il peut évidemment les évaluer). Le client peut en prendre (je répète encore...).
Pour un mirroir public, le client va dire, pour faire court, qu'il s'en fout des risques, et l'expert va proposer le minimum.
Ce n'est pas à l'expert de définir le risque à prendre ! Sinon on tombe dans la stupidité où l'expert se donne du boulot.
Le mainteneur d'OpenSSL est un expert sécurité (ou devrait l'être).
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
> Ben alors tu as pris des risques.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
> Ou comment dire tout et son contraire dans le meme post...
Et toi l'art de faire l'autruche.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Rappeler qu'on a le droit de ne pas être d'accord avec la FSF ?
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 3.
Remettre en cause la FSF ?
Rappeler qu'on n'a le droit de na pas être d'accord avec la FSF ?
Diaboliser la FSF ?
Enfoncer des portes ouvertes ?
Contester l'"autorité" de la FSF dans le domaine du logiciel libre ?
Où discuter de ce que vient de faire la FSF et ses crititères pour être une distribution libre ?
Tu peux ne pas être d'accord avec la FSF qui ne veut pas de blob.
Mais les trucs fumeux type :
- "Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante[*], faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ..."
Bien du plaisir pour mettre ça dans un guide...
Et quel est le critière de ce "truc" ? Le libre ? La popularité ? Un "score" (sur quoi?) ? La ménagère de moins de 50 ans ? Les parts de marché ? Le potentiel pognon ? L'indispensabilité ? Nuire à MS ? Coller à la distribution la plus populaire ? Coller aux maximum de distributions ?
Je doute que le critière soit le libre...
> La liberté n'a pas été inventée par la FSF
Merci pour cette précision.
Je croyais que la FSF avais inventé la liberté.
[*] La FSF ne dicte pas la suppression de blob, elle dit seulement qu'elle ne qualifie pas de libre les distributions avec des blobs. Ne t'inquiète pas, il va rester encore plein de distribution avec des blobs, des drivers proprios, et qui d'auto-proclameront libre (la FSF ne l'interdit pas). Démonstration que la FSF ne dicte rien avec ce guide. Elle ne fait que donner son avis.
[^] # Re: Et les micro noyaux type HURD ?
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 1.
Le boot le plus rapide jusqu'à l'ihm pour moi ?
Simple : Windows 3.1.
Diablement rapide (outils norton compris).
Mais il ne me manque pas.
[^] # Re: Pas à l'utilisateur de deviner
Posté par IsNotGood . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 2.
Je n'avais pas compris :-)
Si c'était "se dépêcher pour ne rien faire" j'aurais peut-être compris.
Les bons jeux de mots ne saute pas aux yeux. Celui-ci est excellent.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
[^] # Re: Rolling Release Distros
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 1.
Très bonne remarque.
Ma notion d'évoluée n'est peut-être pas la tienne et je ne prétend pas que la mienne soit forcément plus pertinente qu'une autre.
> Est-ce que tu pourrais m'en dire plus ?
Si c'est pour partir sur un débat sur ce qui est évolué ou non, je préfère éviter. Ça va être une interminable "bagarre" et rien que de l'envisager ça me fatigue :-)
[^] # Re: Liberté d'expression ?
Posté par IsNotGood . En réponse au journal FSF et liberté d'expression. Évalué à 2.
# Liberté d'expression ?
Posté par IsNotGood . En réponse au journal FSF et liberté d'expression. Évalué à 7.
Guidelines for Free System Distributions
Introduction
The purpose of these guidelines is to help people determine whether or not all the information for practical use in a system distribution (such as a GNU/Linux distribution) is free, and to help people create such distributions. "Information for practical use" includes software, documentation, fonts, and other data that has direct functional applications.
Ça ne t'interdit pas de faire de la pub à Flash.
Ça dit seulement que si tu fais de la pub pour du logiciel proprio (et d'autres bricoles), la FSF ne va pas dire que ta distribution est libre.
La FSF ne t'empêche pas de dire que ta distribution est libre. Mais, la FSF ne dira pas que ta distribution est libre.
T''es totalement libre de dire ce que tu veux avec ta distribution, de faire de la pub à du logiciel proprio, de faire de la pub pour MS, les DRM et MS-OOXML. Pas de problème. Mais si tu dis que ta distribution est libre selon la FSF, ben tu fais un mensonge. C'est tout.
Il y a aussi :
It does not include artistic works that have no immediate practical purpose, or statements of opinion or judgment.
Il suffit de lire le début du document de la FSF pour lever toutes tes intérogations.
Et c'est "marrant" de voir ta critique envers le document de la FSF (document qui n'interdit rien) alors que tu vas (voire veux) installer des programmes proprios qui vont t'interdire de publier des benchs, de faire du reverse engineering, de publier toutes failles dans le système DRM, etc.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 1.
C'est la FSF qui est le mieux placé pour le faire.
Mais peut-être que tu te crois plus balaise que la FSF dans ce domaine.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Même pas besoin de faire Linux.
Formidable.