Si j'ai bien compris, Red Carpet sera une sorte de Helix Update, mais gérera les dépendances de manière plus fine (plus stable?), de même que les formats rpm et deb. Serait-ce un concurrent de apt-get de Debian?
Et pendant ce temps-là, tapi dans l'ombre, Aduvizor attend son heure ;-)
Aller plus loin
- Ximian Red Carpet (2 clics)
- Aduva - Aduvizor (2 clics)
# pas nouveau
Posté par Anonyme . Évalué à 0.
cf l'annonce "Helix Code Rocking Out at COMDEX 2000" http://www.ximian.com/pressroom/(...) .
[^] # Re: pas nouveau
Posté par Anonyme . Évalué à 0.
# Les trolls volent bas aujourd'hui
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
Je ne CROIS pas que ce soit un concurrent d'apt-get, ca serait plutôt un frontend, un dépoussierrage de dselect à la sauce Stormix !
Sinon c'est bel et bien une plateforme pour pouvoir répandre des logiciels (Redhat a déjà signé) online. En gros plus ça va plus il y aura des rubriques : maintenant c'est Evolution, Debian, ... etc dans pas longtemps ce sera ton boulanger favoris =)
Bon nombre de discussion ont courues sur la mailing-lists de développement Gnome (Gnome-1.4, Gnome-Devel) à ce propos.
Le fait est que Ximian aura peut-être du mal pour cohabiter avec Nautilus, qui rend déjà ces mêmes services ! Certains ont pensés qu'il ne fournirait pas Nautilus mais c'est impossible car il fait partie de Gnome 1.4+ ! Bref, ca va être chaud pour eux, surtout avec Aduvizor et son interface "2001, l'Odyssée de l'espace" ;)
[^] # Re: Les trolls volent bas aujourd'hui
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Heureusement les gentils internautes corrigent de temps en temps les fautes des méchants modérateurs :)
[^] # Re: Les trolls volent bas aujourd'hui
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
C'est du bon sens ! =)
[^] # Re: Les trolls volent bas aujourd'hui
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
# Ximian et Eazel
Posté par François Heiblé . Évalué à 1.
Si quelqu'un veut bien informer un ignorant?
[^] # Re: Ximian et Eazel
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
J'ai omis de dire que bien sûr, ils ont le droit (GPL oblige) de créer une version customisée, n'intégrant pas ces services !
Je pense perso que Nautilus va s'orienter de plus en plus au niveau des services en lignes, et Ximian gardera sa position !
Reste à attendre aux environs du 28/3 pour confirmation ! =)
[^] # Re: Ximian et Eazel
Posté par Anonyme . Évalué à 0.
[^] # Re: Ximian et Eazel
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
GNOME 1.4 Schedule
------------------
1/29 Nautilus PR3 release
2/5 Library freeze date - create 1.4 branches, bug fix only mode
2/10 Freeze date for everything else - bug fix only mode, branch as
needed
2/10 Drop dead date for packages - any proposed new packages which are
not ready will be dropped)
2/15 Package due date for GNOME 1.4 Beta 1 (maintainers must upload
packages by this date)
2/17 GNOME 1.4 Beta 1 (based on Nautilus PR3)
2/18 - 2/25 Beta 1 Test Cycle
2/23 Nautilus 1.0 freeze
2/26 Nautilus release candidate tarballs released (0.9 or 0.99 or
something - done barring final Eazel
and community QA)
2/26 GNOME 1.4 Beta 2 package due date
2/28 GNOME 1.4 Beta 2 (based on Nautilus release candidate)
2/28 - 3/7 Beta 2 Test Cycle
3/5 Nautilus 1.0 release
3/6 GNOME 1.4 beta 3 package due date
3/8 GNOME 1.4 Beta 3 (based on Nautilus 1.0)
3/8 Hard freeze except for docs and translations - code changes may
only go in for critical bugs as reviewed by Release Team (or the
GNOME Foundation board for hard cases).
3/9 - 3/17 Beta 3 Test Cycle
3/16 GNOME 1.4 Release Candidate 1 package due date
3/18 GNOME 1.4 Release Candidate 1
3/18 Hard freeze for everything, including docs and translations -
code changes may only go in for critical bugs as reviewed by
Release Team and GNOME Foundation board.
3/19 - 3/26 Release Candidate 1 Test Cycle
3/25 GNOME 1.4 Final package due date - but no changes expected from RC1
3/27 GNOME 1.4 Final
[^] # Re: Ximian et Eazel
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
http://linuxfr.org/2001/02/05/2194,0,0,0.php3(...)
# Question sur l'installation
Posté par Anonyme . Évalué à 0.
[^] # Re: Question sur l'installation
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
T'as question, c'est bien : pourquoi relancer la session X (donc gnome-session pour ainsi dire) ?
Ca dépend ... t'as une Debian ? ;) (Normalement non, sinon tu n'utiliserais pas HelixUpdate)
La Debian possède un kernel patché pour pouvoir écrire sur des fichiers en cours d'exécution !
Pour les libs, c'est autre chose : elles sont chargées en mémoire, tu peux les écraser.
C'est un début de réponse ...
[^] # Re: Question sur l'installation
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
A quoi cela sert-il de pouvoir écrire sur des fichiers en cours d'exécution ?
Il me semble que la mise à jour d'un paquets passe par la suppression des anciens fichiers, puis par l'installation des nouveaux. Dans ces conditions il n'est pas nécessaires de patcher le noyau pour supprimer un fichier en cours d'exécution.
Ce patch a t'il vraiment une utilité ?
[^] # Re: Question sur l'installation
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
Ca a été pendant longtemps une des bannières de la Debian, je ne sais pas si maintenant beaucoup de monde y fait attention.
[^] # Re: Question sur l'installation
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
Imaginons que j'ai apache 1.3.14 qui fonctionne (processus httpd)
J'écrase sur disque, grâce au patch Debian, le fichier binaire httpd avec celui d'apache 1.3.17 (supprimer l'ancien binaire, puis installer le nouveau reviens normalement au même)
En mémoire j'aurais toujours apache 1.3.14.
Pour que ce soit effectivement Apache 1.3.17 qui fonctionne je suis obligé de quitter le processus httpd en cours et de relancer le nouveau.
Donc ce patch ne sert à rien pour avoir de la haute disponibilité et pour mettre à jour les paquets.
De plus si je ne redémarre pas le processus httpd, je prend le risque d'avoir une erreur de chargement de page si tout le binaire httpd n'est pas en mémoire.
un "http://localhost/server-info"(...) devrait permettre de vérifier mes dires mais je n'ai pas deux binaires sous la main.
Cela dit, si le patch permet effectivement de mettre à jour en mémoire un changement de binaire sans interruption de service, je veux l'URL !
[^] # Re: Question sur l'installation
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
> heu, les libs ... ca serait sympas de copier les libs dynamiques, ya pas que les binaires dans la vie ;)
> Pour que ce soit effectivement Apache 1.3.17 qui fonctionne je suis obligé de quitter le processus httpd en cours et de relancer le nouveau.
1) t'inquiète, y'en a sûrement plus d'un ;)
2) pourquoi latter l'autre tout de suite ? Tu peux très bien chopper la liste des process httpd, démarrer une autre session apache puis killer les anciens : pendant un instant, tu auras 2 fois le nombres de threads que tu as d'habitude !
"pour que ce soit effectif" : nan, le processus père qui est lancé lit la config de httpd.conf, srm.conf, ... etc après, ses fils l'ont aussi forcément (mémoire partagée, héritage, ... j'en sais trop rien, je suis pas allé matter le code ;)
Donc ta deuxième session aura bel et bien la nouvelle config active ...
C'est-y pas magique ?
[^] # Re: Question sur l'installation
Posté par Anonyme . Évalué à 0.
[^] # Re: Question sur l'installation
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
Non, ce n'est pas possible. Un seul processus à la fois peut écouter un port IP. Donc tant que le processus httpd père est présent, je ne peut en démarrer un autre qui écoute sur le même port (80 en l'occurence).
[^] # Re: Question sur l'installation
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
Néanmoins, je tiens quand même à vous dire que les conneries que j'ai racontées marchent effectivement ! C'est ce que vous avez dit toi et l'anonyme du dessus (remarquez que quand je troll, moi j'assume) qui est FAUX ! Un seul processus peut écouter une paire {adresse IP, port}, donc rien ne t'empêche de faire de l'IP aliasing (sorte d'émulation comme si tu avait deux cartes rézo), et donc de posséder 2 adresses IP pour la même station, qui, j'en convient, bosseront sur le même port !
Tu balances ensuite un SIGHUP à l'ancien Apache, qui vas attendre que ses fils se terminent correctement (sinon, adieux les communications en cours ...), le reforcera à lire ses fichiers de config (ya un autre signal qui ne fait pas cette seconde partie) et à REDEMARRER : donc ca c'est pour un seul Apache, sans couper les comms !
Mais pour aller au fin-fond de ma pensée, lorsqu'on a deux process Apache père, on peut envoyer le signal (je sais plus lequel ?) à l'ancien process Apache père qui va JUSTE attendre la fin de ses fils puis se terminer. Il ne reste donc plus qu'un seul process Apache père avec la nouvelle config, qui écoute deux paires {adresse IP,port} auquel cas il y aurait fallu mettre deux fois moins de thread dans la config, car Apache balances N process pour une paire {adresse IP,port} !
[^] # Re: Question sur l'installation
Posté par pasBill pasGates . Évalué à 1.
Que Apache 1.3.14 se transforme en 1.3.17 en memoire par magie ?
Si tu veux remplacer un processus par un autre, ben il y a pas de miracle, faut virer le premier pour mettre le second.
D'autre part si tu veux vraiment faire de la haute disponibilite, ben tu as un cluster, et si tu as un cluster, ben tu mets les machines off-line les unes apres les autres pour faire ta modif et tu coupes pas ton service. Personne ne fait de la haute disponibilite avec une seule machine, parce que si elle crashe, ben t'as plus de service du tout, ce qui est loin d'etre de la haute disponibilite.
[^] # Re: Question sur l'installation
Posté par syntaxerror . Évalué à 1.
bien malgré le kernel 2.2.18 standard que j'utilise.
En regardant en vitesse le diff du 2.2.18, je n'ai
vu que les habituelles modifs pour désactiver l'apm
par défaut, le "bigphysarea" et quelques drivers.
En tous cas, c'est vrai que la Debian s'upgrade
parfaitement en état de marche (et le reste, en état).
A vrai dire, on écrit pas sur un fichier en cours
d'exécution. On écrit à côté. La copie active reste
jusqu'à arrêt du programme. Petit test à faire lors
d'un upgrade de Netscape (ce qui arrive souvent
pour raisons de sécurité): démarrer netscape,
faire l'upgrade comme d'hab, df pour vérifier la
place disque utilisée, arrêter netscape, re-df
et comparer.
[^] # Re: Question sur l'installation
Posté par Stéphane Démurget (site web personnel) . Évalué à 1.
De plus, ca va être chaud de vérifier avec un simple 'df', il faudrait essayer 'checkinstall', qui log les écritures, déplacements, lectures des fichiers lors de l'exécution d'une commande !
[^] # Re: Question sur l'installation
Posté par Anonyme . Évalué à 0.
Techniquement si ce genre de patch existait, ce serait aussi inutile que les patch de "sécurité"
pour rendre la pile non exécutable (eux y sont sur les kernels mandrake...)
[^] # Re: Question sur l'installation
Posté par Anonyme . Évalué à 0.
Mais que signifie "fichier en cours d'execution" ?
A ma connaissance, un programme n'est qu'une suite d'instructions chargées en mémoire *à partir* du code contenu dans ledit fichier. Alors que tu écrives toto ou titi dans le fichier chargé, peu importe, vu que ces modifications ne seront prises en compte dans le programme qu'une fois que celui-ci sera effectivement relu sur le disque (les instructions du nouveau programme étant ainsi chargées dans la mémoire).
Donc, je pense que rien n'interdit de réécrire sur un fichier qui au moment de l'éxecution ne joue aucun rôle sur le bon déroulement du programme (une fois que les instructions se trouvent en mémoire). Un patch de kernel me paraît ainsi totalement inutile ou plutôt hors de propos (surtout quand on entend dire que la Debian possède un noyau Linux "originel"... ceci n'est pas un troll j'ai aussi une Debian).
--
bmc pas chez lui donc pas authentifié
[^] # Re: Question sur l'installation
Posté par Anonyme . Évalué à 0.
Ou alors gdm prépare t'il l'environnement de sorte que Gnome soit utilisable ?
Ce qui implique qu'on ne peut utiliser un xdm/kdm sans 'bidouille'.
[^] # Re: Question sur l'installation
Posté par Manuel Menal . Évalué à 1.
Mais ne rêve pas, si tu upgrades Gnome sous Gnome, tu ne verras pas ton interface se métamorphoser comme par magie. Tu devras bien relancer Gnome :)
Non, gdm ne prépare pas l'environnement Gnome pour qu'il soit utilisable. Gdm, en tout cas en configuration par défaut, lance juste un script (dans /etc/X11/gdm/Sessions) qui lance uniquement gnome-session, comme tu pourrais le faire.
Les développeurs de Gnome, contrairement à ceux d'autres environnement (pas forcément KDE), ont toujours mis un point d'honneur à ce que leurs applications soient parfaitement utilisables dans un autre environnement. Ainsi, l'utilisation des types MIME est poussée à son maximum, là où par exemple Kmail lance obligatoirement Kfm (ou peut-être Konqueror maintenant). (c'est effectivement une critique, mais ne confondez pas critique et troll :)
Bon, il y'a peut-être des erreurs dans ce commentaire, je m'en excuse d'avance...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.