Raphaël SurcouF a écrit 2609 commentaires

Urgl ! Du java...
Adieu monde cruel... ;-)

Après avoir importer un fichier au format OFX fourni par ma banque,
j'étais heureux de voir que Grisbi s'en tirait fort bien, me soulageant d'une longue saisie.
Par contre, j'ai l'impression qu'il m'a sucré les centimes sur toutes les opérations saisies avant la 0.5.0 et l'une d'entre-elles (je n'ai pas encore tout vérifié) s'est même vue incrémentée d'un euro !...

Tu pourrais faire un vrai rapport d'anomalie sur le bts.
Ce serait mieux...

La date de la nouvelle sur le site de grisbi.org a presqu'un mois par rapport à cette dépêche.
Est-ce normal, d'autant plus que l'auteur est l'un des développeurs ?

Et pas moyen d'avoir les API pour Linux sans devoir payer comme une entreprise ?
Va-t-il falloir monter une association à but non lucratif pour y parvenir ?

En même temps, j'en ai marre de recevoir des spams me proposant du viagra ;-)
Du spam un peu mieux ciblé, je serais moins contre, quoi... (entre deux maux).

Tant qu'à faire, autant tester la rc1 qui a été annoncée il y a quelques jours: http://lists.debian.org/debian-devel-french/2004/05/msg00041.html(...)

En tout cas, le connecteur permet au moins d'utiliser OpenGroupware.org de façon entièrement libre à défaut d'attendre le natif que développe en ce moment l'équipe de Skyrix.

C'est aussi la diffusion officielle d'un logiciel particulier, par exemple linux.
On parle alors également de distribution de linux pour les tarball disponibles sur kernel.org.
Dans le contexte qui nous concerne, il s'agit d'un système au-dessus d'un ensemble de distributions debian afin des les gérer conjointement de façon centralisée (c'est comme ça que je le comprend).

Vu que c'est GPL à présent, pourquoi pas reprendre le boulot...

Bon, je sais, on peut toujours rêver, hein ;-)

Je dirais que Kontact est encore loin d'Evolution: il ne faudrait pas inverser les rôles. Même si c'était propriétaire et payant, Evolution pouvait déjà le faire.

Au contraire, ce sont les anglais qui les ont perdus ;-)

J'en connais un basé sur Dia et Postgres mais il est encore assez orienté PHP car il génère des classes PHP directement accessibles de façon transparente en fonction de ta base de données. En clair, tu n'écris que très rarement de requêtes SQL dans ton code.

Dia2Postgres: http://www.nocternity.net/index.php/projets/dia2postgres(...)

Au hasard, A'rpi de MPlayer (enfin, ex de) ? ;-)

Déjà, je n'ai jamais parlé de faire de rétro-portage des paquets testing vers la stable. Ensuite, en bon admin consciencieux, tu peux toujours récupérer les patchs qui corrigent le trou de sécurité et l'appliquer à ta version d'openldap snas risquer la corruption (à moins que ce soit le patch même qui en soit la cause).
Evidemment, cela requière quelques connaissances de la construction d'un paquet debian et plus exactement, la façon d'appliquer un patch: mais il y a toujours moyen de le faire à sa façon.

1/ C'est la solution que je préconise dans la mesure où, contrairement à ce que j'ai pu lire parmi les commentaires, le suivi de sécurité bien qu'officielement absent est facilement remplacé par les priorités accordées à de telles mises à jour pour les paquets entrant dans l'unstable. En effet, la durée d'incubation varie en fonction de ce paramètre: 10, 5 ou 2 jours.

2/ Si les paquets rétro-portés proposés sont souvent assez populaires, je ne conseille pas cette méthode: aucune assurance quant au suivi de sécurité/qualité. Ca dépanne à l'occasion, c'est certain mais en production, ce n'est pas toujours rassurant.

