BAud a écrit 12979 commentaires

et ya le même pour x86_64 ? ya un bugzilla pour remonter les demandes d'améliorations ? :p

qu'est ce qui est dur de cocher main / updates et contrib dans http://easyurpmi.zarb.org et de choisir un miroir ?

ça te permettrait de bénéficier en supplément de
mandriva-doc-Discovery-fr
mandriva-doc-Starter-fr

pour désactiver les CD, visiblement tu n'as jamais lancé le centre de contrôle Mandriva :/ Système / Administration / configurer votre ordinateur / Sélectionner source de paquetages...
après si tu ne veux pas lire de doc', pas de souci, je ne souhaite pas aider non ceux qui ne se prennent pas par la main ;-)

http://www.delafond.org/survielinux/
http://lea-linux.org

elle est papéticienne celle-là alors :)

bon bin désactive les CD
retourne sur http://easyurpmi.zarb.org pour avoir les médias de main et updates (et contrib), comme je te l'avais recommandé au début (qu'est ce qui t'a fait ne pas suivre ce que j'ai dit ?)

tant que j'y suis, donne le résultat de rpm -qa |grep mandriva-doc

qu'as-tu pensé de la lecture des tutoriels de mandriva inclus dans ta distribution ?

l'info est dans l'agenda du libre (AdL) tu trouveras les LUGs de la région http://agendadulibre.org/showevent.php?id=872

peux-tu donner le résultat de lsusb ? cela permettra d'identifier clairement le modèle (ou un lspcidrake -v)

sinon pour la mandriva 2007, elle intègre déjà le pilote ueagle-atm, ne manque que le firmware que tu trouveras sur http://atm.eagle-usb.org/wakka.php?wiki=UeagleAtmDocFr

quel scanner utilises-tu ?

d'après https://linuxfr.org/~nelis/11968.html ajouter le paquet xsane-gimp pour que gimp gère les scanners

Je n'ai pas compris ta question de relancer une installation après ajout de matériel... le centre de contrôle est justement là pour effectuer la configuration des matériels détectés, qu'ils soient branchés au démarrage ou pas.

Je vois au moins les deux avantages suivants à une licence libre :
- Une licence libre permet à un artiste de se faire connaître en bénéficiant d'une distribution facilitée ?
- Pour des livres, possibilité de traduction dans d'autres langues (j'allais ajouter, "de son vivant" quand il est encore possible de contacter l'auteur pour échanger avec lui pour voir ce qu'il en pense).

Le choix d'une licence libre facilite les initiatives, donne un cadre légal cadré, plutôt que d'avoir à rentrer dans une logique contractuelle compliquée (c'est toujours plus simple quand l'auteur y a réfléchi auparavant, lors du choix de sa licence). D'autant que le choix d'une licence doit être fait au début, il est assez difficile d'en changer par la suite quand le nombre de contributeurs a augmenté (voire certains deviennent injoignables).

C'est pour cela qu'il me semble important de promouvoir des licences libres plutôt que des licences faussement libres http://faq.tuxfamily.org/wakka.php?wiki=LicenceLibrePourquoi

donne le résultat de urpmq --dump-config
ouvre une fenêtre terminal plutôt que de passer en console par ctrl-alt-f1 pour les copier/coller, il suffit alors de sélectionner et de cliquer sur la molette de la souris pour coller
tu as sans doute pris main/updates mais pas main

d'autre part, urpmi --fuzzy kernel-source-stripped t'afficherait les noms de paquets disponibles, mais urpmi nvidia - après calcul des dépendances - devrait te le proposer tout seul.

en tout cas c'est bon sur l'agenda du libre http://agendadulibre.org/showevent.php?id=915
/me se dit qu'il va voter contre les prochaines dépêches d'événements pas présentes dans l'AdL au moment de la soumission à LinuxFR ;-)

oui ;-) mais tu oublies le cas où la lib' nécessaire est dans la dernière version, qui - justement - n'est pas encore packagée par la distribution :/

