IsNotGood a écrit 5009 commentaires

XPS sera la prochaine masquarade :
http://www.ecma-international.org/memento/TC46-M.htm

> ce n'est pas nécesssaire.

Par définition, ce qui n'est pas nécessaire n'est pas requis. Donc ne mélangeons pas les Requires et les Suggests.

> Il y a même une chasse quasi permanente aux suggest superflux.

Suggest qui est un choix "politique".

> Même chose avec les suggest, si on les installe ça marche mieux,

C'est ça. Firefox marche mieux avec Flash....
N'importe quoi.

C'est un patch spécifique Mandriva.
Comme je l'ai dit ailleurs, les champs SUGGESTSNAME, etc on été ajouté au format rpm (donc c'est upstream).

> Si c'est pour de la bureautique, pourquoi ils ont pas mis Ubuntu?

On l'a appris il y a quelques mois : Linux = Ubuntu.
Maintenant OOo = Ubuntu. C'est nouveau.

Ça montre que le FUD de MS pour OOXML on va se le bouffer pour longtemps.

Notons qu'au début MS disait qu'il fallait plusieurs formats (et donc pas un seul format pour tout le monde). MS voulais nous faire croire qu'il n'était pas dans la défense d'un monopole. Mais maintenant c'est encore, et comme d'habitude, la défense d'un monopole de MS.

Autre chose, le groupe SC34 (majoritairement composé d'employé MS) va "bosser" sur la fusion d'OOXML et ODF. Un groupe dédié à OOXML (créé pour tuer ODF) va bosser pour la fusion des deux formats. Si c'était faux, ça pourrait être rigolo. Cette fusion est en fait la mort de ODF.
Et quelle fusion ?
On l'imagine déjà. Tout ce qui va être ODF pourra être mappé dans OOXML, rendant (sur le papier) ODF "inutile".
On est passé de :
1- un format ouvert (ODF)
2- un format ouvert (ODF) et un format fermé (OOXML)
3- un format fermé (OOXML qui aura un autre nom)

Ben oui, on a ce que les l'hypothèse les plus folles envisageaient. ODF va avoir du mal a abtenir ses futures certifications ISO. ODF v1.2 aura probablement la cerfication ISO, la stratégie de "fusion" n'ayant pas encore porté ses fruits. Pour ODF v2 on aura des non (sponsorisé par MS) prétextant que ODF v2 nuit aux efforts de fusion de SC34 (qui est à la botte de MS). Fusion demandée par les anti-OOXML d'hier. Belle ironie.

L'"idée" de l'AFNOR est finalement bien mauvaise.

> Tu me confortes, par ton argumentation, dans l'idée d'avoir des caméras.

On pourrait en mettre une dans ton bureau.

> Le problème de fond de l'insécurité ne peut relever de la compétence d'un établissement d'enseignement

+1000
Absolument.

Mais pour Samuel Bizien, que faire ?
Ceci doit être une décision de politique nationnale.

> On a de très jolis principes - et c'est important d'en avoir - mais il faut parfois savoir les mettre de côtés.

Pas les mettre de côtés.
Il faut parfois faire des compromis entre principes. Par exemple le principe d'assurer la sécurité (qui permet la liberté) et le principe de respect de la vie privée. On ne met manifestement pas ses principes de côté ici.
L'idéal est d'avoir ses deux principes au mieu sans qu"ils s'empiètent. Avoir le respect de la vie privée mais ne pas avoir la liberté de pouvoir aller à l'école est pour le moins embêtant.

C'est très bien d'avoir des principes et des convictions.

Les caméras ne sont qu'un moyen. On pourrait les remplacer par des flics ou des observateurs.
Donc ne diabolisons d'outils. C'est l'usage qu'il faut contrôler.

Donc quel usage ?
Spécifiquement de sécurité, alors seul ceux qui sont concernés par la sécurité doivent avoir accès au contenu. Les profs ou les parents ne doivent pas y avoir accès. Ceux qui s'occupent de la sécurité ne doivent pas faire de rapport aux profs ou aux parents. Mais un rapport au responsable du lycé peut être pertinent. A titre exceptionnel il pourra contacter les profs ou parents concernés.

Es-ce un flicage ?
Si non alors il ne doit pas y avoir d'archive (ou seulement le nécessaire).

Je ne suis pas un spécialité de sécurité ni des écoles.
Mais ne diabolisons et gardons la tête froide. Analysons bien les objectifs et ne donnons que les moyens pour tenir ses objectifs. Ainsi les choses sont claires et tout le monde peut l'accèpter.

Bref, les objectifs, les objectifs, les objectifs. S'ils sont accèptables, adapter les moyens aux objectifs sera alors facile.

> Finalement je crois que je comprend pourquoi il y a un fork de rpm...

Je viens de regarder, les suggest ont été ajoutés au format rpm.
Mais rpm (de rpm.org) n'en fait rien.

Admettons. En passant, je crois que tu mélanges avec un autre problème.

Mais vois comme cette "mauvaise" idée a rapidement des répercutions.
Es-ce que rpm doit encourager ce type de truc ?
Je ne crois pas.
Ceci dit, je pense avoir bien compris ton avis et que tu as bien compris le mien.
Donc j'arrête.

> D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute)

