Au menu de cette nouvelle mouture, on peut citer le prise en charge complète de l'Asus EEE PC, la possibilité de synchroniser les logiciels d'agenda avec la plupart des PDA (incluant Windows Mobile 5 et supérieur, ainsi que les Blackberry et les téléphones Nokia). Elle inclut également un gestionnaire de codecs pour les applications multimédias (Codeina). KDE y est en version 3.5.9 et la version 4.0.3 est disponible sur les miroirs officiels. GNOME quant à lui est en version 2.22. Enfin, on y retrouvera également OpenOffice.org en version 2.4, le noyau Linux 2.6.24.4, X.org 7.3, Compiz 0.7, et bien d'autres !
Si l'installation vous fait peur, la version One (sur un live-CD) est également disponible (une version spéciale KDE ou une version GNOME, au choix, sont disponibles). L'installation des outils de synchronisation pour les PDA se fait grâce aux méta-paquets task- installant les logiciels préférés pour GNOME ou KDE et notamment le framework OpenSync permettant la synchronisation par SyncML :
- Nokia : task-nokiasync-gnome (greffon opensync pour evolution, multisync-gui), task-nokiasync-kde (kitchen-sync, kdepim) et ajouter la bibliothèque Gnokii
- WM5/6 : task-wm5sync-gnome (greffon evolution, multisync-gui), task-wm5sync-kde (kitchen-sync, kdepim) pour ajouter synce-kpm
- Smartphones BlackBerry : task-blackberry-gnome task-blackberry-kde
- task-lamp-perl
- task-lamp-php
- task-lamp-python
Pour le téléchargement, afin d'éviter d'écrouler plus les serveurs FTP, vous pouvez utiliser bittorrent (sélectionnez la version qui vous convient, contenant Spring bien sûr).
La documentation de prise en main de Mandriva Linux est disponible dans les paquets mandriva-doc et aussi directement téléchargeable au format PDF ; le wiki est à la disposition de tous sous licence libre CC-by-sa et documente par exemple le centre de contrôle Mandriva Linux (aka MCC ou CCM) qui permet de disposer d'assistants pour une configuration facilitée et avancée de votre système.
Enfin, pensez à prendre 5 minutes pour signaler votre configuration sur Hardware4Linux en installant hwreport (inclus sur les dépôts), cela servira à d'autres pour sélectionner du matériel qui fonctionne ; via le centre de contrôle vous pouvez aussi directement soumettre les données dans la liste de compatibilité matérielle de Mandriva.
Aller plus loin
- L'annonce de la sortie de la 2008.1 Spring (9 clics)
- La page sur le wiki de mandriva pour la 2008.1 (8 clics)
- Le test de la RC2 (1 clic)
- Mandriva Linux 2008.1 en images (10 clics)
# UPNP & Coherence
Posté par RO1 . Évalué à 10.
On peut également utilisé elisa comme client sur une autre machine linux ce qui permet de partager simplement musique, video, photos entre 2 machines Linux.
[^] # Re: UPNP & Coherence
Posté par littlebreizhman . Évalué à 3.
Pour ma part j'utilise mediatomb comme serveur uPnP. Il a une interface web pour ajouter/enlever le contenu après une config de base avec un bon vieil éditeur.
Pour coherence, que je n'ai jamais testé, il y a t il également une interface qui le fait fonctionner une fois le rpm installé ou faut il quand même mettre le nez dans les fichiers de conf ?
Sinon, pour utiliser cette version de Mandriva en cooker 64 bits, c'est vraiment une très bonne release je trouve.
[^] # Re: UPNP & Coherence
Posté par RO1 . Évalué à 6.
Tu as ensuite la possibilité d'utiliser une applet python-coherence-applet qui a été développée par un contributeur Mandriva (merci neoclust) et intégrée upstream dans cette version 0.5.4.
Une fois que l'applet est installée, tu peux l'ajouter dans ta zone de notification (via le menu internet/coherence)
Après, depuis l'applet, tu peux démarrer/stopper coherence qui fonctionne alors sans aucune configuration ! C'est vraiement pratique. Il va partager automatiquement tes répertoires XDG aka photos/video/musique.
Bref, l'applet te permet d'avoir un partage UPNP sans aucune configuration ni base de données etc... Un vrai progrès pour l'utilisateur.
[^] # Re: UPNP & Coherence
Posté par littlebreizhman . Évalué à 3.
Par contre, je me pose de fait une autre question...
Quand tu dis répertoires XDG, tu parles de ce concept http://standards.freedesktop.org/basedir-spec/basedir-spec-0(...) ?
Si j'ai bien compris, les dossiers sont donc définis préalablement dans une variable d'environnement standard et coherence sait s'en servir pour trouver les fichiers à partager.
Si j'ai tout faux : comment sont définis ces répertoires XDG ?
[^] # Re: UPNP & Coherence
Posté par RO1 . Évalué à 1.
Normalement, tout ça c'est déjà bien configurer.
N'hesites pas faire des retours sur ton expérience, et viens sur #mandrivafr (sur freenode) si tu veux en discuter.
[^] # Re: UPNP & Coherence
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 1.
ou bien même GeeXboX ...
# dommage
Posté par Jeanuel (site web personnel) . Évalué à -10.
Dommage aussi qu'il faille payer pour disposer de la version complète et des forums.
Dommage enfin qu'elle soient si laide et mal configuré et que les outils de configuration, qui sont propriétaires, soient aussi instables et envahissants.
De toute façon, c'est la plus mauvaise distrib que je connaisse. La dernière fois que j'ai essayé de l'installer, elle m'a grillé 2 disques dur et un lecteur DVD. Sans compter que j'ai chopé un lumbago.
Les dev feraient bien de se remettre au travail et de s'inspirer d'une vraie distrib comme Ubuntu !
[^] # Re: dommage
Posté par vincent_k (site web personnel) . Évalué à -4.
[^] # Re: dommage
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 7.
[^] # Re: dommage
Posté par Stéphane Davy . Évalué à 7.
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 2.
Et il ne se porte pas si mal que ça tout de même.
[^] # Re: dommage
Posté par FantastIX . Évalué à 4.
Respects :-) .
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à -1.
Si tu avançais des arguments de critiques gratuites ?
[^] # Re: dommage
Posté par Maclag . Évalué à 7.
On avait pas dit qu'on trollait sur le journal de sa sortie, et qu'on gardait les commentaires pertinents sur la dépêche?
Surtout qu'on n'est pas vendredi!
Du coup je sais plus où poster, moi!
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 1.
Ben oui :-)
[^] # C'est pour la télé ?
Posté par Kerro . Évalué à 0.
[^] # Re: C'est pour la télé ?
Posté par lolop (site web personnel) . Évalué à 2.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: dommage
Posté par goom . Évalué à 10.
La gestion des rpm à travers rpmdrake est largement satisfaisante pour moi. Rpmdrake n'a cessé de progresser depuis plusieurs versions aussi bien en ergonomie qu'en rapidité. Quant au débat entre .deb et .rpm je dois avouer ma totale incompétence d'une part n'étant pas développeur et d'autre part n'utilisant pas de distribution à base de .deb pour pouvoir comparer objectivement sur la facilité d'emploi.
Le forum officiel est totalement gratuit depuis pas mal de temps, l'inscription est gratuite et tout le monde peut intervenir librement, y compris pour critiquer Mandriva, la distribution, la société.
Les outils de configuration sont sous licence GPL, stable de mon point de vue et utilisable aussi bien avec que sans interface graphique (ce qui est très pratique pour remettre d'aplomb la configuration du serveur X avec XFdrake sans avoir besoin de bidouiller un fichier de configuration dans la console). L'aspect visuel est du goût de chacun, certains apprécient le bleu, d'autres le vert ou le marron.
Elle mérite le coup d'œil et de mon point de vue elle rend l'utilisation de Linux très facile et permet de se passer de toute ligne de commande pour se faire oublier et se consacrer à l'utilisation de son ordinateur et non à la maintenance de son système d'exploitation.
Maintenant on peut débattre ou troller sur des bases sérieuses ;)
[^] # Re: dommage
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
Mais et le lumbago ? hein ? hein ?
Il n'est toujours pas prouvé que mandriva n'est pas responsable des lumbagos ;)
[^] # Re: dommage
Posté par Janfi . Évalué à 3.
[^] # Re: dommage
Posté par Uvoguine . Évalué à 6.
[^] # Re: dommage
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à -2.
Je ne suis pas non plus un adepte du gestionnaire de paquets RPM, lui préférant APT que je trouve plus souple et plus pratique. Mais loin de moi l'idée de lancer le débat.
Je profite de ce point pour m'informer su le projet Autopackage http://autopackage.org.
Qu'en est il de son intégration dans les différentes distributions ? et surtout de son usage chez les différents mainteneurs de paquet ... ?
Certaines personnes auraient de l'info ? Je sais que ce n'est pas vraiment le lieu m'enfin, vous pourriez m'accorder quelques liens et avis ... :D
Alexandre COLLIGNON
[^] # Re: dommage
Posté par GeneralZod . Évalué à 9.
Déjà première erreur, l'équivalent de RPM ce n'est pas APT mais dpkg.
RPM et dpkg sont des système de gestion de paquets, yum/urpmi et apt-get/aptitude sont des systèmes avancés de gestion de paquets qui se basent respectivement sur les systèmes précédemment cités.
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.
[^] # Re: dommage
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 3.
Merci pour la correction, c'est une erreur grossière.
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Je ne vais pas donner mon avis ici, on va dire que je troll. :D
Alexandre COLLIGNON
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Mouaif...
rpm/apt est bas-niveau. Ils connaissent le format des paquets (à quel offset est stocké telle ou telle information, etc), il fait tous les contrôles en toute fin, il lance les scripts d'installations, contrôle les conflits entre fichiers, c'est rpm qui fait la vérification de signature, etc.
Il y a largement plus de code pour rpm que pour yum.
Yum (ou autre) est "seulement" un utilisateur de rpm (ou librpm). Il n'est pas plus avancé que rpm. Il fait des choses que ne fait pas rpm. Des choses qui ne sont pas nécessaire pour l'outil de bas niveau. Par exemple downloader les paquets, ajouter automatiquement un paquet s'il y a une dépendance, etc.
En passant, rpm avait la gestion automatique de dépendance. Ça utilisait rpmdb (qui n'est plus fournit). La fonctionnalité, si elle existe encore, n'est pas supportée.
[^] # Re: dommage
Posté par Stéphane Davy . Évalué à 2.
tu aurais du mettre cela dans le journal spécial troll
[^] # Re: dommage
Posté par IsNotGood . Évalué à 7.
A part la réputation de deb, il y a quoi de formidable dans deb ?
Deb vient d'avoir les trigger alors que ça existe depuis des lustres sous rpm. En passant, c'est spécifique Ubuntu. Rpm supporte les systèmes bi-arch (i386/x86_64). Rpm a la signature (GPG) des paquets depuis des lustes alors que dpkg depuis quelques mois.
Il y a un truc qu'a deb et non rpm, c'est les suggestions.
> tu aurais du mettre cela dans le journal spécial troll
Fait un journal qui démontre la supériorité de deb sur rpm.
Fait de même pour apt et yum si tu veux.
[^] # Re: dommage
Posté par zeb . Évalué à 3.
[^] # Re: dommage
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
- rpm gère les paquets, mais pas leurs dépendances.
- urpmi est une surcouche à rpm qui gère les dépendances.
- rpmdrake est une surcouche graphique à urpmi
Ce schéma est volontairement simplifié. Le comprendre devrait permettre d'éviter de dire des bêtises.
Il y a aussi l'applet "Mandrake On line" qui 'appuie sur urpmi et permet de mettre la distribution à jour d'un seul clic !
En ligne de commande
urpmi.update -a && urpmi --auto-selectfait la même chose.La gestion de paquets de Mandriva n'a rien à envier aux autres distributions, bien au contraire !
[^] # Re: dommage
Posté par Infernal Quack (site web personnel) . Évalué à 5.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: dommage
Posté par IsNotGood . Évalué à 5.
rpm gère les dépendances !
Ce que ne fait pas rpm, c'est les résoudre automatiquement.
[^] # Re: dommage
Posté par vincent_k (site web personnel) . Évalué à -1.
Faut pas chercher loin
[^] # Re: dommage
Posté par genesis83 . Évalué à 6.
Faux, rpm gère les suggestions : Suggests: dans les fichiers spec
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
Car je crois que Jeff Johnson avait proposé ça assez tard (année 2007) et que rpm (rpm.org) l'a refusé. Par contre rpm de Jeff Johnson (rpm5.org) l'a peut-être.
Il me semble que conectiva était contre et Fedora est contre aussi. En passant, Fedora a les groupes (fichier comps.xml) depuis des lustes. Ce qui limite l'intérêt des suggestions.
Les groupes sont gérés par yum (et ses fils graphiques).
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
[^] # Re: dommage
Posté par genesis83 . Évalué à 7.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
[^] # Re: dommage
Posté par genesis83 . Évalué à 1.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Ne soit pas débile.
> certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
Es-ce que Firefox nécessite adobe-flash ?
Non.
Chaqu'un est libre de violer rpm. Des cons il y en aura toujours.
[^] # Re: dommage
Posté par dguihal . Évalué à 3.
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Et alors je ne vois pas le problème, si mandriva dans son paquet firefox veut y inclure une dépendance molle vers flash, je ne vois pas en quoi ça impacte Suse/Fedora/... Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Il n'est pas politique.
> Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.
Oui. Mais un rpm n'est pas forcément fait pour et par une distribution. Certains rpms (lsb compatible) peuvent être installer partout.
Et si je veux l'installer, je ne veux pas qu'il me sugère flash d'adobe. Le boulot de rpm, c'est (entre autre) l'installation des programmes. Pas un truc pour faire de la pub à flash d'adobe.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
L'horreur...
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Je ne vois pas le rapport.
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
[^] # Re: dommage
Posté par Jérôme Benoit . Évalué à 0.
Small is beautiful, guys.
Le graphe de dépendances et de suggestions ne doit pas être gérer au niveau du logiciel de paquet, c'est de l'over engineering d'un logiciel çà.
a +.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Au chargement du module nv, il pourrait y avoir un message dans /var/log/message qui suggère le driver proprio.
Je suis contre ce principe.
Après du pourrait avoir Firefox qui suggère Gnome s'il ne trouve pas Gnome, etc.
C'est la (mauvaise) idée globale qu'il faut voir ici. Pas le côté technique.
[^] # Re: dommage
Posté par dguihal . Évalué à 4.
Pour tu donner un contre exemple, je te donnerai l'exemple du paquet task-kde sous la mandriva (2008.1 précisement)
si je veux installer le task-kde celui-ci me tire via un jeu de dépendance dures :
Kerry -> Beagle -> Mono -> ...
super !!!! Je voulais KDE et je me retrouve avec ce gros bloatware de mono. Alors qu'il aurait juste fallu avoir mis Kerry en suggest et hop ! Je peux garder mon task-kde (qui me facilite l'install de kde) sans avoir (trop) de cochonneries (Brevets / techno microsoft / MDI) d'installées sur ma machine
[^] # Re: dommage
Posté par GeneralZod . Évalué à 2.
L'avantage est que c'est plus souple à maintenir, je ne change qu'un fichier xml et non pas un fichier spec qui signifie recompilation du paquet, mise à jour inutile pour 99% des utilisateurs etc ..., si tu dois faire ça assez souvent, ça devient vite lourdingue. Les concepteurs de RPM ont fait choix, celui de laisser la gestion des groupes à l'outil de haut niveau.
Si tu veux un mécanisme de suggestions, il faut l'implémenter dans urpmi et non pas dans RPM.
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
Ce n'est pas un faux problème.
Pour Fedora il y a :
- Fedora (full, avec evolution par défaut, etc)
- Fedora KDE (avec kmail par défaut, etc)
- Fedora Games
- Fedora Developers
- Fedora Electronic Lab
- Fedora XFCE
Il y a en peut-être d'autres. Toutes ses distributions utilisent les mêmes paquets rpm. On n'a pas à recompiler 6 (!) fois le même paquets. Gain de temps et d'espace disque (ose imaginer le cas de OOo).
> donc c'est un faux probleme
La place disque (sur les mirroirs) commence a être un sérieux problème.
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
Ton OOo il est dans un repository commun a toutes tes versions de Fedora, et eventuellement dans ton Fedora KDE tu y colles un paquet qui permet de KDEiser son interface pour qu'elle s'integre mieux dans KDE.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Mais vois comme cette "mauvaise" idée a rapidement des répercutions.
Es-ce que rpm doit encourager ce type de truc ?
Je ne crois pas.
Ceci dit, je pense avoir bien compris ton avis et que tu as bien compris le mien.
Donc j'arrête.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
On peut voir que yum c'est étoffé avec des informations qui n'ont pas leur place dans rpm. Par exemple des informations qui indiquent si le paquet est un correctif de sécurité (pertinant pour une mise à jour, mais sans intérêt pour une nouvelle release). Cette informations est par rapport à l'ancien paquet et donc implique un "workflow" dont rpm est totalement étrangé. Donc cette information, aussi utile soit-elle, n'a pas à être dans rpm.
Ce n'est pas car une information est utile, qu'il faut la foutre n'importe où.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Je dis ça, c'est une news Mandriva, je vais me faire exploser et accuser d'insulter les développeurs, de chier sur ... etc...
Bref, je n'irais pas plus loins sauf pour dire qu'il y a des alternatives à ces meta-paquets.
[^] # Re: dommage
Posté par bubar🦥 (Mastodon) . Évalué à 2.
gnome / f-spot / mono > /dev/null
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
Tu prends le mauvais exemple d'une dépendance vers un lib proprio, alors qu'il pourrait y avoir des dizaines d'exemple concernant du pur libre (entre autres dans le multimedia).
Un package est toujours créé pour une version de distribution a cause des dépendances dures concernant des versions de bibliothèques par exemple, donc le fichier SPEC n'est pas écrit pour lsb mais pour une version précise de distribution, tout en tenant compte des recommandations lsb qui portent surtout sur des emplacements de fichier autant que je le sache.
Si le paquet rpm de mandriva qui tu voulais installer sur ta fedora te fais des suggestions qui te de plaisent, tu peux toujours :
- prendre un autre paquet : Suse / CentOS / ... en proposent ( Fedora aussi ;-) )
- refaire le paquet en virant le suggest a partir du src.rpm
- ignorer le suggest
Je trouve que c'est un choix plus que raisonnable.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Je dis seulement que ça ne doit pas être fait au niveau de rpm (qui est le plus bas niveau).
Fedora a des "dépendances molles", c'est traitée avec le fichier comps.xml. C'est dans ce fichier qu'on trouvera les décisions "politiques". Pas au plus bas niveau.
Le fichier comps.xml est au niveau de la distribution (et techniquement rien n'empêche de l'utiliser avec des .deb ou autre).
Au plus bas niveau on doit avoir le minimum de dépendance et ne pas faire de suggestion. Ça améliore la réutilisation.
> donc le fichier SPEC n'est pas écrit pour lsb
Ben parfois oui. Parfois il est fait pour plusieurs distributions.
Un exemple récent :
http://developer.amazonwebservices.com/connect/entry.jspa?ex(...)
Ce n'est pas fait spécifiquement pour une distribution.
Et après, que fais tu des suggestions ?
Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
Et après, que fais tu des suggestions ?
Simple, si elle ne sont pas disponibles, tu ne le propose même pas.
Sinon tu propose (après entre le opt-in et le opt-out ça c'est effectivement purement politique)
Le problème du comps.xml (que je ne connais pas vraiment) c'est que c'est géré au niveau de yum non ? Dans ce cas quid des autres distrib qui n'utilisent pas yum ? Elle est où la compatibilité inter distribution ?
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
Elle n'existe pas, c'est quasi intentionnel.
Ainsi tu peux avoir une distribution avec le bureau par Gnome défaut, une autre avec KDE, une autre avec evolution par défaut, une autre avec thunderbird, une autre qui installe tout Gnome et une autre qui installe que le minimum pour Gnome, etc.
comps.xml est spécifique à la distribution.
Par contre rpm ne l'est pas.
Les suggestions sont spécifiques à une distribution (à sa politique/philosophie), donc ils ne devraient pas être au niveau de rpm. Rpm s'occupe que de questions techniques.
[^] # Re: dommage
Posté par dguihal . Évalué à 2.
Je te rappelle que je ne plaide pour avoir l'obligation mais la possiblité d'utiliser le suggest, c'est tout à fait optionnel.
Libre après à chaque mainteneur de paquetage/distribution de l'utiliser selon ses goûts et ses envies.
Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm, c'est sa présence ou non et les dépendances qui s'y trouvent (autrement dit la manière de l'utiliser) qui est propre à une distribution.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.
Après tu peux ajouter les résolutions automatiques (et optionnels) des dépendances, le choix du mirroir à utiliser (optionnel), l'interface graphique (optionnelle), etc.
Ce principe moux va à la catastrophe ou du moins est la voix royale au n'importe quoi.
Après le suggest, il y aura le suggested-doc (ça ne fait pas de mal, c'est optionnel), le suggested-skin (ça ne fait pas de mal, c'est optionnel), le suggested-ram (ça ne fait pas de mal, c'est optionnel), etc.
Ceci sucks dans les grandes largeurs.
Tu aimes ça, je n'aime pas ça, on ne sera pas d'accord.
> Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm
Ben il n'y est pas.
Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).
[^] # Re: dommage
Posté par CrEv (site web personnel) . Évalué à 2.
Mais non justement ça n'a rien à voir.
D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute), gnome a des options.
Seulement elles ne sont pas toutes visibles et pour certaines on ne peu y accéder que par gconf.
Mais les options sont là.
Ben là c'est pareil, rpm gère les requires, devrait gérer à mon sens les suggest (qui ne sont qu'une forme de dépendance, optionnel mais dépendance)
Et comme actuellement, c'est aux sur couches (urpmi, yum, ...) d'installer, proposer, etc, tenir compte de suggest ou non. Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.
Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...
Finalement je crois que je comprend pourquoi il y a un fork de rpm...
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Bien vu.
Mais c'était une connerie de ma part.
Rpm a des objectifs (que) technique. Ce n'est pas le cas de Gnome.
> une forme de dépendance, optionnel mais dépendance
Une dépendance optionnelle n'est pas une dépendance.
Quand penses-tu ?
> Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.
Je ne peux pas parler pour Mandriva, mais pour Fedora ce n'est pas fait comme ça.
J'ai Gnome comme bureau, je peux (et d'ailleurs je le fais) virer Nautilus. Le bureau Gnome ne dépend pas de Nautilus (mais Nautilus dépend de Gnome).
Et je "maudirais" rpm si un jour il me suggère d'installer Nautilus.
PS: ce n'est pas une critique de Nautilus, je n'utilise pas les gestionnaires de fichier graphique.
> Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...
Je répète pour au moins la quatrième fois, je ne suis pas contre le concèpte de suggérer un autre paquet, mais je suis contre de le faire dans rpm.
A une époque Fedora "suggérait" epiphany comme navigateur. Puis ça été Firefox. Ben Fedora n'a pas besoin de recompiler les paquets pour ça. Comme ce n'est pas dans rpm, Fedora n'a pas un compiler des paquets pour Fedora saveur Gnome et Fedora saveur KDE et Fedora saveur developers, etc.
Je répète encore, je ne suis pas contre le concèpte de suggérer un autre paquet. Fedora, les faits le montre, n'y est pas contre non plus. Mais ça ne doit pas être fait dans rpm.
[^] # Re: dommage
Posté par CrEv (site web personnel) . Évalué à 3.
> Quand penses-tu ?
je dirais qu'on est vendredi aujourd'hui... ;-)
mais oui, une dépendance peut être optionnelle, je ne vois pas le problème.
Par exemple, sous kdesvn, par défaut il me fait le diff avec un outil kde "basique".
Si j'installe kompare, il va l'utiliser pour représenter les diffs.
Initialement kdesvn n'en avait pas besoin. Néanmoins, kdesvn permet de l'utiliser si celui-ci existe. Il y a bien une dépendance entre les deux, mais non obligatoire.
Maintenant, avec un système sans suggestions, si le packager ne veut pas de kompare (ce qui semble correct car non nécessaire) alors l'installation de kdesvn ne me permettra pas de voir mes diffs avec. Si le packager veut lui utiliser kompare, alors il me force à l'installer et peut-être je ne le voulais pas.
Il suffit alors que kdesvn viennent avec une dépendance optionnelle (je parlais bien de dépendance au sens require de rpm) et lorsque je vais l'installer il me dira que le soft marche sans kompare mais que si je veux il me propose de l'installer car kdesvn l'utilisera alors.
Faire ceci en dehors de rpm est illogique. Les dépendances sont dans les .spec et à mon avis, dépendances et suggestions doivent être au même niveau .
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Je viens de regarder, les suggest ont été ajoutés au format rpm.
Mais rpm (de rpm.org) n'en fait rien.
[^] # Re: dommage
Posté par Anonyme . Évalué à 4.
Si si, ca existe, et c'est utilisé sur certains packages sur Mandriva.
$ rpm --help
[...]
--suggests list capabilities this package suggests
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Comme je l'ai dit ailleurs, les champs SUGGESTSNAME, etc on été ajouté au format rpm (donc c'est upstream).
[^] # Re: dommage
Posté par Anonyme . Évalué à 3.
Les Suggests ne sont pas plus des décisions politiques que les Requires ...
> Ben parfois oui. Parfois il est fait pour plusieurs distributions.
Peu etre que tu n'es pas au courant, mais ce n'est pas par ce que la fonctionnalité est disponible qu'il est obligatoire de l'utiliser tout le temps. Tu peux très bien ne pas l'utiliser quand tu fais des packages destinés à plusieurs distributions, ou bien prevoir que ces Suggests seront ignorés sur certaines.
> Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.
urpmi l'utilise.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Foutaise.
S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.
> urpmi l'utilise.
Mais ce sont des infos qui viennent de rpm ou d'ailleurs ?
[^] # Re: dommage
Posté par wismerhill . Évalué à 2.
Même chose avec les suggest, si on les installe ça marche mieux, il y a plus de fonctionnalités puisque des composants non essentiels sont alors disponibles. C'est aussi un constat technique.
Par exemple: k3b fait usage de cdrecord/wodim, cdrdao et growisofs, mais il peut se passer de tous (on peut utiliser k3b pour faire de l'extraction de cd audio par exemple). Donc à ce niveau-là, utiliser le suggest pour indiquer que k3b permettra de faire plus de choses avec ces programmes est utile, et c'est bien au niveau du paquet que cette information est intéressante, parce qu'elle est vraie qu'elle que soit la distribution.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 1.
C'est ça. Firefox marche mieux avec Flash....
N'importe quoi.
[^] # Re: dommage
Posté par wismerhill . Évalué à 5.
Tu as inventé toi-même cet exemple et depuis tu passe ton temps à le sortir comme sois-disant preuve que le champ suggest est mauvais alors que nous somme plusieurs à te répéter que l'utilisation souhaitée d'un champ suggest n'est pas celle-là.
Pour te paraphraser, ce n'est pas parce que tu (avec ton exemple) viole l'usage prévu pour le champ suggest qu'il est mauvais.
[^] # Re: dommage
Posté par Zorro (site web personnel) . Évalué à 4.
Si suggest est utilisé strictement pour indiquer des trucs de sécurité ou des trucs vraiment indispensable, pourquoi pas ? Mais qui va juger de ce qui est indispensable ou pas ? Par définition, suggest sous-entend un choix de l'auteur du paquet.
En même temps, suggest a bien sa place quand les paqueteurs ont acquis notre confiance, qu'on les connaît, et qu'on connaît l'esprit de la distro pour laquelle ils travaillent. Par exemple, j'ai tendance à faire confiance à Mandriva dans les paquets et l'équipement du bureau qu'ils me suggèrent d'installer... Et ça ne me dérangerait pas qu'ils me suggèrent le paquet Flash avec FF, moi.
Mais pour la dérive de suggest, on pourrait presque imaginer que la dérive ultime serait de faire de suggest une distribution à lui tout seul... Après tout, une distribution Linux, c'est l'installation du noyau, avec plein de suggest autour ! :-)
Je pense que suggest aura naturellement tendance à susciter la polémique et la dérive.
[^] # Re: dommage
Posté par CrEv (site web personnel) . Évalué à 3.
La confiance il faut déjà l'avoir, car bon suggest peut ptetre ajouter certaines choses (mais toujours optionelles) mais si le packageur est mauvais, il peut aussier ajouter de requires qu'on ne veut pas... et là c'est pire car on a pas le choix.
Donc ne pas vouloir suggest pour ceci, autant supprimer les dépendances...
Ce que je ne comprend pas c'est l'animosité que suggest provoque, si certains ne veulent pas de suggest ils n'ont qu'à pas installer ce qui est suggéré et leur distrib se comportera comme sans. Et ceux qui veulent profiter des améliorations le pouront.
[^] # Re: dommage
Posté par GeneralZod . Évalué à 2.
RPM se veut un outil bas-niveau dans l'esprit Unix, il fait une chose et il le fait bien. Après, c'est à l'outil de plus haut niveau de proposer des fonctionnalités plus avancés comme les suggestions.
Pourquoi s'amuser à complexifier RPM alors qu'il l'est suffisamment si ce n'est déjà trop ?
Hein, Fedora offre les groupes (géré par le fichier comps.xml), OpenSuSE offre également des "recommendations" et des "suggestions" via son One-Click Install. (http://en.opensuse.org/Build_Service/Tutorial)
Rien n'empêche Mandriva d'implémenter dans son urpmi ce mécanisme, rien ne les empêche de discuter avec les autres distributions à base de RPM d'implémenter un mécanisme commun sans forcément le foutre dans RPM.
[^] # Re: dommage
Posté par CrEv (site web personnel) . Évalué à 3.
rpm intègre déjà les requires. Les suggest ne sont que des dépendances optionnelles et sont justement au même niveau.
Franchement je ne vois pas pourquoi il y aurait une différence entre les 2.
Maintenant, oui, tout comme ce sont les front-end qui gèrent l'installation des dépendances, ces front-end peuvent traiter (ou non) les suggests à leurs niveaux.
Mais là ou ce serait vraiment intéressant c'est qu'il y aurait une (et une seule) façon d'indiquer les suggest pour tous les paquets rpms.
Le suggest fait partie du paquet et non de l'outil de gestion du paquet ou d'installation.
[^] # Re: dommage
Posté par TeXitoi (site web personnel) . Évalué à 3.
Hein ?
$ sudo apt-get install p7zip-fullLecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Paquets suggérés :
p7zip-rar
Les NOUVEAUX paquets suivants seront installés :
p7zip-full
0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 0o/1189ko dans les archives.
Après cette opération, 2931ko d'espace disque supplémentaires seront utilisés.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 2.
Et pour synaptique ?
Es-ce que par exemple on peut avoir la liste des suggestions actuelles qui ne sont pas installées ?
[^] # Re: dommage
Posté par Julien . Évalué à 2.
La réponse courte : oui aptitude le permet
La réponse moyenne :
aptitude search '?not(?installed)?reverse-suggests(?installed)'
ou
aptitude search '!~i~R[suggest]~i'
La réponse plus longue :
http://algebraicthunk.net/~dburrows/projects/aptitude/doc/fr(...)
[^] # Re: dommage
Posté par Anonyme . Évalué à 3.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
Vous êtes con ou quoi ?
Un require c'est ce qui est nécessaire pour que ça marche. Ce n'est pas optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, c'est nécesssaire.
Il y a peut-être des distributions qui ne respectent pas la signification de require, mais c'est leurs oignons. En tout cas Fedora respecte la signification de require. Si un require n'est pas nécessaire pour le bon fonctionnement du logiciel, ben fait un rapport de bug. Tu vas voir, le require sera supprimé.
Il y a même une chasse quasi permanente aux requires superflux.
[^] # Re: dommage
Posté par Julien . Évalué à 3.
Il y a peut-être des distributions qui ne respectent pas la signification de suggest, mais c'est leurs oignons. En tout cas MaDistrib respecte la signification de suggest. Si un suggest ne représente pas une fonctionalité supplémentaire qui peut être ajoutée au logiciel, ben fait un rapport de bug. Tu vas voir, le suggest sera supprimé.
Il y a même une chasse quasi permanente aux suggest superflux.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 0.
Par définition, ce qui n'est pas nécessaire n'est pas requis. Donc ne mélangeons pas les Requires et les Suggests.
> Il y a même une chasse quasi permanente aux suggest superflux.
Suggest qui est un choix "politique".
[^] # Re: dommage
Posté par Anonyme . Évalué à 4.
rpm le fait aussi maintenant.
[^] # Re: dommage
Posté par vrm (site web personnel) . Évalué à 4.
- la rapidité de apt/dpkg à coté de yum et autres,
- la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.
Sinon ca joue pas énormément sur la qualité de la distro, ce qui fait la différence entre deux c'est surtout la qualité des packages, plutot que le système de package en lui même.
[^] # Re: dommage
Posté par daemontux . Évalué à 2.
C'est vrai que yum est lent, c'est le seul défaut que je reproche à fedora. Par contre, je pense qu'urpmi est assez rapide (même si je l'ai peu utilisé).
[^] # Re: dommage
Posté par liberforce (site web personnel) . Évalué à 3.
Ça fait 4 ans que j'utilise urpmi, depuis la Mandrake 9.1, j'ai jamais ressenti la même lourdeur, il a toujours été assez rapide.
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
Faut pas pousser.
Quelques exemples :
J'ai des mises à jour en attente en attentes :
# time yum update
[...]
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 20 Package(s)
Remove 0 Package(s)
Total download size: 29 M
[...]
real 0m53.804s
user 0m12.287s
sys 0m3.598s
Moins d'une minute pour 29 Mo (compressé).
Voici un autre petit test avec une installation mini (machine virtuelle kvm).
time yum install openoffice.org-writer
[...]
Transaction Summary
=============================================================================
Install 125 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 157 M
[...]
real 1m52.924s
user 0m23.623s
sys 0m19.857s
Moins de 2 minutes pour 157 Mo (compressé)
> j'avais le temps d'aller faire une belote pour installer un package...
Tu fais un belote en 1 minute ?
[^] # Re: dommage
Posté par IsNotGood . Évalué à 5.
On est dans le myth. Un base rpm n'explose pas ou quasiment jamais.
Moi ça m'est jamais arrivé alors que j'utilise du rpm depuis maintenant plus de 10 ans !
Il y a des gens qui "explosent" leur base en utilisant les options "--nodeps" ou "--force". Mais ils l'ont cherché. Mais ce n'est pas vraiment une explosions de la base, car la base reste cohérente (c-à-d est l'image des conneries de l'utilisateur).
Par contre rpm est fragile face au coupure de courant (dpkg aussi). Dans ce cas la base rpm n'est pas corrompue (car rpm utilise un système transactionnel), mais il y a incohérence entre ce qui est installé et ce qui est indiqué dans la base et d'autres problèmes très emmerdant.
Rpm peut aussi être "emmerdé" en cas de manque d'espace disque. Notons que bien avant dpkg, rpm vérifie que l'espace disque est suffisant avant de faire l'installation. D'ailleurs je ne suis pas sûr que dpkg le fasse encore.
En passant, ce n'est pas car yum (ou équivalent) écrit un message d'erreur avec "erreur dépendance manquante" que la base rpm est "explosée". Et ce n'est pas car apt "cache" les dépendances manquantes que ça base n'est jamais "explosée".
[^] # Re: dommage
Posté par rewind (Mastodon) . Évalué à 1.
des références à propos de ce mensonge honteux ?
[^] # Re: dommage
Posté par IsNotGood . Évalué à 3.
Je n'ai pas dit que c'était un mensonge (honteux).
Si tu veux la même chose avec yum, il y a le greffon yum-skip-broken.
C'est un choix qu'a fait apt, yum ne l'a pas fait (du moins par défaut).
[^] # Re: dommage
Posté par rewind (Mastodon) . Évalué à 1.
[^] # Re: dommage
Posté par Prosper . Évalué à 7.
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.
Urpmi ça date de 1999 qd même , c'est pas si jeune que ça ...
[^] # Re: dommage
Posté par Anonyme . Évalué à 2.
[^] # Re: dommage
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 3.
J'ai uniquement donné un avis qui n'a pas la prétention d'avoir une valeur universelle.
Ne cherchons pas le diable partout !!
Alexandre COLLIGNON
[^] # Re: dommage
Posté par campagnard . Évalué à 3.
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 2.
[^] # Re: dommage
Posté par Infernal Quack (site web personnel) . Évalué à 8.
La news ne parle pas d'urpmi.recover. Je suppose qu'ils ne communiquent pas encore dessus car pour eux ce n'est pas suffisamment stable mais perso j'ai testé et c'est très pratique.
Par exemple, hier j'ai voulu tester "conduit".
"urpmi conduit" et là il me dit qu'il doit installer 20 paquetages supplémentaires ! Avant je faisais un copier/coller fastidieux de la liste des paquetages pour faire un "urpme" si "conduit" ne m'intéresse pas.
Maintenant je fais "urpmi.recover -checkpoint" (Pour poser un point de retour et pour activer le système de retour arrière). Ensuite "urpmi conduit". Et si conduit ne m'intéresse pas "urpmi.recover -rollback 2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés après cette date.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: dommage
Posté par gnumdk (site web personnel) . Évalué à 3.
>2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés
>après cette date.
Ca n'a quand même pas la souplesse d'un:
apt-get --purge autoremove
C'est dommage que urpmi ne soit pas capable de trouver tout seul ce qui n'a pas été implicitement installé par l'utilisateur.
[^] # Re: dommage
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Si ça se trouve un équivalent au --purge existe sous rpm. Des experts sur le sujet ?
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 3.
urpme `urpmi_rpm-find-leaves -g`
[^] # Re: dommage
Posté par TeXitoi (site web personnel) . Évalué à 4.
L'équivalent apt de ce que tu donnes, c'est
apt-get --purge remove `deborphan`autoremove propose d'enlever les paquets installés automatiquement par apt (genre libtrucmuch quand tu installes progfoo) qui n'est plus nécessaire (genre la mise à jour de progfoo ne dépend plus de libtrucmuch).[^] # Re: dommage
Posté par Jeanuel (site web personnel) . Évalué à 1.
Par exemple sur mon poste, j'avais une lib qui trainait sans raison :
$ urpme `urpmi_rpm-find-leaves -g`
$ désinstallation de liblua5.0-5.0.3-4mdv2008.0.i586
$ désinstallation du paquetage liblua5.0-5.0.3-4mdv2008.0.i586
Voila, le ménage est fait.
[^] # Re: dommage
Posté par TeXitoi (site web personnel) . Évalué à 4.
[^] # Re: dommage
Posté par Alban Crequy (site web personnel) . Évalué à 1.
# KDE 4
Posté par jiyuu . Évalué à 4.
Dans la dépêche et ici [http://club.mandriva.com/xwiki/bin/view/Main/2008SpringRelea(...)] il est indiqué que la version de kde 4 est la 4.0.2.
Par contre ici [http://wiki.mandriva.com/en/2008.1_Tour] et ici [http://wiki.mandriva.com/fr/Mandriva_Linux_2008_Spring_Visit(...)ée], il est indiqué que c'est la version 4.0.3.
[^] # Re: KDE 4
Posté par Neije . Évalué à 2.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
# Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Bruce Le Nain (site web personnel) . Évalué à 8.
Ainsi que la refonte du MCC (mandriva control center). Je n'ai pas testé toutes les fonctionnalités, mais le gestionnaire de paquetages a été grandement améliorée, il est possible d'utiliser le filtre "applications graphiques" afin d'épurer toutes les bibliothèques et autres dépendances, et n'avoir que les logiciels au sens "applicatif générique". Il semble que la conversion des index au format xml ait été fortement bénéfique. La rapidité d'exécution n'a plus rien à voir, qu'il s'agisse d'urpmi ou de rpmdrake. Plus besoin non plus, semble-t-il, de passer par plf puisque à la première connexion il est proposé d'installer toutes les sources nécessaires. L'applet de mise à jour ne s'affiche que lorsque une mise à jour est nécessaire, ou qu'il y a un problème. Enfin, avant il fallait choisir entre les index complets, ou réduits (moins d'info mais temps de téléchargement plus court) et maintenant seul les infos nécessaires sont téléchargées à la volée. Bref, je pense qu'il manque uniquement, pour parfaire le tableau, une série d'icônes graphiques représentant les "incontournables" pour le débutant qui cherche à installer un logiciel spécifique, tel que j'ai pu le voir dans certaines distributions dont kubuntu.
Pour finir, tout comme la dernière fedora, la teinte du fond d'écran varie en fonction de l'heure.
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par claudex . Évalué à 5.
C'est peut-être un gadget inutile mais ça donne super bien, j'en suis complètement fan.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Zorro (site web personnel) . Évalué à 3.
Sérieux, j'aime beaucoup.
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Macsim . Évalué à 2.
Ce module est disponible pour d'autre distribution ?
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Jerome Alet (site web personnel) . Évalué à 2.
Qui donc est chargé de préserver notre morale et celle de nos pauvres enfants ???
"et permet d'instituer des limites temporelles d'utilisation de l'ordinateur"
man time.conf
à bas la censure !
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par GeneralZod . Évalué à 2.
C'est un script bourrin à la main ou bien ils utilisent la fonctionnalité de Nautilus ?
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par brunus (site web personnel) . Évalué à 2.
Voir ici les images et fichiers xml :
http://people.redhat.com/duffy/artwork/infinity-24/
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par GeneralZod . Évalué à 2.
Cette fonctionnalité existe depuis plus d'un an (Fedora 7 l'avait mais aucun wallpaper ne l'exploitait avant Fedora 8), et j'ai remarqué que si les utilisateurs appréciaient, finalement, peu de distributions l'ont adoptés.
Donc, je voulais savoir si Mandriva exploitait cette fonctionnalité ou avait développé son propre truc.
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Anne NICOLAS . Évalué à 9.
Anne - employée Mandriva
[^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)
Posté par Neije . Évalué à 4.
D'un côté plus "technique", on notera la présence de composant bas niveau (kernel, drivers ...) communs avec la distribution Turbolinux. Ces éléments sont maintenants développés au sein d'un labo commun : "Manbolab". Chaque version futures de ces deux distrib's intégreront de plus en plus de composants communs au fur et à mesure de l'avancée du projet.
Sinon, on notera aussi que tous les paquetages (ou presque) sont maintenant refait automatiquement par un bot pour chaque nouvelle version. Qq vieux paquest devaient encore migrer.
Le contrôle parental est aussi un super nouvel outil. A tester.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
# Intégration des outils des synchronisations
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 7.
Avec l'essor des offres 3G+, un grand nombre d'utilisateur lambda se retrouve avec un superbe outils entre les mains, jusqu'alors difficilement utilisable avec une linux box.
Voici un argument de plus pour une migration toute en douceur ... :D, et aussi de quoi faire plaisir à tous les geek ayant acquis se genre de portable.
Alexandre COLLIGNON
[^] # Re: Intégration des outils des synchronisations
Posté par ultimat . Évalué à 2.
Ou bien ceux qui utilisent déjà ce genre de technique peuvent-ils nous indiquer quel est leur mobile ?
[^] # Re: Intégration des outils des synchronisations
Posté par BAud (site web personnel) . Évalué à 2.
Sinon un peu plus d'info sur http://wiki.mandriva.com/en/2008.1_Synchronization pour la synchro (mais pas de liste), la catégorie Téléphone du wiki http://wiki.mandriva.com/fr/Cat%C3%A9gorie:T%C3%A9l%C3%A9pho(...) ne demande qu'à être complétée.
Et en cherchant un peu http://www.opensync.org/wiki/DeviceCompatibilityList montre ce qui fonctionne avec opensync.
# Support EEE
Posté par Cédric Brun (site web personnel) . Évalué à 2.
[^] # Re: Support EEE
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Support EEE
Posté par ʭ ☯ . Évalué à 2.
ça vient de là : http://forum.eeeuser.com/viewtopic.php?id=18287&p=12
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Support EEE
Posté par djibb (site web personnel) . Évalué à 2.
[^] # Re: Support EEE
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: Support EEE
Posté par B16F4RV4RD1N . Évalué à 3.
oui mais un EEE en suspend to ram n'a même pas 24 h d'autonomie, alors à mon avis il vaut mieux éviter.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Support EEE
Posté par pada . Évalué à 2.
L'install d'une powerpack par mon DVD externe LaCie (le modèle lourd) a été long, de l'ordre de 3 heures. J'ai fait une install KDE par défaut sans swap. ll m'a fallu reconfigurer KRandRTray pour utiliser un écran externe, j'ai aussi immédiatement enlevé Kerry Beagle. Pour le reste ça a l'air bien, on verra un peu plus tard, mais dès le départ c'est fonctionnel: montage des clés usb, sans fl (mais pas encore essayé wpa supplicant avec le protocole de mon université...) ...
[^] # Re: Support EEE
Posté par Budzi Jabaroff . Évalué à 3.
après ubuntu et eeexubuntu sur eeepc 701.
Je viens d'installer cette version sur mon eeepc avec GNOME, tout le matos est super bien reconnu, et je trouve l'installeur de mandriva très simple (niveau ubuntu, meme mieux peut etre)
==le cool==
Cheese dans le dépot
Gnome 2.22
Ecran externe VGA bien reconnu
Un démarrage correcte
....
==Points négatifs==
*le wifi, il n'est pas installé par défaut (de la politique anti-proprio?) c'est tres simple à installer et ça se fait graphiquement.
*VNC (tightVNC) C'est à revoir, l'interface est pourrite par rapport à ubuntu
*apres la config de samba, le systeme de configuration ajoute dans le fichier /etc/fstab le partage si on veut, Il rajoute la ligne correspondante en utilisant un nom d'hôte (//Monnomd'hote/monpartage) qui n'est pas reconnu par la suite, donc le montage
echoue après redemarrage de la session gnome.
J'ai du bidouillé le fichier (/etc/hosts) sur ce point.
*NFS c'est dur à configurer, le service ne demarre pas
*Demarrage détaillé en mode texte, ce n'est pas joli
*Le système sonore: le son de amarok n'est pas en priorité haute, ça coupe un peu quand l'ordi rame, c'est désagréable de faire souffrir le son
En tout cas je suis globalement bien content de la bete :-) C le pied, j'avais quitté mandriva FREE il y a un an, je reviens content et pour longtemps je pense,
# ClearClearLooks!
Posté par romi . Évalué à -5.
-> http://wiki.mandriva.com/en/Image:20081_KDE_preferences.jpg
en dehors de ça j'ai rompu avec Mandriva il y a quelques années, pour des raisons plus ou moins évoquées plus haut (et qui sont en partie fondées)
par contre, je ne comprends toujours pas pourquoi une distribution française à la base n'est toujours pas capable de fournir du contenu en français sur leurs sites?
[^] # Re: ClearClearLooks!
Posté par RO1 . Évalué à 6.
Faut chercher 2min avant de troller pour rien (tm)
[^] # Re: ClearClearLooks!
Posté par romi . Évalué à -1.
je signalais juste qu'il y avait sur cette page:
http://wiki.mandriva.com/en/2008.1_Tour
un lien foireux, censé afficher une belle image du "KDE 4's configuration panel", ce lien menait vers une page inexistante:
http://wiki.mandriva.com/en/Image:20081_KDE_preferences.jpg
apparemment le problème été corrigé depuis
pas de troll de ma part, et quand bien même? est-ce que Linuxfr serait toujours lu si les trolls n'existaient plus?
[^] # Re: ClearClearLooks!
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
Tout simplement parce que tu es sur la section anglaise du site, en français, c'est ici :
http://wiki.mandriva.com/fr/Mandriva_Linux_2008_Spring_Visit(...)
(PS : quand linuxfr supportera les accents dans les url ?)
[^] # Re: ClearClearLooks!
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
Les lumbagos ! Je les avais pourtant prévenu, chez mandriva !
[^] # Re: ClearClearLooks!
Posté par libre Cuauhtémoc . Évalué à 2.
Mais il faisait du social en engageant leur packageur wcoincoin que je salue au passage
# apparence
Posté par B16F4RV4RD1N . Évalué à 5.
http://images.mandriva.com/2007Spring/Screenshots/One_2007_s(...)
Cela peut semble anodin face aux nouvelles technos très intéressantes de cette version, mais malgré tout c'est la première chose qui m'a frappé, tant sous gnome que kde, qui se retrouve à égalité à ce niveau (je ne parle même pas de kde4 qui est aussi élégant qu'une pochette de disque des années 80, mais ça ce n'est pas spécifique à Mandriva).
En tout cas chapeau pour tout le reste !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# mandriva : le fichier est où ?
Posté par mlinux . Évalué à -3.
C'est vraiment surprenant l'expérience avec cette mandriva, le site est une usine à gaz incroyable dans laquelle il est complexe de se repérer, quand on arrive enfin à comprendre que spring/one/1 ca se ressemble alors on charge un lien pour voir (car entre asia et int on s'interroge : à quand des libellés simples ? ) .
Puis comme le 1er lien est mort on poursuit , genre au 5ème ... toujours des liens morts sur les mirroirs france !!
Euh ils dorment ou quoi ?
Bon allez, je tente chez distri coffee ou un truc dans le genre un peu plus bas et là ouf !! ya du café et même un lien... Heureusement que j'avais prévu un wget -c car l'aprém passée le cd n'était pas encore arrivé... J'ai arrêté là les frais.
[/mode mandriva off]
[^] # Re: mandriva : le fichier est où ?
Posté par B16F4RV4RD1N . Évalué à 4.
http://www.mandriva.com/fr/telecharger
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: mandriva : le fichier est où ?
Posté par mlinux . Évalué à 1.
si si c'est exactement le lien utilisé et je crois que les torrents sont l'un des choix possibles, mais pas le seul. A mon avis seuls ceux qui savent que les torrents soulagent la bande passante les prennent, notamment quand d'autres choix sont là avant . Je suis donc allé au choix le plus évident : or le choix du pays offre des mirroirs locaux aux liens http et ftp ; torrent n'est présenté qu'ensuite en bas de page et de plus comme méthode alternative ; c'est dommage en effet , même si cela à la mérite d'exister. J'aurai proposé torrent d'abord et les autres liens ensuite ;)
Si je critique c'est car la critique est constructive. Quand à moi de telles anomalies en page de téléchargement me paraissent aberrantes (page de téléchargement trop chargée et mal agencée, une fois le pays choisi n liens vides, téléchargement anormalement long pour un simple cd ) , d'autant plus pour une société qui par ailleurs vend ses produits et devrait fignoler ces aspects de telle sorte que l'on soit tenté d'acheter si la version gratuite convaint.
[^] # Re: mandriva : le fichier est où ?
Posté par B16F4RV4RD1N . Évalué à 4.
Donc aucun problème à signaler du côté des différentes méthodes de téléchargement.
Au niveau du site ce n'est pas le meilleur site au monde, mais il n'est pas mal fait quand même et relativement pratique à utiliser je trouve (wiki etc)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: mandriva : le fichier est où ?
Posté par vladislav askiparek . Évalué à 1.
C'est mon premier amour "viable" (après RH, mais c'est l'époque qui voulait ça).
Ils ont toujours été précurseurs pour faire de Linux un système utilisable au bureau et à la maison; toujours!
Mais si le site de Mandrake était une grosse merde, celui de Mandriva est une bouse de première.
Donc, je plussoie...et vous me moinsez.
[^] # Re: mandriva : le fichier est où ?
Posté par Bruce Le Nain (site web personnel) . Évalué à 5.
[^] # Re: mandriva : le fichier est où ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Certes, il n'est pas parfait, mais tout le monde peut contribuer à http://wiki.mandriva.com/fr/Accueil
# Enfin la voilà
Posté par Sébastien FRADE . Évalué à 6.
Encore beaucoup de nouveautés en perspective. :)
Je suis content de voir qu'OpenOffice.org est présent sous sa toute dernière version (les transitions 3D d'Impress sont-elles inclues?).
Quant aux trolls sur la version Powerpack, je rappelle que le paiement est dû à la présence de pilotes propriétaires pour les cartes graphiques et autres, des programmes payants (exemple, LinDVD), du support utile pour les débutant comme pour les entreprises, etc qui ne sont pas présent dans la version Libre pour des raisons évidentes.
Histoire de troller à l'inverse: pourquoi n00buntu ne propose-t-elle pas une version de ce type qui est d'une symplicité déconcertante pour le nouveau venu dans le monde GNU/Linux? :D
Non mais sérieusement, arrètons les trolls deb/rpm, version payante, etc... accueillons plutôt à bras ouverts cette nouvelle version d'une distribution grand-public dont la qualité n'est plus à démontrer (même s'il en existe d'autres comme OpenSuse ou Ubuntu et bien d'autres).
Je reste fidèle à Mandriva qui sait rendre GNU/Linux accessible au grand public depuis bien longtemps.
Je n'ai pas encore réussi à télécharger l'ISO (apparemment pas mal d'autres se sont rués comme moi sur les serveurs à l'annonce de la release :P). Je vais donc attendre un peu avant de pouvoir la tester sur mon ordinateur fixe. :)
[^] # Re: Enfin la voilà
Posté par alouali (site web personnel) . Évalué à 8.
je viens de tester, et les transitions 3D OpenGL d'OO Impress sont bien là et fonctionnent toutes !!! Pour une fois ça fait plaisir de voir un truc qui marche sous Linux, mais dont on ne sait pas si ce sera porté un jour sur Windows ou Mac.
Dans le même genre d'idée, en plus évolué, il y a KeyJNote, qui propose des transitions OpenGL de grande qualité, et un accès ultra rapide à l'ensemble des vignettes : je préfère désormais ça pour la visualisation (il faut convertir les fichiers en PDF avant, on perd donc des choses en en gagnant d'autres...)
Et j'en profite aussi pour remercier et féliciter toute l'équipe de Mandriva, tout a marché out of the box sur ma machine, même Compiz-Fusion avec ma vieille carte 3D, bravo ! J'avais switché en 2003, et depuis je n'ai plus jamais eu envie de retourner sous Windows.
[^] # Re: Enfin la voilà
Posté par Sébastien FRADE . Évalué à 2.
Je vais aussi pouvoir tester la bête en live-cd sur mon ordinateur portable.
:D et dès la fin des examens, si tout va bien, je l'installe. :)
[^] # Re: Enfin la voilà
Posté par djibb (site web personnel) . Évalué à 3.
[^] # Re: Enfin la voilà
Posté par alouali (site web personnel) . Évalué à 4.
http://www.oooninja.com/2008/02/eye-candy-3d-opengl-transiti(...)
Elles sont faciles à repérer : c'est les seules dont le nom n'est pas traduit en français !
(et apparemment c'est issu du Google summer of code 2007)
[^] # Re: Enfin la voilà
Posté par djibb (site web personnel) . Évalué à 3.
[^] # Re: Enfin la voilà
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Pour ma part, je viens de dépasser le ratio de 1.00 C'est à dire que j'ai rendu à internet plus que je lui ai demandé. J'espère bien monter à un rapport de 3 ou 4 sur les 4 images ISO de DVD que j'ai téléchargé sur ma machine.
[^] # Re: Enfin la voilà
Posté par Zorro (site web personnel) . Évalué à 10.
Et en plus, ça leur donne un bienvenu coup de main pour continuer à coder, et du pain pour manger.
Je crois que personne n'a pensé à donner le lien pour l'acheter. C'est là :
http://store.mandriva.com/product_info.php?products_id=388
[^] # Re: Enfin la voilà
Posté par Sébastien FRADE . Évalué à 3.
# :(
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Et on se rammasse vos commentaires au final
linuxfr, c est plus ce que c' était.
désolé des grots mots, mais franchement (...)
[^] # Re: :(
Posté par Spyhawk . Évalué à 2.
Ben si, justement :)
[^] # Re: :(
Posté par Sébastien FRADE . Évalué à 1.
# Ca marche bien sur eeePC
Posté par Sébastien Rohaut . Évalué à 3.
Testé en livecd sur un eeePC, et installé par accident*. Donc ça marche, les touches ACPI sont gérées, bien que l'OSD pour le volume soit bien trop gros (1/4 de l'écran).
La webcam fonctionnelle directement sans avoir à l'activer dans le bios, mise en veille OK,gestion énergie ok (mieux que sous eeexubuntu), pour l'instant, je n'ai rien à dire une fois installée.
J'ai par contre deux-trois griefs :
- Installation par erreur : j'avais booté via un lecteur cd externe sur le live. Ma fille de 4 ans 1/2 adore jouer avec les icones, surtout les icondes rigolotes, et sait cliquer sur les boutons de la boite de dialogue. Elle a donc fait cliclic puis suivant, jusqu'au bout, et compris la sélection du mot de passe root et des comptes se fait après la copie... L'installation ne demande pas de mot de passe, et d''ailleurs un su sur la live montre l'absence de mot de passe root. J'appelle ça un trou de sécurité. Bref, tout perdu... Mais ça prouve qu'une enfant de 4 ans 1/2 ne sachant pas lire peut installer Mandriva One.
- Devant le fait accompli, j'ai tout de même réinstallé moi-même la distrib. Impossible de choisir ext2 à l'installation ! Embetant sur le SSD de l'eeePC. Donc passage à la main, reformatage avec un bloc size de 1024.
- j'ai voulu utiliser la distrib et le gestionnaire de paquet de mandriva. Malgré n tentatives, le téléchargement finissait par bloquer sur certains paquets de plusieurs Mo, sans reprise (j'ai parfois attendu près d'une heure). Alors je clique sur Annuler, je désélectionne quelques produits, et relance l'installation. Et bien il n'a pas pris en compte mes "déselections". Hop un bug ! De toute façon, je n'ai jamais réussi à installer.
- Pire : en fermant le gestionnaire de paquets, la transaction continue et il y a un lock sur la base rpm... Pire encore : le Mandriva Update se déclenche parfois quand on est dans le gestionnaire, et du coup on ne peut plus rien installer durant ce temps... Mal fichu.
- Le boot graphique est absent par défaut de l'eeePC faute d'activation du frame buffer. je vais chercher voir si c'est tout de même possible.
Mais bon, malgré ces légers soucis, je vais continuer. Les serveurs Mandriva sont saturés en ce moment, ceci expliquant cela. C'est joli, ça marche pas mal, le matériel est parfaitement géré, rien à retoucher à ce niveau, 3D activé, pilote graphique Intel ok (problème xv des eeexubuntu absent). Moi qui suis habitué à OpenSUSE et Ubuntu, j'avoue que c'est pas mal.
My 2 cents.
[^] # Re: Ca marche bien sur eeePC
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Je connaissais l'expression « Un enfant de 6 ans pourrait le faire », mais là, il va falloir réviser notre langage !
Bravo à elle et toutes mes félicitations à ses parents.
[^] # Re: Ca marche bien sur eeePC
Posté par wismerhill . Évalué à 4.
Non, le trou de sécurité c'est d'avoir laissé un ordinateur sans surveillance dans un état où n'importe qui peut le foutre en l'air.
[^] # Re: Ca marche bien sur eeePC
Posté par romi . Évalué à 1.
[^] # Re: Ca marche bien sur eeePC
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Pour choisir l' EXT2 lors de la phase d' installation :
Lors du partitionnement, choisir "partionnement personalisé".
Puis clicker sur "expert" (cela va ouvrir différentes fonctions à différents endroits).
Enfin clicker sur "type" et choisir "Linux NATIF" en lieu et place de EXT3.
Voilà, peut être que cela servira ?
En tout cas, si EXT2 est à conseillé pour le ssd (je cours relire l' article de Patrick_G sur les formats de fichiers), cela pourrait être un plus qu' il soit proposé par défaut dans le cas de cet EEEPC ??
Tu peux ouvrir un rapport de bug, je pense, afin de proposer cette suggestion.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.