3/ Encore pire que le précédent: vu l'écart, tu as peu de chances que ça fonctionne à cause des dépendances et, en outre, tu devras jongler avec apt pour mettre à jour ce dont tu as besoin et tu finirais par avoir une testing/unstable plus qu'une stable: la libc6 sera une des dépendances cruciales rapidement installées.

Dans tous les cas, je conseille d'avoir ce trio:
- plateforme de production,
- plateforme de test et
- plateforme de développement.
Le matériel utilisé ne doit pas être le même mais il vaut mieux avoir pour les deux premières, de l'identique. J'oubliais de penser aussi à une plateforme en backup: mais ceci est normalement compris dans la plateforme de prod.: on double tout.
Ce concept doit bien évidemment rappeler celui déjà utilisé par debian.

Je suis d'accord avec toi sur la problématique posée par le statut actuel de l'unstable mais j'apporterais un bémol: si Gnome 2.6 a été "uploadé" dans experimental, ce n'est nullement pour ajouter un énième distribution à panel debian.
En effet, c'est la situation critique de testing qui a amené les membres de l'équipe Gnome de Debian a préféré cette voie plutôt que d'y inclure directement dans l'unstable afin de moins perturber la sortie imminente de la Sarge.
En outre, ils ont également souhaité évité l'écueil qu'a connu Gnome 2.4.
Et j'ajouterais que Debian a toujours connu des versions concurrentes de paquets, c'est même explicitement permis par la Debian Policy.

Et comme dit 100 fois, la sécurité dans tout ça ?

Comme dit "100 fois" aussi, il n'est guère difficile de prendre un paquet à jour provenant de l'unstable et la priorité est telle que le délai est réduit à 2 jours au lieu des 10 habituels.

Au fait, qui es-tu, toi qui m'a l'air d'avoir enfin un discours censé en ce bas-monde ?
Apparement, ton login n'a été crée que depuis cette dépêche.
Alors, je me demande ;-)

On est bien d'accord.

Et tu préconises quoi à la place ? Utiliser des paquets rétro-portés peut-être ?
Où est l'assurance de correctifs de sécurité dans ce cas ? C'est encore pire.
Alors, je dois me contenter de postfix 1.x, de cyrus 1.x, de samba 2.2.x, d'openldap 2.0.x ou Linux 2.4.18 selon toi ? J'aimerais bien mais parfois, on ne peut pas et tous ces logiciels nécessitent autant d'attentions quant à la sécurité.
Les correctifs arrivent aussi bien pour la stable que l'unstable même s'il y a une équipé spécialement pour la première. Il n'est pas difficile d'importer sans attendre ces paquets de l'unstable si le besoin s'en fait sentir. En outre, selon l'urgence, le délai de quarantaine est plus ou moins long mais je l'ai déjà dit à de nombreuses reprises dans d'autres commentaires.
Ensuite, si j'installe des unstable en "serveur" (dieu que ce terme m'énerve: hors contexte, ça ne veut rien dire, passons...), non seulement je l'assume mais je le limite à mon usage exclusif personnel.
C'est assez amusant et paradoxal de voir comment les idées évoluent: il y a un an, je me serais dit exactement la même chose. Mais là, ça fait deux ans qu'on attend... Trois ans, ce serait un peu trop tard.

Quel est ce préjugé envers debian comme quoi elle ne ferait pas un excellent poste de travail ? Elle serait exclusivement réservé pour faire des "serveurs" ?
Je ne suis pas d'accord avec ce point de vue.
Et devoir passer par testing/unstable n'est pas complètement normal.
Peut-être faudra-t-il que le projet se scinde en deux avec un sous-projet dédié au desktop ?

