> Là où yum me gonfle, c'est quand pour rechercher des infos sur un paquetage, je suis obligé d'avoir une connexion active.
yum --help :
-C run entirely from cache, don't update cache
Et voilà. Je crois que tu n'a pas beaucoup cherché.
Tu peux aussi faire un "yum makecache" quand tu as la connection. Ainsi il récupère aussi la liste des fichiers et ses attributs (mode, md5sum, etc). Par défaut yum récupère ces infos que si c'est nécessaire pour l'action demandée (requête, dépendance sur un fichier, etc).
> tout ça parce que les messages d'erreur sont mal foutus...
Tout ça car tu n'as pas lu la doc.
Man yum:
SEE ALSO
yum.conf (5)
Man yum.conf
proxy url to the proxy server that yum should use.
proxy_username
username to use for proxy
proxy_password
password for this proxy
J'ai mis 10 secondes pour trouver l'info.
Ce qui manque c'est la configuration du proxy à l'installation (via firstboot par exemple) ou que pirut propose automatiquement de configurer le proxy si la connection échou. Pour plus tard.
> > Au final Red Hat a trouvé que ça sucks (et je suis d'accord).
> Oui, bof... Tout le monde a critiqué Linuxconf. C'était tout de même le premier outil inventé pour nous faciliter la vie.
Je ne voulais pas dire que Linuxconf suckait. Mais que le principe de dépendre d'un outil externe pour la configuration d'une distribution suckait.
De plus il faut considérer l'audience. Les outils de configuration d'une distribution doivent être simples voire trivials. Un outil pour configurer chaque touche du clavier sous X11 c'est bien. Mais ça n'a rien à foutre avec les outils de configuration par défaut d'une distribution.
Regarde Ubuntu. Je trouve cette distribution assez "creuse". Mais ce qu'elle démontre clairement c'est que les gens par défaut ne veulent pas être face à un tableau de bord d'avion même si chaque bouton a son utilité.
Qui peut le plus n'est pas toujours qui peut le mieux.
> > Il y a quoi pour configurer un DNS chez Mandriva ?
> drakwizard ?
Pour mettre en place un serveur DNS primaire ?
Je ne parle pas de seulement ajouter une ou deux lignes à /etc/resolv.conf, mais de configurer un serveur DNS.
> Par contre, il est difficile de l'utiliser par défaut dans l'état actuel des choses, il est difficilement administrable, ne fonctionne (pour l'instant) qu'une fois un utilisateur loggué
Il y a des reproches ici qui sont liés aux objectifs même de NetworkManager.
Je ne vois pas de solutions.
> et duplique les scripts réseaux système.
Pourquoi ?
Si tu veux une connection permanente, tu passes par /etc/sysconfig. Si c'est une connection par utilisateur tu passes par NetworkManager.
NB : NetworkManager n'utilise pas /etc/sysconfig (il n'utilise rien de /etc sauf NetworkManagerDispatcher). Ou alors j'ai raté un épisode.
Mais il pourrait effectivement y avoir une options (après saisi du mot de passe root) pour que la configuration soit utilisées en permanence.
Le fonctionnement de NetworkManager c'est :
- tu branches ta carte wifi via usb
- tu choisis ton réseau
- t'es connecté
- tu vas chez un pote il a un autre réseau, il te donne le mot de passe wifi
- tu "bidouilles" l'applet NetworkManager et t'es connecté
- tu retournes chez toi et t'es automatiquement connecté
Aucun passage en root. Le mot de passe wifi que ton pote t'a donné est bien par utilisateur. Si tu prêtes ton portable à un autre pote, il n'a pas a avoir accès ou utiliser le précédent mot de passe.
Globalement Mandriva n'a pas compris la philosophie de NetworkManager.
Certe NetworkManager est assez compliqué. Mais si NetworkManager n'utilise pas ifcfg, ce n'est pas pour rien. ifcfg c'est pour une connection qui est sensée toujours marcher avec des paramètres qui ne bougent pas.
Ben NetworkManager ne veut pas remplacer /etc/sysconfig.
> NetworkManager is supposed to be able to read network settings from the current system configuration (ifcfg files).
Je ne crois pas. En tout cas pas pour la connection wifi. Le seul truc que fait NetworkManager c'est de changer le default gateway (donc il doit connaitre la valeur avant la création de la connection wifi et la restaurer après).
Pour F7 Fedora devrait donner un coup de boost à NetworkManager pour le rendre "rock solid".
> Tu vois Fedora dire qu'il faut développeur pour Gnome
Ooops. C'est Red Hat qui dit à ses employés qu'il faut développer pour Gnome. Le projet Fedora n'a pas à dire à ses contributeurs de développer pour tel ou tel bureau.
> qui en plus indiquent bien dans leur nom le nom dudit concurrent
Tu peux toujours changer le nom.
Avant les programmes de configuration de Red Hat commençaient par "redhat-config". Pour Fedora (et idem RHEL maintenant) le nom est plus neutre : system-config-*.
M'enfin, tout finit par se savoir...
> En quoi être GNOME-HIG compliant est un avantage pour un outil multi-bureaux ?
Mandriva respecte quoi comme HIG ?
Il ont créer un nouveau HIG qui sucks aussi bien sous Gnome que sous KDE ?
Pour info, par défaut Fedora utilise Gnome, Fedora supporte Gnome (développement (très) actif en upstream). Mais Fedora propose aussi KDE.
Tu vois Fedora dire qu'il faut développeur pour Gnome et dire aussi que les outils de configuration ne respectent pas le HIG Gnome ?
Pour F7 il y aura :
- Fedora Prime : Sélection des programmes par défaut par le team Fedora. Que Gnome.
- Fedora KDE : KDE, pas de Gnome.
- Fedora Full (peut-être) : tout Fedora. KDE, Gnome, XFCE, etc..
> il y avait un monde du point de vue de la maturité
Exemple ?
J'ai déjà demandé ce que fait urpmi et ne fait pas yum. Yum a une préthore de plugin, yum est utilisé par anaconda, mock, pirut, puggy, puplet, etc...
Il ne manque pas de maturité. Il a été mis par défaut dans Fedora pour FC1 ou FC2 (j'ai oublié) et Yum existait bien avant Fedora (il était utilisé par Yellow Dog).
> notamment la différence de réactivité de l'outil
Au delà des optimisations qui sont toujours bienvenues (si elles ne rendent pas le code incompréhensible), il y a aussi des questions de choix techniques. Entre autre yum utilise librpm pour vérifier les dépendances. Oui c'est long, mais ça marche superbement. Si yum dit que des paquets peuvent être installés, ils peuvent être installés. Ce n'est pas toujours le cas avec apt4rpm.
> je pense que c'est plus lié avec l'envie de se différencier de Mandriva
C'est pour se différencier de Mandriva ? Ça été mis après avoir consulté les plans de Mandriva ?
Fedora a déjà bien assez à faire en voulant faire évoluer le logiciel libre et c'est un objectif beaucoup plus ambitieux que seulement se différencier de Mandriva.
Sûr que Fedora a des outils de configuration que n'a pas Mandriva (lvm, nfs, cluster, netboot, etc). Va les proposer à Mandriva en leur demandant de les adopter. Tu vas être fraichement accueilli.
Alors au-lieu de dire que Red Hat/Fedora ne veut pas des outils de Mandriva, prend les choses dans l'autre sens et demande toi pourquoi Mandriva ne veut pas des outils de configuration de Red Hat/Fedora.
Mandriva supporte kerberos ou Fedora Directory Server "out of the box" ?
> gestionnaire de fenetre 3D,
Un case à cocher pour la configuration et Fedora a pratiquement tout développé.
> wifi,
Fedora a développé NetworkManager qui est aussi repris par Ubuntu et Novell. La seulement question que je me pose, c'est quand Mandriva va reprendre NetworkManager...
> Chez mandriva, l'outil de partitionnement est tres bien foutu par exemple.
Par défaut Fedora utilise lvm. Donc c'est fait par system-config-lvm. Btw Mandriva propose un outil de configuration pour lvm ?
Les outils de configuration sont très dépendants de la distribution.
> juste pour prouver que tu en as une plus grosse !
Certe et c'est compréhensible.
Mais il faut creuser le problème un peu plus loin.
Par exemple Fedora.
Fedora n'utilise que du python pour les outils de configuration.
Anaconda est en python, yum est en python, donc anaconda peut utiliser (et le fait) yum. D'où Fedora qui supporte (enfin) les dépôts externes à l'installation.
Sous Fedora au premier boot, on arrive sur system-config-firstboot. Ce dernier appèles divers programmes comme system-config-securitylevel, system-config-sound, system-config-date, etc... Tous les system-config-* étant en python, ils sont parfaitement intégrés à system-config-firstboot.
Quelques exemples volé sur le web: http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...) http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...) http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...)
Ces system-config-* peuvent aussi être appelé de façon indépendante hors de system-config-firstboot (soit via la ligne de commande, soit via le menu Système->Administration). La majorité des system-config-* tourne aussi en mode texte.
Regardons aussi l'historique de Red Hat. A une époque (RH 6.x ?) Red Hat utilisait un programme qu'il n'avait pas développé pour configurer le système. Red Hat n'était pas le seul à utilise ce programme (j'ai oublié son nom). Au final Red Hat a trouvé que ça sucks (et je suis d'accord).
Donc Red Hat a considéré les outils de configuration comme "statégiques".
C'est important car (par ordre d'importance à mes yeux) :
1- c'est très utilisé
2- ça dépend beaucoup de la distribution
3- ça fait parti de la signature de la distribution
Le 2 est important. Par exemple la configuration (du moins le paramétrage de la configuration; pas la configuration fine) sous Fedora est principalement stockée dans /etc/sysconfig et est quasi totalement dépendant de la distribution. Debian n'a pas de /etc/sysconfig, SuSE a un /etc/sysconfig mais l'utilise de façon très différente de Fedora (Fedora n'y met que de grosses options). Etc...
Si par exemple Fedora ajoute ipv8 pour la Fedora 20, il faut que les outils de configuration supportent ipv8. Si le distributeur ne développe pas les outils de configuration, c'est compliqué ou trop long (discussion avec l'équipe en upstream).
Concernant Red Hat/Fedora, il y a aussi un aspect qu'on ne peut négliger. Red Hat a beaucoup de développeur. L'activité développement des outils system-config-* leur prend très peu de ressource pour eux.
"Culturellement", Red Hat ne fait pas de distribution pour les "petites filles" mais principalement les administrateurs/développeurs voire station de travail. Si pour formater un disque dure il faut taper une ligne commande, ben il faut taper une commande. On va pas développer une interface graphique pour un truc qu'on fait tous les 36 du mois.
> Fedora/Red Hat aurait gagné sur toute la ligne à reprendre urpmi
Ah bon...
> pourquoi ne l'ont-ils pas fait ?
Car urpmi n'a pas été proposé contrairement à apt, yum et smart (qu'on a trouvé très tôt dans Fedora Extras, avant la sortie de FC1). Je crois que j'ai vue qu'une seule proposition en faveur de urpmi ! Yum a été retenu. NB : Yum n'est pas un projet Red Hat. Il a été fait pour Yellow Dog au début.
Car urpmi est compliqué. "urpmi.update -a ; urpmi -autoselect" (ou un truc approchant) pour faire un "yum update".
Car urpmi est écrit en perl. Red Hat a fait de python son "standard", tous les outils Red Hat sont en python.
Car urpmi ...
Je ne vois pas pourquoi tu t'en prends à Red Hat alors que personne reprend les outils Mandriva.
En dehors du support des périphériques amovibles, que propose urpmi que n'a pas yum (ou pirut) ?
zfs peut fonctionner sous Linux mais il ne peut pas être diffusé avec Linux. GPL oblige, pour le plus grand bien des droits de l'utilisateurs et leurs pérennités.
> Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente.
Tous les sgdb qui font des transactions ont toujours un état cohérent sur le disque. C'est définitivement le cas pour PostgreSQL. Après d'une coupure de courant ou d'un freeze système, le sgdb ignore (nettoye) simplement les transactions en cours (tout ce qui n'a pas été validé par le retour de "commit", un retour d'instruction type "insert into ..."). Et il ne va surtout pas les refaires puisqu'elles sont imcompletes !
Notes que c'est indispensable, sinon la base de donnée ne pourait pas redémarrer dans un état cohérent après une bête coupure de courrant.
> Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot.
Certe, mais ce n'est pas nécessaire avec un "vrai" snapshot.
Ton snapshot c'est l'état de ta bd comme si le moteur de base de donnée recevait un "kill -9". Or les sgbd doivent supporter un "kill -9" (ou une coupure de courant).
> Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point.
C'est cohérent, point.
> Là ça passe par un agent intermédiare.
Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).
Autre chose, quand on parle de "rejouer un journal", on ne rejoue que les transactions validées (celles avec un commit/etc qui a aboutis ET qui est indiqué comme telle dans le journal).
> Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir.
Postgresql le fait aussi :-)
Ça été introduit dans PostgreSQL 8.0 je crois.
L'API Windows est si large, si profonde et si fonctionnelle que la plupart des
éditeurs de logiciels indépendants seraient stupides de ne pas l'utiliser. De plus,
elle est si profondément insérée dans le code source de nombreuses
applications Windows que le coût de passage à un système d'exploitation
différent serait énorme. [...] C'est ce coût de passage à un autre système qui a donné aux clients la patience
de continuer à utiliser Windows, malgré toutes nos erreurs, nos gestionnaires
de périphériques défectueux, notre coût total de possession élevé, notre
difficulté, parfois, à imaginer des solutions attrayantes pour nos clients, et bien
d'autres difficultés. [...] Les clients évaluent en permanence d'autres
plateformes de bureau, [mais] cela leur demanderait tellement de travail de
changer de plateforme, qu'ils espèrent que nous améliorerons Windows plutôt
que de les contraindre à changer. En bref, sans cette franchise exclusive appelée l'API Windows, nous serions
morts depuis longtemps.579
La franchise Windows est alimentée par le développement d'applications
axées sur nos API.
C'est page 124-125.
J'avais dit que l'API de Windows sucks, on sait pourquoi.
Je vous conseille de lire à partir de la page 66 (sur les standards ouverts). C'est fabuleux comme MS se fout de la commission européenne !
Deux choses :
- L'europe a produit un fabuleux travail pour "démasquer" les embrouilles de MS.
- MS n'a aucune limite pour se foutre du monde. C'est un voyou.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
yum --help :
-C run entirely from cache, don't update cache
Et voilà. Je crois que tu n'a pas beaucoup cherché.
Tu peux aussi faire un "yum makecache" quand tu as la connection. Ainsi il récupère aussi la liste des fichiers et ses attributs (mode, md5sum, etc). Par défaut yum récupère ces infos que si c'est nécessaire pour l'action demandée (requête, dépendance sur un fichier, etc).
> tout ça parce que les messages d'erreur sont mal foutus...
Tout ça car tu n'as pas lu la doc.
Man yum:
Man yum.conf
J'ai mis 10 secondes pour trouver l'info.
Ce qui manque c'est la configuration du proxy à l'installation (via firstboot par exemple) ou que pirut propose automatiquement de configurer le proxy si la connection échou. Pour plus tard.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à -1.
Le thread débute par (posté par lezardbreton) :
Et je répondait à lezardbreton.
T'es d'une mauvaise fois affolante.
[^] # Re: c'est ça le libre ...
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
> Oui, bof... Tout le monde a critiqué Linuxconf. C'était tout de même le premier outil inventé pour nous faciliter la vie.
Je ne voulais pas dire que Linuxconf suckait. Mais que le principe de dépendre d'un outil externe pour la configuration d'une distribution suckait.
De plus il faut considérer l'audience. Les outils de configuration d'une distribution doivent être simples voire trivials. Un outil pour configurer chaque touche du clavier sous X11 c'est bien. Mais ça n'a rien à foutre avec les outils de configuration par défaut d'une distribution.
Regarde Ubuntu. Je trouve cette distribution assez "creuse". Mais ce qu'elle démontre clairement c'est que les gens par défaut ne veulent pas être face à un tableau de bord d'avion même si chaque bouton a son utilité.
Qui peut le plus n'est pas toujours qui peut le mieux.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
Ça changer rien.
> > Il y a quoi pour configurer un DNS chez Mandriva ?
> drakwizard ?
Pour mettre en place un serveur DNS primaire ?
Je ne parle pas de seulement ajouter une ou deux lignes à /etc/resolv.conf, mais de configurer un serveur DNS.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 2.
Il y a des reproches ici qui sont liés aux objectifs même de NetworkManager.
Je ne vois pas de solutions.
> et duplique les scripts réseaux système.
Pourquoi ?
Si tu veux une connection permanente, tu passes par /etc/sysconfig. Si c'est une connection par utilisateur tu passes par NetworkManager.
NB : NetworkManager n'utilise pas /etc/sysconfig (il n'utilise rien de /etc sauf NetworkManagerDispatcher). Ou alors j'ai raté un épisode.
Mais il pourrait effectivement y avoir une options (après saisi du mot de passe root) pour que la configuration soit utilisées en permanence.
Le fonctionnement de NetworkManager c'est :
- tu branches ta carte wifi via usb
- tu choisis ton réseau
- t'es connecté
- tu vas chez un pote il a un autre réseau, il te donne le mot de passe wifi
- tu "bidouilles" l'applet NetworkManager et t'es connecté
- tu retournes chez toi et t'es automatiquement connecté
Aucun passage en root. Le mot de passe wifi que ton pote t'a donné est bien par utilisateur. Si tu prêtes ton portable à un autre pote, il n'a pas a avoir accès ou utiliser le précédent mot de passe.
> http://wiki.mandriva.com/en/Projects/EasyWifi/Development/Ne(...)
Globalement Mandriva n'a pas compris la philosophie de NetworkManager.
Certe NetworkManager est assez compliqué. Mais si NetworkManager n'utilise pas ifcfg, ce n'est pas pour rien. ifcfg c'est pour une connection qui est sensée toujours marcher avec des paramètres qui ne bougent pas.
> http://wiki.mandriva.com/en/Projects/EasyWifi/Development/Ne(...)
> NetworkManager could be a complete replacement of the network scripts
Ben NetworkManager ne veut pas remplacer /etc/sysconfig.
> NetworkManager is supposed to be able to read network settings from the current system configuration (ifcfg files).
Je ne crois pas. En tout cas pas pour la connection wifi. Le seul truc que fait NetworkManager c'est de changer le default gateway (donc il doit connaitre la valeur avant la création de la connection wifi et la restaurer après).
Pour F7 Fedora devrait donner un coup de boost à NetworkManager pour le rendre "rock solid".
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 2.
Ooops. C'est Red Hat qui dit à ses employés qu'il faut développer pour Gnome. Le projet Fedora n'a pas à dire à ses contributeurs de développer pour tel ou tel bureau.
Au passage, pour F7 (avec la fusion de Core et Extras) il sera plus facile de participer à KDE et/ou son intégration dans Fedora. Si vous aimez Fedora et KDE, il ne faut pas hésiter :
http://fedoraproject.org/wiki/KDE
http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE
http://fedoraproject.org/wiki/UnleashKDE (les motivations)
[^] # Re: Question de droits ?
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
Tu peux toujours changer le nom.
Avant les programmes de configuration de Red Hat commençaient par "redhat-config". Pour Fedora (et idem RHEL maintenant) le nom est plus neutre : system-config-*.
M'enfin, tout finit par se savoir...
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
Pour voir si un dépôt a été mis à jours, Yum ne downloade qu'un petit fichier (repomd.xml ; moins de 2k).
> et tu évites les upgrade foireux qui te désintallent plein de packages
Yum ne désintalle un package (foo) que si une mise à jour a un "obsolet: foo". De plus yum ne fait jamais de downgrade.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
Mandriva respecte quoi comme HIG ?
Il ont créer un nouveau HIG qui sucks aussi bien sous Gnome que sous KDE ?
Pour info, par défaut Fedora utilise Gnome, Fedora supporte Gnome (développement (très) actif en upstream). Mais Fedora propose aussi KDE.
Tu vois Fedora dire qu'il faut développeur pour Gnome et dire aussi que les outils de configuration ne respectent pas le HIG Gnome ?
Pour F7 il y aura :
- Fedora Prime : Sélection des programmes par défaut par le team Fedora. Que Gnome.
- Fedora KDE : KDE, pas de Gnome.
- Fedora Full (peut-être) : tout Fedora. KDE, Gnome, XFCE, etc..
[^] # Re: Question de droits ?
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 2.
> http://www.tuxmachines.org/gallery/albums/pclos2007b2/pcc2.j(...)
Intéressant, limite le KDE touch.
Pourquoi ? Hal fait ça tout seul.
Pourquoi deux fois cette option ?
Idem pour floppy.
Intérêt de la chose ?
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
Rire.
On trouve presque tous les system-config dans Gentoo :
http://gentoo-portage.com/Search?search=system-config
Et pour drake :
http://gentoo-portage.com/Search?search=drake
0, nada.
La malédiction Mandriva a encore frappé.
Il y a quoi pour configurer un DNS chez Mandriva ?
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 2.
Et pourquoi "--auto-update" et non tout simplement "--update" ?
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 1.
Exemple ?
J'ai déjà demandé ce que fait urpmi et ne fait pas yum. Yum a une préthore de plugin, yum est utilisé par anaconda, mock, pirut, puggy, puplet, etc...
Il ne manque pas de maturité. Il a été mis par défaut dans Fedora pour FC1 ou FC2 (j'ai oublié) et Yum existait bien avant Fedora (il était utilisé par Yellow Dog).
> notamment la différence de réactivité de l'outil
Au delà des optimisations qui sont toujours bienvenues (si elles ne rendent pas le code incompréhensible), il y a aussi des questions de choix techniques. Entre autre yum utilise librpm pour vérifier les dépendances. Oui c'est long, mais ça marche superbement. Si yum dit que des paquets peuvent être installés, ils peuvent être installés. Ce n'est pas toujours le cas avec apt4rpm.
> je pense que c'est plus lié avec l'envie de se différencier de Mandriva
Franchement, je crois que Fedora en a rien à foutre de se différencier de Mandriva. Techniquement Fedora a des fonctionnalités qu'on ne trouve pas chez Mandriva. Fedora n'a pas pris SeLinux pour seulement se différencier de Mandriva (surtout quand on considère la quantité de boulot demandé ; d'ailleurs Fedora est la seule distribution a supporter SeLinux "out of the box").
Pour F7 (parmis d'autres choses et si tout va bien) :
http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitch(...)
http://fedoraproject.org/wiki/Releases/FeatureTicklessKernel
http://fedoraproject.org/wiki/Releases/FeatureNouveau
http://fedoraproject.org/wiki/Releases/FeatureKVM
http://fedoraproject.org/wiki/Releases/FeatureCustomDistro
C'est pour se différencier de Mandriva ? Ça été mis après avoir consulté les plans de Mandriva ?
Fedora a déjà bien assez à faire en voulant faire évoluer le logiciel libre et c'est un objectif beaucoup plus ambitieux que seulement se différencier de Mandriva.
Sûr que Fedora a des outils de configuration que n'a pas Mandriva (lvm, nfs, cluster, netboot, etc). Va les proposer à Mandriva en leur demandant de les adopter. Tu vas être fraichement accueilli.
Alors au-lieu de dire que Red Hat/Fedora ne veut pas des outils de Mandriva, prend les choses dans l'autre sens et demande toi pourquoi Mandriva ne veut pas des outils de configuration de Red Hat/Fedora.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 0.
Mandriva supporte SeLinux ?
> reseau,
Mandriva supporte kerberos ou Fedora Directory Server "out of the box" ?
> gestionnaire de fenetre 3D,
Un case à cocher pour la configuration et Fedora a pratiquement tout développé.
> wifi,
Fedora a développé NetworkManager qui est aussi repris par Ubuntu et Novell. La seulement question que je me pose, c'est quand Mandriva va reprendre NetworkManager...
> Chez mandriva, l'outil de partitionnement est tres bien foutu par exemple.
Par défaut Fedora utilise lvm. Donc c'est fait par system-config-lvm. Btw Mandriva propose un outil de configuration pour lvm ?
Les outils de configuration sont très dépendants de la distribution.
[^] # Re: c'est ça le libre ...
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
Certe et c'est compréhensible.
Mais il faut creuser le problème un peu plus loin.
Par exemple Fedora.
Fedora n'utilise que du python pour les outils de configuration.
Anaconda est en python, yum est en python, donc anaconda peut utiliser (et le fait) yum. D'où Fedora qui supporte (enfin) les dépôts externes à l'installation.
Sous Fedora au premier boot, on arrive sur system-config-firstboot. Ce dernier appèles divers programmes comme system-config-securitylevel, system-config-sound, system-config-date, etc... Tous les system-config-* étant en python, ils sont parfaitement intégrés à system-config-firstboot.
Quelques exemples volé sur le web:
http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...)
http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...)
http://blog.skydiverss.net/public/Screenshots/Capture%20FC7/(...)
Ces system-config-* peuvent aussi être appelé de façon indépendante hors de system-config-firstboot (soit via la ligne de commande, soit via le menu Système->Administration). La majorité des system-config-* tourne aussi en mode texte.
Regardons aussi l'historique de Red Hat. A une époque (RH 6.x ?) Red Hat utilisait un programme qu'il n'avait pas développé pour configurer le système. Red Hat n'était pas le seul à utilise ce programme (j'ai oublié son nom). Au final Red Hat a trouvé que ça sucks (et je suis d'accord).
Donc Red Hat a considéré les outils de configuration comme "statégiques".
C'est important car (par ordre d'importance à mes yeux) :
1- c'est très utilisé
2- ça dépend beaucoup de la distribution
3- ça fait parti de la signature de la distribution
Le 2 est important. Par exemple la configuration (du moins le paramétrage de la configuration; pas la configuration fine) sous Fedora est principalement stockée dans /etc/sysconfig et est quasi totalement dépendant de la distribution. Debian n'a pas de /etc/sysconfig, SuSE a un /etc/sysconfig mais l'utilise de façon très différente de Fedora (Fedora n'y met que de grosses options). Etc...
Si par exemple Fedora ajoute ipv8 pour la Fedora 20, il faut que les outils de configuration supportent ipv8. Si le distributeur ne développe pas les outils de configuration, c'est compliqué ou trop long (discussion avec l'équipe en upstream).
Concernant Red Hat/Fedora, il y a aussi un aspect qu'on ne peut négliger. Red Hat a beaucoup de développeur. L'activité développement des outils system-config-* leur prend très peu de ressource pour eux.
"Culturellement", Red Hat ne fait pas de distribution pour les "petites filles" mais principalement les administrateurs/développeurs voire station de travail. Si pour formater un disque dure il faut taper une ligne commande, ben il faut taper une commande. On va pas développer une interface graphique pour un truc qu'on fait tous les 36 du mois.
[^] # Re: Qu'est-ce que tu veux
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
Ah bon...
> pourquoi ne l'ont-ils pas fait ?
Car urpmi n'a pas été proposé contrairement à apt, yum et smart (qu'on a trouvé très tôt dans Fedora Extras, avant la sortie de FC1). Je crois que j'ai vue qu'une seule proposition en faveur de urpmi ! Yum a été retenu. NB : Yum n'est pas un projet Red Hat. Il a été fait pour Yellow Dog au début.
Car urpmi est compliqué. "urpmi.update -a ; urpmi -autoselect" (ou un truc approchant) pour faire un "yum update".
Car urpmi est écrit en perl. Red Hat a fait de python son "standard", tous les outils Red Hat sont en python.
Car urpmi ...
Je ne vois pas pourquoi tu t'en prends à Red Hat alors que personne reprend les outils Mandriva.
En dehors du support des périphériques amovibles, que propose urpmi que n'a pas yum (ou pirut) ?
# Re:
Posté par IsNotGood . En réponse au journal A propos des draketools. Évalué à 3.
Connaissent-ils autre chose ?
Je connais vaguement les drake* pour avoir testé épisodiquement Mandr(ake|iva), j'en n'ai pas un souvenir "fabuleux".
> je me demandais si l'intégration de ces outils dans d'autres distrib' ne serait pas une bonne idée.
Pourquoi pas.
M'enfin chez Fedora c'est "plein" :
http://fedoraproject.org/wiki/SystemConfig/Tools
Désolé, je n'ai pas de copie d'écran sous le coude.
[^] # Re: Time Machine?
Posté par IsNotGood . En réponse au journal Journalisation de fichier. Évalué à 2.
[^] # Re: ZFS
Posté par IsNotGood . En réponse au journal Journalisation de fichier. Évalué à 2.
Sauf qu'en plus t'as des vrais quotas et pas un "not enought disk space".
[^] # Re: rdiff-backup
Posté par IsNotGood . En réponse au journal Journalisation de fichier. Évalué à 2.
Tous les sgdb qui font des transactions ont toujours un état cohérent sur le disque. C'est définitivement le cas pour PostgreSQL. Après d'une coupure de courant ou d'un freeze système, le sgdb ignore (nettoye) simplement les transactions en cours (tout ce qui n'a pas été validé par le retour de "commit", un retour d'instruction type "insert into ..."). Et il ne va surtout pas les refaires puisqu'elles sont imcompletes !
Notes que c'est indispensable, sinon la base de donnée ne pourait pas redémarrer dans un état cohérent après une bête coupure de courrant.
> Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot.
Certe, mais ce n'est pas nécessaire avec un "vrai" snapshot.
Ton snapshot c'est l'état de ta bd comme si le moteur de base de donnée recevait un "kill -9". Or les sgbd doivent supporter un "kill -9" (ou une coupure de courant).
> Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point.
C'est cohérent, point.
> Là ça passe par un agent intermédiare.
Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).
Autre chose, quand on parle de "rejouer un journal", on ne rejoue que les transactions validées (celles avec un commit/etc qui a aboutis ET qui est indiqué comme telle dans le journal).
> Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir.
Postgresql le fait aussi :-)
Ça été introduit dans PostgreSQL 8.0 je crois.
[^] # FA-BU-LEUX
Posté par IsNotGood . En réponse au journal Ms ce sont des rigolos. Évalué à 8.
C'est page 124-125.
J'avais dit que l'API de Windows sucks, on sait pourquoi.
[^] # Re: protocoles inconnus ?
Posté par IsNotGood . En réponse au journal Ms ce sont des rigolos. Évalué à 3.
Deux choses :
- L'europe a produit un fabuleux travail pour "démasquer" les embrouilles de MS.
- MS n'a aucune limite pour se foutre du monde. C'est un voyou.
[^] # Re: protocoles inconnus ?
Posté par IsNotGood . En réponse au journal Ms ce sont des rigolos. Évalué à 3.
[^] # Re: protocoles inconnus ?
Posté par IsNotGood . En réponse au journal Ms ce sont des rigolos. Évalué à 4.
Mais il faut lire un bon paquet de page pour arriver sur du concrêt (aviron vers la page 50).