Bien vu.
Mais c'était une connerie de ma part.
Rpm a des objectifs (que) technique. Ce n'est pas le cas de Gnome.

> une forme de dépendance, optionnel mais dépendance

Une dépendance optionnelle n'est pas une dépendance.
Quand penses-tu ?

> Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.

Je ne peux pas parler pour Mandriva, mais pour Fedora ce n'est pas fait comme ça.
J'ai Gnome comme bureau, je peux (et d'ailleurs je le fais) virer Nautilus. Le bureau Gnome ne dépend pas de Nautilus (mais Nautilus dépend de Gnome).
Et je "maudirais" rpm si un jour il me suggère d'installer Nautilus.

PS: ce n'est pas une critique de Nautilus, je n'utilise pas les gestionnaires de fichier graphique.

> Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...

Je répète pour au moins la quatrième fois, je ne suis pas contre le concèpte de suggérer un autre paquet, mais je suis contre de le faire dans rpm.

A une époque Fedora "suggérait" epiphany comme navigateur. Puis ça été Firefox. Ben Fedora n'a pas besoin de recompiler les paquets pour ça. Comme ce n'est pas dans rpm, Fedora n'a pas un compiler des paquets pour Fedora saveur Gnome et Fedora saveur KDE et Fedora saveur developers, etc.

Je répète encore, je ne suis pas contre le concèpte de suggérer un autre paquet. Fedora, les faits le montre, n'y est pas contre non plus. Mais ça ne doit pas être fait dans rpm.

> donc c'est un faux probleme

Ce n'est pas un faux problème.
Pour Fedora il y a :
- Fedora (full, avec evolution par défaut, etc)
- Fedora KDE (avec kmail par défaut, etc)
- Fedora Games
- Fedora Developers
- Fedora Electronic Lab
- Fedora XFCE

Il y a en peut-être d'autres. Toutes ses distributions utilisent les mêmes paquets rpm. On n'a pas à recompiler 6 (!) fois le même paquets. Gain de temps et d'espace disque (ose imaginer le cas de OOo).

> donc c'est un faux probleme

La place disque (sur les mirroirs) commence a être un sérieux problème.

J'ajoute pour être clair, je ne suis pas contre le principe de suggérer ou des meta-paquets. Mais ça ne doit pas (à mon avis) être fait au niveau de rpm.

On peut voir que yum c'est étoffé avec des informations qui n'ont pas leur place dans rpm. Par exemple des informations qui indiquent si le paquet est un correctif de sécurité (pertinant pour une mise à jour, mais sans intérêt pour une nouvelle release). Cette informations est par rapport à l'ancien paquet et donc implique un "workflow" dont rpm est totalement étrangé. Donc cette information, aussi utile soit-elle, n'a pas à être dans rpm.

Ce n'est pas car une information est utile, qu'il faut la foutre n'importe où.