Parce ce que tout ce que tu décris n'est qu'une situation qui n'a que trop duré.
Installer une debian stable sur du matériel récent devient de moins en moins évident: ce n'est pas simplement une course à la nouveauté. Et ne viens pas me parler du nouvel installateur pour la sarge: il est récent et on attend justement après lui (entre autres) pour que la sortie de la Sarge soit effective. La testing n'a pas pour but de s'éterniser à ce point-là et devenir une solution à moyen/long terme. Apparement, tu ne dois pas être venu chez debian depuis longtemps, tu n'as pas l'air d'avoir connu l'époque précédant la woody.
La stable doit être la base avec laquelle on compose. Utiliser des paquets rétro-porté, etc, te prive finalement des avantages que tu avais auparavant avec debian: on commence par un paquet et finalement, tu termines par avoir la plupart des logiciels qui te sont importants ainsi: autant utiliser une LFS et faire ses propres mises à jour soi-même, avec le suivi que ça importe.
Ce n'est pas de l'impatience que d'avoir attendu deux ans pour qu'elle sorte, c'est de la frustration de voir qu'elle risque encore de voir sa sortie reportée pour une raison qui pourrait attendre un peu. Et deux ans, dans le monde des logiciels informatiques: c'est assez long, surtout dans celui des Logiciels Libres.
Un an serait acceptable, 6 mois peut-être trop demandé.

Par ailleurs, la distribution Debian orientée entreprise sera probablement UserLinux et je la suis avec attention. En parrallèle, avec d'autres "Debian-addict", nous développons une Debian Custom la plus proche de UserLinux/Woody-Sarge que nous déployons en entreprise. La 40-aine de clients n'a pas l'air de s'en plaindre...

C'est justement ce que je constate: avec cette nouvelle polémique, les projets basés sur debian vont reprendre de plus belle. Pourquoi pas.

Tu crois que je ne suis pas au courant qu'il s'agit de bénévoles ?
De même que pour certains projets pourtant importants du Libre.
Il est toutefois vrai que certains sont employés par une société pour ne se consacrer qu'à ce logiciel libre en question (Linux, Gnome, Mozilla, OO.o, etc...)

Maintenant, je parle en tant qu'administrateur d'une société quelconque parce que c'est mon métier: il n'est pas question de productivisme à l'état pur mais de fonctionnement simple.
On ne demande pas à avoir tout et tout de suite, on est les premiers à être conscient des délais que ça peut imposer. Maintenant, les développeurs debian sont 900, s'il n'y a personne pour faire le boulot à la place d'un autre, c'est qu'il y a un problème et il n'est pas rare qu'un développeur fasse pression pour que les mises à jour d'un logiciel soient reléguées aux calenques grecques parce que la méthode proposée pour le corriger ne lui plaît pas. C'est donc aussi un problème humain. Personne ne les a forcé à prendre en charge ces paquets et ils le font de leur plein gré. Maintenant, Debian a une structure relativement associative et, pour être moi-même membre d'une association, quand on accepte de prendre des responsabilité au sein d'un groupe, il faut savoir les assumer. Si tu penses que tu ne vas pas y arriver, que tu auras des problèmes, c'est simple: tu demandes de l'aide, c'est tout. Même en entreprise, ça se fait: ce n'est pas que de l'exigeance, c'est de la rigueur et de la responsabilité. Sinon, faut pas proposer son aide.

Maintenant, je ne t'ai pas attendu pour utiliser testing/unstable, je ne fais que relater les demandes d'utilisateurs que je vois passer ci-et-là et qui ont besoin de telles ou telles versions d'un logiciel (samba, linux, etc.) parce que sinon, ça ne marche pas. Et ceux-là, je me répète encore, n'ont que trois alternatives:
- passer à testing/unstable,
- utiliser des paquets rétro-portés,
- changer de distribution.
Tous ces choix, je les connais et je les assumes à chaque fois. Je suis un fervent supporter de Debian, je suis le premier à conseiller d'utiliser testing/unstable quand stable ne convient plus mais à condition de rapporter les anomalies quand il y a en a et utiliser le BTS (et je suis le premier à le faire).

Maintenant, à toi de me dire ce que tu as comme distribution parce qu'avec de telles accusations, je suis curieux de savoir ce que tu as.

Avec RHN ou Windows Update, c'est pareil sauf qu'au lieu de taper une commande, tu cliques...
Donc, c'est autant automatisé.