Puis bon, effectivement, les bonnes pratiques de gestion de version de libs existent, faut-il encore que la libification ait été faite correctement par les développeurs (gecko cause quelques petits soucis par exemple, ceci expliquant que le dernier firefox 2.0 n'est pas packagé par pas mal de distribs en backport vu que cela casse epiphany, galeon, yelp et d'autres trucs...).

mouais le "sans installation" ;-)
je ne sais pas pourquoi ça me rappelle Oracle Application (un ERP ou PGI en français) dont la fameuse applet java faisait de l'ordre de 20 Mo (ou 80 Mo, j'ai un petit doute d'un coup...).
Bon eh bien, quand tu as un parc de plus de 100 utilisateurs (même un peu plus généralement pour ce genre d'appli), tu n'as pas trop envie d'écrouler ton réseau en journée, donc tu fais quand même la gestion du déploiement (malgré cette vague promesse du "sans installation"...).
Mieux vaut avoir un système maîtrisé, qui gère le retour arrière, gère les ressources, gère la configuration, ... que des "solutions de développeur" à la "yaka qu'à recompiler, yarien à installer ça se fait tout seul" qui ne gèrent pas la complexité d'une prod' réelle (mais qui effectivement marchent très bien en dév', avec un seul poste à déployer, en LAN en plus, toussa...).

oui et non.
d'un point de vue développeur, effectivement ce serait à la distrib' de faire les paquets
d'un point de vue distrib', autant que les dévs maintiennent les packages,
ou alors que les développeurs trouvent des contributeurs en mesure de faire des paquets et gèrent leur intégration dans leur distrib' préférée (je sais pas pourquoi je suis plutôt pour cette dernière solution pour certains paquets...)

bon en fait, si, je sais pourquoi :
quand tu vois que pas mal de distribs ont aujourd'hui plus de 10 000 paquets (voire plutôt > 20000), qu'il n'y a pas forcément 100 employés dédiés à faire des paquets, une solution claire revient à faire appel "à la masse" des contributeurs (sans connotation négative), c'est à peu près un bon moyen de faire un tri dans les "logiciels valant le coup d'être packagés"
ainsi, c'est bien aux développeurs de motiver - parmi leurs utilisateurs - des contributeurs pour packager et aux distribs de simplifier la tâche aux contributeurs pour packager (je n'ai pas dit que c'était facile)

Après, il y a la politique de montée de version de chaque distrib' qui rentre en ligne de compte, l'obsolescence des "vieilles" distribs, le nombre limité de réels contributeurs... Pas mal de distributions proposent des backports, quand le logiciels n'a pas de dépendance à trop de libs structurantes, ça peut valoir le coup et le coût (pas encore pour Firefox, ni KDE ou Gnome sans vouloir lancer de troll, des backports déstabiliseraient un peu trop le système...).

Je comprends tout de même les développeurs qui chouinent contre les distribs et les packageurs qui chouinent après les développeurs (bon ya aussi les utilisateurs qui chouinnent, mais bon parfois il y a un merci tout de même...). Il s'agit AMHA de trouver un mode de fonctionnement qui convienne à tout le monde ; perso, le système de paquets me semble le plus intéressant : cela permet d'avoir plus de contributeurs "éclairés" pour les développeurs upstream ET pour les distributions (et moins d'utilisateurs qui cassent leur système à vouloir contourner le système de paquets de leur distrib'...).

sur un 'unix' on peut aussi faire des systèmes d'installation simples
euh tu veux dire comme des packages ?
genre dispos pour solaris avec http://www.sunfreeware.com/ ? (pour AIX je ne me rappelle jamais du site...)

ah tiens, z'ont même pas gcompris eux :/
puis bon, z'ont un peu moins de packages que pas mal de distributions GNU/Linux aussi (si ça se trouve leur système d'installation doit être compliqué, flûte)

euh t'as oublié de dire que les copies d'écran sont disponibles sur la page http://www.ivanhoe-technologies.com/products/pptools/pptools(...)
tu aurais pu indiquer un petit teaser du genre "bientôt intégré à ktechlab (ou en add-on..." https://linuxfr.org/2006/03/11/20484.html et je n'ai pas vu de dépêche sur trollfr^Wlinuxfr pour la sortie de la v1.0... ;-) (/me adepte des copies d'écran pour booster la comm' : suffit de regarder les liens les plus cliqués sur les dépêches de linuxfr pour se rendre compte que je ne suis pas le seul :p)

D'autre part, choisir un hébergement des sources sur https://gna.org (par exemple, sf et berlios souffrant de lenteurs AMHA...) peut permettre de "rassurer" sur la liberté de ton soft (on ne perd pas de temps à trouver le texte de la licence) ainsi que d'assurer que demain les sources ne vont pas soudain disparaître (cela permet aussi d'intégrer de nouveaux développeurs tout étant fait pour le travail collaboratif et pour ouvrir le projet à la communauté).
Pour l'hébergement du site web, tu as aussi http://tuxfamily.org (qui peut permettre aussi de gérer ton source d'ailleurs, même si je suis plus habitué à gna pour cela), plutôt que free qui fait tout de même beaucoup "site perso" AMHA.

En tout cas, pour le choix de freshmeat, c'est très bien, cela permet le tri par catégories déjà. J'ai eu à rechercher des logiciels par thème / évaluer leur niveau de maintenance pour http://cookerspot.tuxfamily.org/wikka.php?wakka=ProgramsScie(...) et c'est clair que les sites non raccrochés à une forge ne sont pas très lisibles (voire très difficiles à trouver déjà...).

bin configurer les sources par http://easyurpmi.zarb.org (main / contrib / plf...)

et peut-être prendre le paquet nvidia-legacy si ta carte n'est plus supportée par les derniers pilotes propriétaire nvidia...

PS: si quelqu'un a le background UNIX nécessaire pour m'expliquer à quoi correspond des "programs and data that are shareable amongst a group of hosts" je suis preneur
Tu peux tout à fait imaginer qu'un parc homogène de stations de travail bootent par le réseau, ce qui permet d'avoir des "terminaux" évolués (et indifférenciés) ainsi qu'une gestion centralisée des mises à jour / ajouts de programmes pour tout le parc.
Le /usr/local permet de différencier les applications pour ton site : cela correspond à des applications qui sont adaptées à ton besoin (ou ceux de tes utilisateurs) mais qui n'ont pas vocation à être gérées de manière standard au niveau de la configuration. Par exemple, quand en admin' en central intervient en région, cela lui permet d'identifier directement ce qui est utilisé en spécifique (et d'être sûr de ne pas tout casser). Cela permet de partager les responsabilités.