Ben cette pratique des meta-paquets n'est pas bonne à mon avis.
Je dis ça, c'est une news Mandriva, je vais me faire exploser et accuser d'insulter les développeurs, de chier sur ... etc...
Bref, je n'irais pas plus loins sauf pour dire qu'il y a des alternatives à ces meta-paquets.

> Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm

C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.
Après tu peux ajouter les résolutions automatiques (et optionnels) des dépendances, le choix du mirroir à utiliser (optionnel), l'interface graphique (optionnelle), etc.
Ce principe moux va à la catastrophe ou du moins est la voix royale au n'importe quoi.
Après le suggest, il y aura le suggested-doc (ça ne fait pas de mal, c'est optionnel), le suggested-skin (ça ne fait pas de mal, c'est optionnel), le suggested-ram (ça ne fait pas de mal, c'est optionnel), etc.

Ceci sucks dans les grandes largeurs.

Tu aimes ça, je n'aime pas ça, on ne sera pas d'accord.

> Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm

Ben il n'y est pas.
Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).

> des références à propos de ce mensonge honteux ?

Je n'ai pas dit que c'était un mensonge (honteux).
Si tu veux la même chose avec yum, il y a le greffon yum-skip-broken.
C'est un choix qu'a fait apt, yum ne l'a pas fait (du moins par défaut).

> Faut il egalement retirer les requires de rpm ?

Vous êtes con ou quoi ?
Un require c'est ce qui est nécessaire pour que ça marche. Ce n'est pas optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, c'est nécesssaire.

Il y a peut-être des distributions qui ne respectent pas la signification de require, mais c'est leurs oignons. En tout cas Fedora respecte la signification de require. Si un require n'est pas nécessaire pour le bon fonctionnement du logiciel, ben fait un rapport de bug. Tu vas voir, le require sera supprimé.
Il y a même une chasse quasi permanente aux requires superflux.

Autant pour moi.
Et pour synaptique ?
Es-ce que par exemple on peut avoir la liste des suggestions actuelles qui ne sont pas installées ?

> Les Suggests ne sont pas plus des décisions politiques que les Requires ...

Foutaise.
S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.

> urpmi l'utilise.

Mais ce sont des infos qui viennent de rpm ou d'ailleurs ?

> Elle est où la compatibilité inter distribution ?

Elle n'existe pas, c'est quasi intentionnel.
Ainsi tu peux avoir une distribution avec le bureau par Gnome défaut, une autre avec KDE, une autre avec evolution par défaut, une autre avec thunderbird, une autre qui installe tout Gnome et une autre qui installe que le minimum pour Gnome, etc.
comps.xml est spécifique à la distribution.
Par contre rpm ne l'est pas.
Les suggestions sont spécifiques à une distribution (à sa politique/philosophie), donc ils ne devraient pas être au niveau de rpm. Rpm s'occupe que de questions techniques.

OK.
Au chargement du module nv, il pourrait y avoir un message dans /var/log/message qui suggère le driver proprio.
Je suis contre ce principe.

Après du pourrait avoir Firefox qui suggère Gnome s'il ne trouve pas Gnome, etc.
C'est la (mauvaise) idée globale qu'il faut voir ici. Pas le côté technique.

> ce qui explique peut être que Stallman aime bien allumer

Pooouuufff.............
RMS n'a rien allumé du tout. On lui a posé une question et il y a répondu. Après OpenBSD en a chié une pendule.

Diable, es-ce RMS ne pourrait pas avoir une avis ?

Les pseudo provocations de RMS il faut les chercher pour les trouver.

Voici le site de RMS :
http://www.stallman.org/

Rien sur BSD ou *BSD.

Je pense qu'il y avait aussi du fond.
Fedora clamait pouvoir lire des vidéos flash. Linus, et il a raison, les a pris au mot.

Je suis archi sûr qu'il y a 1 an Linus aurait simplement installé le flash d'Adobe. Mais comme F9 prétend lire les vidéos flash, il a sauté sur l'occasion. Et il a très bien fait.