J'ai une question "concon". Il me semble que tu "travails" ou évolues dans le monde Mandrake.
Tu es "discret" ou tu n'as pas d'infos ou c'est encore au stade de gestation et tout doits rester plus ou moins confidenciel tant qu'il n'y a rien de consistant pour éviter les confusions inutiles ?
Par exemple :
> Je ne me rappelle plus des premières echéances mais il n'y aura rien avant quelques mois.
CS sort tous les 18/24 mois. Donc la prochaine c'est au mieux dans 18 mois.
> De toute manière, le LCC ne représentera que la base du système, les rpm de la majorité des applis de la prochaine corpo seront sans doute ceux de la 11.0.
* Conectiva Enterprise Server (deuxième trimestre 2005)
* Mandrakesoft Corporate Server (deuxième trimestre 2005) <===
* Progeny Componentized Linux (premier trimestre 2005)
* Turbolinux Enterprise Server 10 (premier trimestre 2005)
Deux distributions serveurs en 6 mois ça fait beaucoup pour une distribution qui sort tous les 18/24 mois.
Tu m'expliques ? Ou tu ne veux pas ou ne peux pas ou ne sais pas ?
Pour être "claire", je donne te un exemple : RHEL 3 est basée sur RH9.
Si tu me demande les sources de RHEL 3 et que je te pointe RH9, c'est tu même tonneau que quand tu me pointes Mdk 10.0 pour CS 3.0 ?
Si c'est le cas, ce n'est pas ce que j'attendais. RHEL 3 est un fork de RH9 et pas RH9 + update. Par exemple RHEL 3 a ACL et pas RH9, RHEL 3 a été porté sur PowerPC et pas RH9, etc...
Donc, pour te résumer, et ce que comprend de ton post "succint", CS 3.0 est une Mandrake 10.0 + update et c'est tout. Si j'ai une Mandrake 10.0 à jour, j'ai une CS 3.0 ?
> Pour te donner un exemple, quand tu posent la question "Où sont les sources?" Pour toi il n'y a pas d'ambiguité, car tu sais ce que tu veux dire, mais pour moi il en a une. Tu parles des paquets sources (les *.src.rpm) ou des sources des logiciels que MandrekeSoft développe?
Désolé pour l'imprécision. Je parle uniquement des *.src.rpm de CS 3.0. Je ne parle pas de développement interne ou pour un client particulier de MandrakeSoft.
Ce qui me surprend dans la sortie de CS 3.0, c'est que j'attendais à une distribution basée sur Linux Core Consortium.
Tu peux en dire plus ? CS 4.0 sera basée sur LCC ? Ou en est LCC ?
J'ai aucun info de LCC actuellement (J'ai seulement entendu parlé d'une tentative de rapprochement avec Debian).
Exemple ? Il n'y a rien qui critique "gratuitement" Mandrake dans mon post. Pitié, quand tu critiques, fais comme moi => argumentes !
Là, tu n'as fait qu'une critique gratuite sans argument.
> Note : je trouve aussi scandaleux l'attitude que peuvent avoir certaines personnes envers RedHat. Moi aussi au début l'attitude de RedHat m'a choqué, mais j'ai été voir sur leur site et j'ai trouvé les bonnes réponses, car je ne suit pas l'évolution de RedHat de près, je me contente des news qui passent sur ce site, et je peux te dire que ça ne suffit pas.
J'ignore pour gaim, mais evolution utilise le mécanisme "standard" bonobo. Et l'applet "date" de gnome utilise le composant calendard d'évolution s'il le trouve.
> Je savais meme pas que gaim et evolution savaient se parler :)
Je répète, je ne connais pas gaim. Mais si gaim veut utiliser les composants Evolution, il peut le faire. S'il ne le fait pas, c'est ses oignons et c'est comme ça.
> mais j'espere bien qu'il vont vraiment intégrer dbus dans toutes les applications gnome afin de leur permettre d'etre piloter, de communiquer entre elle comme le fait dcop dans Kde actuellement. C'est ce qui manque a Gnome actuellement.
Déjà fait et depuis longtemps. De plus Dbus est plus bas niveau que Dcop et n'a aucun connaissance/contrainte sur ce qui est communiqué.
Je connais pas ipc mais tu ne connais pas Dbus ni Dcop.
> Le seul probleme, c'est que comme pour Kde, ca risque de cassé la compatibilité et donc imposer un nouveau numéro de version. Donc, peu de chance de voir dbus bien intégré à gnome d'ici gnome 3.0
Et ?
Pourquoi faut-il utiliser Dbus à la place de bonobo ou corba ? Dbus ne fait pas la même chose. Dbus fait un "truc" que bonobo ne fait pas et vice versa.
> Va voir la si tu veux plus d'info sur ce que peut offrir dbus pour le communication interapplication qui est aussi importante a mon avis que le communication system/desktop.
Je connais Dbus, merci.
Mais il y a déjà des technos sous Gnome et il n'y a pas le feu pour les remplacer.
Dbus a été fait _après_ Dcop. Il n'est pas dit que Dbus est basé sur Dcop. Sinon tu vas dire que IIS est basé sur Apache...
a) communication between KDE applications and the underlying operating system
b) communication between KDE and non-KDE applications.
a) => c'est le cadre d'utilisation de Gnome
b) => Dbus n'impose pas de format/protocole. C'est un moyen de communication. Pour l'intéropérabilité, c'est l'affaire de FreeDesktop.
Dbus est bas niveau.
Ce n'est pas parce que Gnome et KDE utilise Unix qu'il sont compatible. Ce n'est pas parcequ'ils utiliseront Dbus qu'ils seront compatibles. PostgreSQL et apache utilise IPC et s'ils sont utilisable ensemble. Ce n'est pas grace à IPC. Tu comprends la nuance ?
> L'entreprise française se positionne donc en concurrent de Novell et de RedHat sur le secteur (probablement le plus lucratif) de Linux dans l'entreprise.
C'est de l'humour ? Il y a deux ans, il y avait CS 2.1 (2.1 car Red Hat avait RHAS 2.1 :-)).
Où est la liste des applis certifiées ?
Où est le portage pour s390 ?
Quels sont les constructeurs qui supportent la distribution ?
Au bout de deux ans de "positionnement en concurrent de Novell/Red Hat" c'est un flop.
Où sont les sources ? Ce n'est pas obligatoire pour respecter la GPL mais Red Hat met les sources à disposition pour tout le monde.
Sans les sources ni liste de paquet et avec la maigre page de présentation, on ne sait pas grand chose de cette CS 3.0.
Pas de source car Mandrake a peur que quelqu'un fasse un fork équivalent à ce qu'a fait WhiteBox pour RHEL ?
Équivalents dont linuxfr ne manquera pas de faire la publicité ici avec une news en première page et un titre accrocheur comme ... "fork libre de Mandrake Corporate Server" pour bien discrédité la CS et inviter les gens à "ne pas foutre leur pognon et leur éthique du libre en l'air" : http://linuxfr.org/2004/04/20/16027.html(...)
Je n'ai pas vu de beta. Pour Red Hat il y a les betas en sources et binaires et iso. L'absence de beta laisse croire que c'est grosso-modo une Mandrake 10.1 sinon je ne vois pas comment il peuvent prétendre que c'est un produit très testé.
Notons aussi que c'est une souscription comme pour Red Hat.
Que comme pour Red Hat, les sources de MandrakeOnline (un système vaguement équivalent à rhn) côté serveur ne sont pas dispos.
Un peu d'histoire :
Que disait-on pour Red Hat il y a trois ans : http://linuxfr.org/2002/02/28/7303.html(...) Red Hat s'éloigne de plus en plus du libre au prix d'entorses de plus en plus sévères à la philosophie d'ouverture qui sied traditionnellement au logiciel libre. Plus grave, au moment de lancer l'infrastructure "up2date", on se souvient que Red Hat avait décidé de ne pas publier le programme serveur nécessaire (d'où par exemple la naissance du projet Current qui propose un serveur up2date libre).
NB: Il n'y a jamais eu les sources rhn côté serveur.
Que disait-on pour Red Hat pour avoir "osez" vendre le service rhn : http://linuxfr.org/2001/03/19/2815.html(...) Red Hat met fin à la gratuité de son Update Agent Personnellement, je n'ai rien contre Red Hat mais ils auraient pu trouver un meilleur moyen de faire tourner le moulin.
Des mises à jour officielles MandrakeSoft - dont les corrections de bugs et les mises à jour de sécurité - resteront librement disponibles pour tous les produits supportés publiquement, en suivant le tableau officiel des cycles de vie produits.
Pas pour CS (du moins les binaires).
4) Libre et Gratuit !
Une version téléchargeable de Mandrake Linux, entièrement composée de Logiciels Libres, continuera à être disponible gratuitement, et officiellement supportée.
Pas pour CS.
6) Mandrake Linux -- Un réel projet Logiciel Libre
Le développement de Mandrake Linux se déroule dans l'esprit des projets Open Source. Le développement des produits Mandrake Linux est basé sur "Cooker", qui est une plateforme et une communauté de développement publiquement disponible.
Pas vrai pour CS. Qui était au courrant de la sortie imminente de CS 3.0 ? Qui a participé à CS 3.0 et peut nous parler des "add-ons" de la CS 3.0 ? Le wiki cooker parle de la CS ?
En lisant bien ou pouvait deviner que ... c'était un bel exemple de "langue de bois". Mais que dit la news, ici même : Un document très intéressant, presqu'un pavé dans la marre en regard des évènements récents qui ont concerné d'autres éditeurs de Linux.
Vraiment marrant tout ça. Mandrake fait maintenant """pire""" que Red Hat mais pas de news d'un type qui joue le puceau outrées.
PS : J'oublie le bugzilla de CS qui ne doit pas être public et autre joyeuseté dont a "profité" Red Hat ici même.
PS2 : les sources de ce message, que certains qualifiront de "troll", viennent principalement de linuxfr (validé par un collège de "sage" (modérateurs) dont l'intégrité/objectivité ne doit pas (mais peut) être remise en cause...).
> Sinon, pour ceux qui vont se la ramener en me disant que gnome utilise deja dbus et que enlever le service n'empeche pas à gnome de fonctionner, je leur répondrais une seule chose: "Preuve que gnome n'utilise pas Dbus"(a part un outils en fait).
Pour Gnome, actuellement, Dbus est pour les messages systèmes et pratiquement rien d'autre. Donc, vires Dbus et nautilus ne voit pas qu'une clées a été ajouté, G-V-M ne voit pas les volumes, cups ne dit où en est l'impression etc.
Dbus est utilisé là où il est utile et adapté. Il n'est pas utisé à tous propos. Je trouve amusant que chez KDE, DBus est vu comme un concurrent/remplaçant de tout et n'importe quoi. Une façon de dramatiser les choses...
> Contrairement à l'intégration statique entre Gaim et Evolution
Connait pas Gaim.
Evolution n'est pas "statique". Il utilise les composants bonobo (comme les applets). Principalement :
- Evolution_Addressbook
- Evolution_Calendar
- Evolution_Mail
- Evolution_Shell
Pour "rigoler", fais :
$ mv /usr/lib/bonobo/servers/GNOME_Evolution_Calendar* /tmp
> t'as pas dû comprendre la logique de stable pour dire que les développeurs ne bossent pas sur stable ...
Je parle de bosser sur la prochaine version stable.
Une distribution est en préparation => tout le monde bosse pour la version stable (Donc cooker est en freeze par exemple).
S'il n'y a pas de distribution en préparation on a :
Cooker => développement
stable => les mises à jours
La majorité des distributeurs "freeze" tout pour les versions stables afin que tout le monde soit concentré sur la version stable (la version en cours de stabilisation).
> Su stable, à par les mise à jour de sécurité, y a tout qui est figé, d'ailleurs la revision 4 viens de sortir.
Si les développeurs avaient bossés en masse sur la version à venir de stable (Sarge actuellement) elle n'aurait pas plus d'un an de retard.
Plus d'une années de retard en informatique c'est gigantesque. C'est la preuve indéniable d'un problème profond.
Rappelez-vous, Sarge était prévu pour fin 2003 !
On est début 2005.
De deux choses l'une, soit les développeurs bossent beaucoup sur stable (c-à-d la prochaine version) mais ils sont nuls. Soit ils ne sont pas nuls et bossent sur autre chose (plus spécifiquement testing/unstable).
Sarge devait sortir avec Gnome 2.4 puis 2.6 et maintenant c'est 2.8.
Tu ne vois pas un problème ?
Ils ont fait quoi les développeurs ?
Ils ont "stabilisé" Gnome 2.4. Puis comme ils s'ennuyaient ils ont décidé de stabilisé Gnome 2.6. Puis comme ils trouveraient les soirées d'hivers longues ils ont décidé de stabilisé Gnome 2.8.
Je ne crois pas.
Une majorité d'utilisateur de Debian n'utilise pas stable.
Tu ne vois pas un problème ?
Il n'y a qu'une petite minorité d'utilisateur de Mandrake ou Red Hat qui utilise Cooker ou Rawhide. Là il n'y a pas de problème.
RHEL sort tous les 18 mois et ils sont rares les utilisateurs qui montent leur logiciel _stable_ en version. 18 mois ou 24 mois semble raisonnable en fréquence de sortie. Mais 4 ans... c'est trop.
Faire le choix de sortir une distribution tous les 5 ans est une chose.
Sortir une distribution tous les 5 ans alors que le planning dit 2 ans, montre qu'il y a manifestement un problème.
Que "stable" soit "hyper-stable" ne change rien au problème.
> Quand le projet GCC a décidé de fair eun compilateur "beta" mais de le rendre public ils l'ont nommés EGCS.
Non, egcs était un fork de gcc (un vrai, nouveau cvs, développeurs différents, objectifs différents, etc). gcc n'a pas fait egcs.
Finalement gcc a changé de politique, egcs et gcc ont fusionné (gcc 2.8).
> GCC-2.96beta
Gcc 2.96 a été utilisé pour RH7.0, RH7.1, RH7.2, RH7.3, RHEL 2.1. Il a aussi été utilisé par Mandrake et Debian (peut-être d'autres encore).
Ce n'était pas un compilateur beta.
> ca aurait évité pas mal d'ennuis à tout un tas de developpeurs de drivers à l'époque.
C'est-à-dire ?
Il n'aurait pas été obligé de corriger leur bug ? Des drivers qui compilent uniquement avec un compilateur qui contient des bugs bien spécifiques, etc... , tu parles d'un progrès...
Pour ton info, Red Hat était aussi livré avec gcc-2.7 pour compiler le noyau. Et le noyau chez Red Hat a été un temps compilé avec gcc-2.7 car il y avait encore trop de drivers buggués qui dépendaient des bug de gcc-2.7.
Notes que ça arrive aussi avec les versions de gcc officielles !
D'ailleur, le compilateur de référence pour Linux est encore gcc 2.95.2 !
> Mais sur le principe je suis contre le fait qu'une tierce partie "emballe" comme satble un programme considéré comme béta ou RC par les developpeurs.
A propos de développeurs, Red Hat a le plus grand nombre de développeur sur gcc, et de loin. Ces développeurs gcc ont estimé que c'était stable. L'histoire a montré qu'ils avaient raisons.
Pour le problème spécifique mplayer, gcc a corrigé un petit bug et mplayer a aussi corrigé son code "buggué".
Notes que ça fait depuis plusieurs années que Red Hat utilise une libc ou gcc directement tiré du cvs et ça ne dérange personne.
Pour gcc-2.96, le changement de numérotation est du à l'incompatibilité binaire.
Et pourquoi tu ne demandes pas aux autres qui ont utilisé gcc-2.96 de mettre gcc-2.96beta ou gcc_redhat-2.96 ?
Pourquoi les distributeurs les plus impliqués en développement devrait ajouter "beta" pour ce qu'ils font. Tu ne veux pas que les distributeurs bossent sur le logiciel libre ?
Red Hat va devoir mettre "beta" pour Linux, glibc, gcc, rpm, mozilla/firefox, gnome, etc....
Et Ubuntu qui a beaucoup patché Gnome doit aussi ajouter "beta" ?
Debian est dans un cercle vicieux :
- stable n'est pas utilisable
- testing est plus utilisable et donc plus utilisé
- les developpeurs bossent sur testing et oublient stable
- stable devient encore moins utilisable
- testing devient encore plus utilisable
Comme il n'y a pas de vrai "patron" pour taper sur la table, et que d'ailleurs personne n'en veut, ce n'est pas près de changer avant longtemps.
> Les anciens se souviennent de la réaction de la communeauté quand Red Hat a sorti un GCC maison numéroté comme un GCC normal avec un incrément (version officielle portant le numéro 2.95, et la version Red Hat le 2.96) . Ca avait fait grincer des dents et Red Hat n'a pas recommencé depuis.
> la réaction de la communeauté
Quelle communauté ?
Mplayer ou gcc ou RMS ?
Qui chez gcc a gueulé quand le compilateur gcc-2.96 était dans les versions betas publiquement disponibles de RH-7.0 ?
Personne.
L'attitude de Mplayer est scandaleuse car Mplayer profite largement du travail de Red Hat sur gcc et que gcc 2.96 a permis de trouver des bugs dans Mplayer (et vise vers ça).
Il y a deux communautés :
1- les développeurs de gcc
2- ceux qui lisent Voici et se régalent des "scandales"
Tu parles de la communauté "2-".
Le "GCC maison" était la version CVS de GCC comme indiqué ici : http://gcc.gnu.org/gcc-2.96.html(...) GCC 2.96 has been the code- name for our development branch that will eventually become GCC 3.0.
C'est "GCC maison" de la maison GCC.
C'était 2.96 car incompatible 2.95.
C'était 2.96 car c'était ne nom de la branche GCC où a été tiré gcc-2.96 !
C'était 2.96 car la version suivante allait être 3.0 et incompatible.
Comme indiqué ici : http://gcc.gnu.org/gcc-2.96.html(...) Current snapshots of GCC, and any version labeled 2.96, produce object files that are not compatible with those produced by either GCC 2.95.2 or the forthcoming GCC 3.0.
C'était nommé "gcc" car c'était GCC. Normal.
Je préfère "gcc 2.96" à "rh-compiler 1.0".
Je préfère "gcc 2.96" à "gcc 2.95" car incompatible 2.95.
Je préfère "gcc 2.96" à "gcc 3.0" car gcc 3.0 n'était pas sorti et gcc 3.0 serait incompatible.
Donc "gcc 2.96" n'est pas un mauvais nom. Ou alors certains ne veulent pas que Red Hat bosse directement sur la branche CVS officiel de gcc et publi son travail et le travail de gcc sous le nom "gcc" ; mais préfèrent que Red Hat fasse un fork sous un autre nom histoire de ne pas "nuire" à gcc.
Quel en serait l'intérêt pour GCC ? Aucun. Le gens penseraient que gcc n'est pas assez bon pour Red Hat et que Red Hat préfère faire cavalier seul. Ça serait très mauvais pour l'image de gcc.
Red Hat bosserait moins directement avec gcc et ça serait aussi très mauvais pour gcc car Red Hat est le principal contributeur.
Peut-être vous avez un meilleur nom à proposer ?
Ou alors gcc n'est pas libre ?
Ça fait encore bien du bruit pour un si petit truc de plusieurs années d'age...
Surtout ça fait mauvaise presse au plus gros contributeur de gcc et ça, Red Hat, mais aussi gcc, s'en passerait bien.
Red Hat a sorti une branche de développement de gcc comme ils le font depuis des années pour la libc ou rpm ou Linux ou .... Pour info, les partitions ext3 de FC3 sont incompatible actuellement. Un nouveau scandale ? Fedora devrait effacer toutes références à Linux pour ne pas "nuire à Linux" ? Faire son propre fork ? Mais c'est bon maintenant car c'est upstream (Linux 2.6.10).
Pour gcc-2.96 comme il y avait incompatibilité binaire avec la dernière version stable, Red Hat a exceptionnellement "dumpé" le numéro de version. Fin de l'histoire. Rien de nouveau sous le soleil.
C'est marrant de voir que des gens trouvent normal que Red Hat n'appelle pas "gcc" ... gcc et que les même trouvent anormal qu'on interdise d'appeller "firefox"... firefox.
Faudrait savoir sur quel pied danser.
Le problème est udev et il faut initrd pour initialiser /dev avant de lancer le premier processus sur la partition root (/dev est vide au début si initrd n'est pas utilisé).
Il y a aussi une méthode pour se passer de initrd.
Pour "root=LABEL=..." il faut toujours initrd. L'oublie de initrd (avec "root=LABEL=...") est l'oubli classique de ceux qui font un noyau personnalisé pour FC.
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 0.
Tu es "discret" ou tu n'as pas d'infos ou c'est encore au stade de gestation et tout doits rester plus ou moins confidenciel tant qu'il n'y a rien de consistant pour éviter les confusions inutiles ?
Par exemple :
> Je ne me rappelle plus des premières echéances mais il n'y aura rien avant quelques mois.
CS sort tous les 18/24 mois. Donc la prochaine c'est au mieux dans 18 mois.
> De toute manière, le LCC ne représentera que la base du système, les rpm de la majorité des applis de la prochaine corpo seront sans doute ceux de la 11.0.
http://www.mandrakesoft.com/company/press/briefs?n=/mandrakesoft/ac(...)
Les entreprises membres construiront leurs produits propres à partir de ce coeur commun. Il sera disponible dès le premier trimestre 2005 et sera intégré dans les produits suivants :
* Conectiva Enterprise Server (deuxième trimestre 2005)
* Mandrakesoft Corporate Server (deuxième trimestre 2005) <===
* Progeny Componentized Linux (premier trimestre 2005)
* Turbolinux Enterprise Server 10 (premier trimestre 2005)
Deux distributions serveurs en 6 mois ça fait beaucoup pour une distribution qui sort tous les 18/24 mois.
Tu m'expliques ? Ou tu ne veux pas ou ne peux pas ou ne sais pas ?
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 0.
Si tu me demande les sources de RHEL 3 et que je te pointe RH9, c'est tu même tonneau que quand tu me pointes Mdk 10.0 pour CS 3.0 ?
Si c'est le cas, ce n'est pas ce que j'attendais. RHEL 3 est un fork de RH9 et pas RH9 + update. Par exemple RHEL 3 a ACL et pas RH9, RHEL 3 a été porté sur PowerPC et pas RH9, etc...
Donc, pour te résumer, et ce que comprend de ton post "succint", CS 3.0 est une Mandrake 10.0 + update et c'est tout. Si j'ai une Mandrake 10.0 à jour, j'ai une CS 3.0 ?
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 0.
Désolé pour l'imprécision. Je parle uniquement des *.src.rpm de CS 3.0. Je ne parle pas de développement interne ou pour un client particulier de MandrakeSoft.
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 1.
Tu peux en dire plus ?
Ce qui me surprend dans la sortie de CS 3.0, c'est que j'attendais à une distribution basée sur Linux Core Consortium.
Tu peux en dire plus ? CS 4.0 sera basée sur LCC ? Ou en est LCC ?
J'ai aucun info de LCC actuellement (J'ai seulement entendu parlé d'une tentative de rapprochement avec Debian).
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à -2.
> Dommage non ?
Non, c'est très bien.
> Allez, je te laisse trouver tout seul les updates corporate x86_64.
Tu me trouverais les sources de la CS 3.0, ce serait cool et je t'assure que je n'aurai pas le moindre regret.
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à -4.
> et qui tapent gratuitement sur les distrib.
Exemple ? Il n'y a rien qui critique "gratuitement" Mandrake dans mon post. Pitié, quand tu critiques, fais comme moi => argumentes !
Là, tu n'as fait qu'une critique gratuite sans argument.
> Note : je trouve aussi scandaleux l'attitude que peuvent avoir certaines personnes envers RedHat. Moi aussi au début l'attitude de RedHat m'a choqué, mais j'ai été voir sur leur site et j'ai trouvé les bonnes réponses, car je ne suit pas l'évolution de RedHat de près, je me contente des news qui passent sur ce site, et je peux te dire que ça ne suffit pas.
On commence vaguement à parler de la même chose.
[^] # Re: Intégrations des applications de messagerie instentaées et freedeskt
Posté par morgendorffer . En réponse au journal J'aime KDE !!!. Évalué à 0.
> Je savais meme pas que gaim et evolution savaient se parler :)
Je répète, je ne connais pas gaim. Mais si gaim veut utiliser les composants Evolution, il peut le faire. S'il ne le fait pas, c'est ses oignons et c'est comme ça.
[^] # Re: Intégrations des applications de messagerie instentaées et freedeskt
Posté par morgendorffer . En réponse au journal J'aime KDE !!!. Évalué à 0.
Déjà fait et depuis longtemps. De plus Dbus est plus bas niveau que Dcop et n'a aucun connaissance/contrainte sur ce qui est communiqué.
Je connais pas ipc mais tu ne connais pas Dbus ni Dcop.
> Le seul probleme, c'est que comme pour Kde, ca risque de cassé la compatibilité et donc imposer un nouveau numéro de version. Donc, peu de chance de voir dbus bien intégré à gnome d'ici gnome 3.0
Et ?
Pourquoi faut-il utiliser Dbus à la place de bonobo ou corba ? Dbus ne fait pas la même chose. Dbus fait un "truc" que bonobo ne fait pas et vice versa.
> Va voir la si tu veux plus d'info sur ce que peut offrir dbus pour le communication interapplication qui est aussi importante a mon avis que le communication system/desktop.
Je connais Dbus, merci.
Mais il y a déjà des technos sous Gnome et il n'y a pas le feu pour les remplacer.
> http://lists.kde.org/?l=kde-core-devel&m=109646893512881&w=(...)
Technically DBUS provides roughly the same capabilities as DCOP. This is not
suprising given that DBUS is modelled after DCOP.
Dbus a été fait _après_ Dcop. Il n'est pas dit que Dbus est basé sur Dcop. Sinon tu vas dire que IIS est basé sur Apache...
a) communication between KDE applications and the underlying operating system
b) communication between KDE and non-KDE applications.
a) => c'est le cadre d'utilisation de Gnome
b) => Dbus n'impose pas de format/protocole. C'est un moyen de communication. Pour l'intéropérabilité, c'est l'affaire de FreeDesktop.
Dbus est bas niveau.
Ce n'est pas parce que Gnome et KDE utilise Unix qu'il sont compatible. Ce n'est pas parcequ'ils utiliseront Dbus qu'ils seront compatibles. PostgreSQL et apache utilise IPC et s'ils sont utilisable ensemble. Ce n'est pas grace à IPC. Tu comprends la nuance ?
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à -2.
Mais il n'en reste pas moins que FightGear est un très bon simulateur de vol et que le mélange banane chocolat est délicieux.
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à -1.
Comme certaines versions de MandrakeLinux (10.1 en DVD par exemple).
Fichtre, ça valait un news tout ça.
Tu ne veux pas en faire plusieurs pour Fedora, Debian, Slack, etc... ?
[^] # Re: Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 0.
# Marrant
Posté par morgendorffer . En réponse à la dépêche Corporate Server et Corporate Desktop : deux nouveaux Mandrakelinux "professionnels". Évalué à 2.
C'est de l'humour ? Il y a deux ans, il y avait CS 2.1 (2.1 car Red Hat avait RHAS 2.1 :-)).
Où est la liste des applis certifiées ?
Où est le portage pour s390 ?
Quels sont les constructeurs qui supportent la distribution ?
Au bout de deux ans de "positionnement en concurrent de Novell/Red Hat" c'est un flop.
Où sont les sources ? Ce n'est pas obligatoire pour respecter la GPL mais Red Hat met les sources à disposition pour tout le monde.
Sans les sources ni liste de paquet et avec la maigre page de présentation, on ne sait pas grand chose de cette CS 3.0.
Pas de source car Mandrake a peur que quelqu'un fasse un fork équivalent à ce qu'a fait WhiteBox pour RHEL ?
Équivalents dont linuxfr ne manquera pas de faire la publicité ici avec une news en première page et un titre accrocheur comme ... "fork libre de Mandrake Corporate Server" pour bien discrédité la CS et inviter les gens à "ne pas foutre leur pognon et leur éthique du libre en l'air" :
http://linuxfr.org/2004/04/20/16027.html(...)
Je n'ai pas vu de beta. Pour Red Hat il y a les betas en sources et binaires et iso. L'absence de beta laisse croire que c'est grosso-modo une Mandrake 10.1 sinon je ne vois pas comment il peuvent prétendre que c'est un produit très testé.
Notons aussi que c'est une souscription comme pour Red Hat.
Que comme pour Red Hat, les sources de MandrakeOnline (un système vaguement équivalent à rhn) côté serveur ne sont pas dispos.
Un peu d'histoire :
Que disait-on pour Red Hat il y a trois ans :
http://linuxfr.org/2002/02/28/7303.html(...)
Red Hat s'éloigne de plus en plus du libre
au prix d'entorses de plus en plus sévères à la philosophie d'ouverture qui sied traditionnellement au logiciel libre.
Plus grave, au moment de lancer l'infrastructure "up2date", on se souvient que Red Hat avait décidé de ne pas publier le programme serveur nécessaire (d'où par exemple la naissance du projet Current qui propose un serveur up2date libre).
NB: Il n'y a jamais eu les sources rhn côté serveur.
Que disait-on pour Red Hat pour avoir "osez" vendre le service rhn :
http://linuxfr.org/2001/03/19/2815.html(...)
Red Hat met fin à la gratuité de son Update Agent
Personnellement, je n'ai rien contre Red Hat mais ils auraient pu trouver un meilleur moyen de faire tourner le moulin.
Une raison de plus pour préférer apt ?
C'est gratuit MandrakeOnline ?
Marrant non ? Comme les gens changent...
Ben j'ai encore plus marrant. Avec une news, ici même, d'un an d'age :
http://linuxfr.org/2003/12/20/14912.html(...)
Pointe sur : http://www.mandrakesoft.com/company/press/pr?n=/pr/corporate/2446(...)
* * * Les 8 Règles d'Or de MandrakeSoft * * *
1) Des mises à jour logicielles pour tous les produits MandrakeSoft
Des mises à jour officielles MandrakeSoft - dont les corrections de bugs et les mises à jour de sécurité - resteront librement disponibles pour tous les produits supportés publiquement, en suivant le tableau officiel des cycles de vie produits.
Pas pour CS (du moins les binaires).
4) Libre et Gratuit !
Une version téléchargeable de Mandrake Linux, entièrement composée de Logiciels Libres, continuera à être disponible gratuitement, et officiellement supportée.
Pas pour CS.
6) Mandrake Linux -- Un réel projet Logiciel Libre
Le développement de Mandrake Linux se déroule dans l'esprit des projets Open Source. Le développement des produits Mandrake Linux est basé sur "Cooker", qui est une plateforme et une communauté de développement publiquement disponible.
Pas vrai pour CS. Qui était au courrant de la sortie imminente de CS 3.0 ? Qui a participé à CS 3.0 et peut nous parler des "add-ons" de la CS 3.0 ? Le wiki cooker parle de la CS ?
En lisant bien ou pouvait deviner que ... c'était un bel exemple de "langue de bois". Mais que dit la news, ici même :
Un document très intéressant, presqu'un pavé dans la marre en regard des évènements récents qui ont concerné d'autres éditeurs de Linux.
Vraiment marrant tout ça. Mandrake fait maintenant """pire""" que Red Hat mais pas de news d'un type qui joue le puceau outrées.
PS : J'oublie le bugzilla de CS qui ne doit pas être public et autre joyeuseté dont a "profité" Red Hat ici même.
PS2 : les sources de ce message, que certains qualifiront de "troll", viennent principalement de linuxfr (validé par un collège de "sage" (modérateurs) dont l'intégrité/objectivité ne doit pas (mais peut) être remise en cause...).
linuxfr : pour mieux vous abrutir !
[^] # Re: D'autres...
Posté par morgendorffer . En réponse au sondage Le vaporware de l'année 2004 :. Évalué à 1.
Tout Sun en fait.
Sun a manipulé la Vaporware comme un maître en 2004.
Je le mets en seconde dans ma liste (après Sarge).
[^] # Re: Intégrations des applications de messagerie instentaées et freedeskt
Posté par morgendorffer . En réponse au journal J'aime KDE !!!. Évalué à 0.
?????
Tu es sûr ?
> en principe il offre la meme chose.
Ah bon...
C'est une bonne nouvelle pour KDE.
[^] # Re: Intégrations des applications de messagerie instentaées et freedeskt
Posté par morgendorffer . En réponse au journal J'aime KDE !!!. Évalué à 1.
Pour Gnome, actuellement, Dbus est pour les messages systèmes et pratiquement rien d'autre. Donc, vires Dbus et nautilus ne voit pas qu'une clées a été ajouté, G-V-M ne voit pas les volumes, cups ne dit où en est l'impression etc.
Dbus est utilisé là où il est utile et adapté. Il n'est pas utisé à tous propos. Je trouve amusant que chez KDE, DBus est vu comme un concurrent/remplaçant de tout et n'importe quoi. Une façon de dramatiser les choses...
> a part un outils en fait
nautilus
cups
desktop-printing
gnome-volume-manager
nautilus-cd-burner
[^] # Re: Intégrations des applications de messagerie instentaées et freedeskt
Posté par morgendorffer . En réponse au journal J'aime KDE !!!. Évalué à 0.
Connait pas Gaim.
Evolution n'est pas "statique". Il utilise les composants bonobo (comme les applets). Principalement :
- Evolution_Addressbook
- Evolution_Calendar
- Evolution_Mail
- Evolution_Shell
Pour "rigoler", fais :
$ mv /usr/lib/bonobo/servers/GNOME_Evolution_Calendar* /tmp
Puis lances Evolution et vois la différence.
[^] # Re: \_o<
Posté par morgendorffer . En réponse au journal Debian GNU/Linux 3.0r4. Évalué à 1.
[^] # Re: Et pendant ce temps...
Posté par morgendorffer . En réponse au journal Debian GNU/Linux 3.0r4. Évalué à 7.
Je parle de bosser sur la prochaine version stable.
Une distribution est en préparation => tout le monde bosse pour la version stable (Donc cooker est en freeze par exemple).
S'il n'y a pas de distribution en préparation on a :
Cooker => développement
stable => les mises à jours
La majorité des distributeurs "freeze" tout pour les versions stables afin que tout le monde soit concentré sur la version stable (la version en cours de stabilisation).
> Su stable, à par les mise à jour de sécurité, y a tout qui est figé, d'ailleurs la revision 4 viens de sortir.
Si les développeurs avaient bossés en masse sur la version à venir de stable (Sarge actuellement) elle n'aurait pas plus d'un an de retard.
Plus d'une années de retard en informatique c'est gigantesque. C'est la preuve indéniable d'un problème profond.
Rappelez-vous, Sarge était prévu pour fin 2003 !
On est début 2005.
De deux choses l'une, soit les développeurs bossent beaucoup sur stable (c-à-d la prochaine version) mais ils sont nuls. Soit ils ne sont pas nuls et bossent sur autre chose (plus spécifiquement testing/unstable).
Sarge devait sortir avec Gnome 2.4 puis 2.6 et maintenant c'est 2.8.
Tu ne vois pas un problème ?
Ils ont fait quoi les développeurs ?
Ils ont "stabilisé" Gnome 2.4. Puis comme ils s'ennuyaient ils ont décidé de stabilisé Gnome 2.6. Puis comme ils trouveraient les soirées d'hivers longues ils ont décidé de stabilisé Gnome 2.8.
Je ne crois pas.
Une majorité d'utilisateur de Debian n'utilise pas stable.
Tu ne vois pas un problème ?
Il n'y a qu'une petite minorité d'utilisateur de Mandrake ou Red Hat qui utilise Cooker ou Rawhide. Là il n'y a pas de problème.
RHEL sort tous les 18 mois et ils sont rares les utilisateurs qui montent leur logiciel _stable_ en version. 18 mois ou 24 mois semble raisonnable en fréquence de sortie. Mais 4 ans... c'est trop.
Faire le choix de sortir une distribution tous les 5 ans est une chose.
Sortir une distribution tous les 5 ans alors que le planning dit 2 ans, montre qu'il y a manifestement un problème.
Que "stable" soit "hyper-stable" ne change rien au problème.
[^] # Re: On se calme et on respire...
Posté par morgendorffer . En réponse au journal ils sont tombés sur la tête. Évalué à 0.
Non, egcs était un fork de gcc (un vrai, nouveau cvs, développeurs différents, objectifs différents, etc). gcc n'a pas fait egcs.
Finalement gcc a changé de politique, egcs et gcc ont fusionné (gcc 2.8).
> GCC-2.96beta
Gcc 2.96 a été utilisé pour RH7.0, RH7.1, RH7.2, RH7.3, RHEL 2.1. Il a aussi été utilisé par Mandrake et Debian (peut-être d'autres encore).
Ce n'était pas un compilateur beta.
> ca aurait évité pas mal d'ennuis à tout un tas de developpeurs de drivers à l'époque.
C'est-à-dire ?
Il n'aurait pas été obligé de corriger leur bug ? Des drivers qui compilent uniquement avec un compilateur qui contient des bugs bien spécifiques, etc... , tu parles d'un progrès...
Pour ton info, Red Hat était aussi livré avec gcc-2.7 pour compiler le noyau. Et le noyau chez Red Hat a été un temps compilé avec gcc-2.7 car il y avait encore trop de drivers buggués qui dépendaient des bug de gcc-2.7.
Notes que ça arrive aussi avec les versions de gcc officielles !
D'ailleur, le compilateur de référence pour Linux est encore gcc 2.95.2 !
> Mais sur le principe je suis contre le fait qu'une tierce partie "emballe" comme satble un programme considéré comme béta ou RC par les developpeurs.
A propos de développeurs, Red Hat a le plus grand nombre de développeur sur gcc, et de loin. Ces développeurs gcc ont estimé que c'était stable. L'histoire a montré qu'ils avaient raisons.
Pour le problème spécifique mplayer, gcc a corrigé un petit bug et mplayer a aussi corrigé son code "buggué".
Notes que ça fait depuis plusieurs années que Red Hat utilise une libc ou gcc directement tiré du cvs et ça ne dérange personne.
Pour gcc-2.96, le changement de numérotation est du à l'incompatibilité binaire.
Et pourquoi tu ne demandes pas aux autres qui ont utilisé gcc-2.96 de mettre gcc-2.96beta ou gcc_redhat-2.96 ?
Pourquoi les distributeurs les plus impliqués en développement devrait ajouter "beta" pour ce qu'ils font. Tu ne veux pas que les distributeurs bossent sur le logiciel libre ?
Red Hat va devoir mettre "beta" pour Linux, glibc, gcc, rpm, mozilla/firefox, gnome, etc....
Et Ubuntu qui a beaucoup patché Gnome doit aussi ajouter "beta" ?
C'est simplement Ridicule.
[^] # Re: Et pendant ce temps...
Posté par morgendorffer . En réponse au journal Debian GNU/Linux 3.0r4. Évalué à -5.
- stable n'est pas utilisable
- testing est plus utilisable et donc plus utilisé
- les developpeurs bossent sur testing et oublient stable
- stable devient encore moins utilisable
- testing devient encore plus utilisable
Comme il n'y a pas de vrai "patron" pour taper sur la table, et que d'ailleurs personne n'en veut, ce n'est pas près de changer avant longtemps.
[^] # Re: Marche pas bien chez moi non plus
Posté par morgendorffer . En réponse au message Attributs étendus. Évalué à 1.
> setfattr: toto: Opération non supportée
Je crois qu'il y a un espace de nom pour setfattr. Essais avec :
- "setfattr -n user.type -v 'text/plain' toto"
Le "user." est important.
[^] # Re: On se calme et on respire...
Posté par morgendorffer . En réponse au journal ils sont tombés sur la tête. Évalué à 4.
> la réaction de la communeauté
Quelle communauté ?
Mplayer ou gcc ou RMS ?
Qui chez gcc a gueulé quand le compilateur gcc-2.96 était dans les versions betas publiquement disponibles de RH-7.0 ?
Personne.
L'attitude de Mplayer est scandaleuse car Mplayer profite largement du travail de Red Hat sur gcc et que gcc 2.96 a permis de trouver des bugs dans Mplayer (et vise vers ça).
Il y a deux communautés :
1- les développeurs de gcc
2- ceux qui lisent Voici et se régalent des "scandales"
Tu parles de la communauté "2-".
Le "GCC maison" était la version CVS de GCC comme indiqué ici :
http://gcc.gnu.org/gcc-2.96.html(...)
GCC 2.96 has been the code- name for our development branch that will eventually become GCC 3.0.
C'est "GCC maison" de la maison GCC.
C'était 2.96 car incompatible 2.95.
C'était 2.96 car c'était ne nom de la branche GCC où a été tiré gcc-2.96 !
C'était 2.96 car la version suivante allait être 3.0 et incompatible.
Comme indiqué ici :
http://gcc.gnu.org/gcc-2.96.html(...)
Current snapshots of GCC, and any version labeled 2.96, produce object files that are not compatible with those produced by either GCC 2.95.2 or the forthcoming GCC 3.0.
C'était nommé "gcc" car c'était GCC. Normal.
Je préfère "gcc 2.96" à "rh-compiler 1.0".
Je préfère "gcc 2.96" à "gcc 2.95" car incompatible 2.95.
Je préfère "gcc 2.96" à "gcc 3.0" car gcc 3.0 n'était pas sorti et gcc 3.0 serait incompatible.
Donc "gcc 2.96" n'est pas un mauvais nom. Ou alors certains ne veulent pas que Red Hat bosse directement sur la branche CVS officiel de gcc et publi son travail et le travail de gcc sous le nom "gcc" ; mais préfèrent que Red Hat fasse un fork sous un autre nom histoire de ne pas "nuire" à gcc.
Quel en serait l'intérêt pour GCC ? Aucun. Le gens penseraient que gcc n'est pas assez bon pour Red Hat et que Red Hat préfère faire cavalier seul. Ça serait très mauvais pour l'image de gcc.
Red Hat bosserait moins directement avec gcc et ça serait aussi très mauvais pour gcc car Red Hat est le principal contributeur.
Peut-être vous avez un meilleur nom à proposer ?
Ou alors gcc n'est pas libre ?
Ça fait encore bien du bruit pour un si petit truc de plusieurs années d'age...
Surtout ça fait mauvaise presse au plus gros contributeur de gcc et ça, Red Hat, mais aussi gcc, s'en passerait bien.
Red Hat a sorti une branche de développement de gcc comme ils le font depuis des années pour la libc ou rpm ou Linux ou .... Pour info, les partitions ext3 de FC3 sont incompatible actuellement. Un nouveau scandale ? Fedora devrait effacer toutes références à Linux pour ne pas "nuire à Linux" ? Faire son propre fork ? Mais c'est bon maintenant car c'est upstream (Linux 2.6.10).
Pour gcc-2.96 comme il y avait incompatibilité binaire avec la dernière version stable, Red Hat a exceptionnellement "dumpé" le numéro de version. Fin de l'histoire. Rien de nouveau sous le soleil.
Pour en revenir à Mozilla, l'excellent Alan Cox donne son avis :
http://www.redhat.com/archives/fedora-devel-list/2004-December/msg0(...)
C'est marrant de voir que des gens trouvent normal que Red Hat n'appelle pas "gcc" ... gcc et que les même trouvent anormal qu'on interdise d'appeller "firefox"... firefox.
Faudrait savoir sur quel pied danser.
Pour en revenir encore une fois à Mozilla, Debian devrait contacter la fondation Mozilla et voir si un arrangement est possible.
Apparament Red Hat a obtenu un arrangement :
http://www.redhat.com/archives/fedora-devel-list/2004-December/msg0(...)
[^] # Re: noyau bloque
Posté par morgendorffer . En réponse au message noyau bloque désespérément. Évalué à 2.
Le problème est udev et il faut initrd pour initialiser /dev avant de lancer le premier processus sur la partition root (/dev est vide au début si initrd n'est pas utilisé).
C'est expliqué ici :
http://fedora.redhat.com/docs/udev/(...)
Il y a aussi une méthode pour se passer de initrd.
Pour "root=LABEL=..." il faut toujours initrd. L'oublie de initrd (avec "root=LABEL=...") est l'oubli classique de ceux qui font un noyau personnalisé pour FC.
# Re: noyau bloque
Posté par morgendorffer . En réponse au message noyau bloque désespérément. Évalué à 1.
Sans initrd il faut mettre dans grub.conf "root=/dev/...".