le terme copyleft en remplacement de copyright ne semble pourtant pas poser de problème pour comprendre ? :-)

Libre de droits n'est pas tout à fait exact par ailleurs...

sur ce, je prends le gauche de ---> [ ]

le pilote inclus dans la free est le pilote libre nv
le pilote propriétaire nvidia est disponible dans plf-nonfree

installe les sources de médias main / contrib / plf par http://easyurpmi.zarb.org (tu prends le serveur FTP le plus proche de chez toi, ne prends pas backports ni testing)
ensuite, urpmi nvidia en tant que root dans une fenêtre terminal (par su - ) t'installera le pilote propriétaire....

sinon un urpmi --fuzzy mandriva-doc te montrera les paquets de documentation mandriva disponible (aller ensuite dans /usr/share/doc/mandriva/ pour les consulter avec konqueror par exemple) et tu as aussi la base de connaissance http://club.mandriva.com/xwiki/bin/view/KB/

tu trouveras quelques documentations d'installation sur
http://tuxmobil.org/acer.html
http://www.linux-on-laptops.com/acer.html
(sinon c'est l'occasion de démarrer ta page web sur les modèles proposés pour prendre des notes sur ton install' et indiquer ce qui marche bien/moins bien...)

Pour t'aider plus avant, ça va être difficile, si tu ne nous précises pas quelle version de debian tu as installée (sarge ? etch ?) et le noyau utilisé (donné par uname -a) + les informations sur ta carte son (donné par lspci -v pour avoir les identifiants matériel)

ah bin j'ai pas pu prévoir suffisamment tôt c'est pas sur http://agendadulibre.org/ ;-)

c'est pourtant pratique pour voir ce qui se passe pas loin de chez soi :/

ah tiens http://www.nojhan.net/geekscottes/index.php?strip=34 il y a encore à faire s/driver/pilote/ et s/noël/Noël/ comme sur le dessin ci-dessus.
le patch n'aurait-il pas été remonté upstream ?

(j'ai pas trouvé ton bugzilla pour les demandes d'évol' :p)

sinon pour l'hébergement de geekscottes.nojhan.net (par exemple) et de tes autres sujets libres, il y a http://tuxfamily.org qui accueille déjà quelques artistes libres http://faq.tuxfamily.org/wakka.php?wiki=LinuxGraphics (graphisme, musique, ... et projets connexes).

Se limiter au jeux libres est louable, mais renier les jeux propriétaires sous Linux, c'est faire passer l'idée comme quoi les Linuxiens refusent les jeux vidéos propriétaire, et faire passer l'idée à ces développeurs de porter sous Linux.

Pour abonder dans ton sens et aller un peu plus loin, il faudrait aussi arrêter de croire qu'un jeu libre est gratuit. Le temps passé à développer / tester / packager / documenter / animer des forums de support est bien "payé" d'une manière ou d'une autre...
Vouloir faire de l'argent n'est pas du tout incompatible avec le libre, simplement celui qui souhaiterait en faire directement doit encore trouver son "business model" (qu'est ce qui empêcherait à la "démo" d'un jeu d'être libre permettant ainsi à quelques early testers de faire des remontées pertinentes, de contribuer des mods en libre s'ils le souhaitent, profiter immédiatement d'une bonne intégration par les distributions Linux : cela me semble bien plus respectueux d'une communauté de joueurs que d'essayer à tout prix de la garder captive).

Il y a peut-être quelques peurs de "divulgation du secret", perdre le contrôle de la distribution, de confusion entre libre et freeware, ... à faire sauter aussi. Aux éditeurs de jeu de faire leurs choix aussi.

Après, l'initiative de jeuvinux et qosgames est très bien pour certains utilisateurs afin de franchir le pas. Je pense qu'elle est effectivement complémentaire de jeuxlibres.net et pas en concurrence (supporter des jeux propriétaires compilés en statique bien souvent, que pour i586, voire que pour windows - initialement - est déjà plus compliqué que de bénéficier de l'intégration proposée par les distributions... bref).

je pense plutôt qu'il voulait dire qu'une formulation précise qu'il aurait attendu serait
"jeuvinux se concentre sur les jeux sous linux, qu'il soient libres ou propriétaires."

Effectivement, jeuxlibres.net n'acceptera pas de freeware, ni de shareware, uniquement des jeux _libres_. L'opposition n'est donc pas entre gratuit et payant, mais bien entre libre et propriétaire. Tu remarqueras que cela va jusqu'à la disponibilité des "données" (maps, persos, musiques, graphismes...) : par exemple Quake III dont seul le moteur est libre n'est pas mentionné sur jeuxlibres.net, en revanche tremulous, nexuiz et openarena basés sur un moteur Quake (I, II ou III) ET dont les données sont libres ont le droit à leur page.
http://jeuxlibres.net/showgame/tremulous.html
http://jeuxlibres.net/showgame/nexuiz.html
http://jeuxlibres.net/showgame/openarena.html
Cela a un effet de bord sympathique cette liberté : par exemple, la possibilité de disposer d'une version x86_64 ou ppc, la possibilité de l'inclure directement dans les distributions (et non dans un CD séparé ou un repository non-free séparé...). Il ne me semble pas que wine permette de faire tourner de jeux propriétaires natifs x86_64 ?