J'ai voulu essayer un jeu, pas de paquet pour ma distribution, j'ai su le compiler en ajoutant tous les packages de développement, mais ça me laisse un goût de geek dans la bouche. A côté de ça, un binaire était fourni pour win32.
Et vous, comment verriez-vous un système libre et facile d'utilisation? Comment être libre d'installer ce qu'on veut? Distribuer des binaires comme Maniadrive est-il une bonne solution pour tous (TM)?
Journal Utiliser un système libre...
21
déc.
2006
# Compilés statiquement
Posté par Anonyme . Évalué à 1.
On est déjà libres d'installer ce qu'on veut, on est content quand y'a des paquets et on rale quand y'en a pas mais il faut bien que quelqu'un les fasse...
Personellement je trouve mon système assez simple d'utilisation, même plus simple que Windows.
[^] # Re: Compilés statiquement
Posté par ʭ ☯ . Évalué à 5.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Compilés statiquement
Posté par Tonton Benoit . Évalué à 4.
Ça dois être la même chose pour la quasi-totalité des "grandes-distribs" (Madriva, Debian, Ubuntu...).
Reste le problème des logiciels propriétaire (contourné dans Gentoo), mais on ne va pas se passer du plus grand avantage des distribution Linux (le gestionnaire de paquets) pour eux !
[^] # Re: Compilés statiquement
Posté par Anonyme . Évalué à 1.
Sa doit pouvoir se vérifier en regardant le nombre de paquets dans les dépots.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Le principe de dire que pour qu'un logiciel fonctionne sur ma distribution X il doit être compilé et fourni pour cette même distribution et en soit une limitation forte à la diffusion de nos logiciels.
Soit tu estimes qu'il ne doit y avoir qu'une distribution et tout le monde fourni des paquets binaires pour celle-ci, soit on accepte la diversité mais il faut alors trouver des mécanismes pour qu'un utilisateur puisse installer un logiciel, quelque soit sa distribution.
[^] # Re: Compilés statiquement
Posté par Anonyme . Évalué à 1.
Bah sa on y peut rien, il faut bien que les logiciels soient compilés différemment selon les contraintes imposées par chaque distribution.
Je pense que ce que tu n'as pas compris c'est que le but d'une distribution est justement de fournir des logiciels à l'utilisateur.
Le logiciel ne prend pas en charge son installation, c'est un logiciel tiers qui s'en occupe comme par exemple aptitude, rpmdrake, autopackage...
Il n'est pas possible d'imposer une distribution unique, mais c'est sur qu'il vaut s'unir plutot que de développer trop de systèmes différents.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 3.
C'est ce qui ce pratique actuellement mais c'est une erreur. Le but devrait être de fournir un système d'exploitation fiable et puissant.
Pour les applications, elle viendront sur ta plate-forme si on sait créer un écosystème permettant l'installation simple d'application. Cela passe par la définition d'un format de paquet multi-distro car aucune plate-forme desktop linux n'est en mesure de faire l'unanimité. Tant qu'on sera dispersé, il n'y a aucune chance de percer sur le desktop grand public.
[^] # Re: Compilés statiquement
Posté par Zenitram (site web personnel) . Évalué à 3.
Aucune distribution n'arrivera à proposer tous les logiciels de la terre.
Le système de distribution, c'est bien, mais il ne faut pas enlever la possibilité d'installer soit-même un truc non pris en charge par la distribution.
Et là, faudrait qu'un jour on arrête notre beau bordel, combien de sites (avec des logiciels sympas, mais non encore dans les distributions) ai-je vu avec un "paquet" pour Windows 95 à Windows XP (oups, Vista maintenant), et 20 paquets pour Linux...
Ca fait très pro, super...
[^] # Re: Compilés statiquement
Posté par Misc (site web personnel) . Évalué à 4.
Mais ils se trouvent que , avec des moyens limités, les distributions préferent faire les choses comme elles sentent devoir le faire ( ie de façon propre avec un vrai systéme de paquets, de la vrai QA, et une vraie intégration ), sur la base de raison technique maintes fois évoqué, que de répliquer le bordel de windows avec du téléchargement anarchique qui a conduit à la montée en force des spywares sur windows.
Tout le monde ne veut pas la derniére version du dernier soft à la mode, surtout si il faut aller le chercher à la main.
Je mets au défi les gens de n'utiliser leur gestionnaire de paquet que pour la base, et autopackage pour le reste. On va dire juste la base kde + perl/python/ruby, SDL, pour faire comme xp + directX, et tenir 6 mois avec ça, et les paquets de http://autopackage.org/packages/.
Et ensuite, faire le bilan de la sécurité, de la facilité d'installation, de la gestion au jour le jour.
Aprés ça, on verras de ce que ça donne vraiment en condition réelle, pas pour un ou deux paquets. Et surtout, on verra si la complexité des nombreuses bibliothéques du libre est gérable de façon décentralisé.
> Ca fait très pro, super...
Pourquoi ça devrait faire pro ? C'est des systémes différents, et voila.
Franchement, le professionalisme, c'est pas d'offrir un installeur universel, c'est d'étre sérieux, de communiquer, d'avoir de la documentation, un systéme de support fiable, des interlocuteurs corrects.
[^] # Re: Compilés statiquement
Posté par michauko . Évalué à 1.
rares => tu es dans Debian "stable"
souvent => en "testing"
15 par jour => en "unstable"
Lisez les premiers chapitres de ma doc (oui c'est aussi de l'autopromo) : http://michauko.org/docs/debian_testing/
[^] # Re: Compilés statiquement
Posté par Anonyme . Évalué à 2.
De plus, tu peux toujours faire toi même les paquets dont tu as besoin, les installer et en faire profiter les autres en les envoyants à ta distribution.
Au début il est vrai que ce mode de fonctionement est assez déroutant mais on se rend vite compte que le système de paquets est très très pratique.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 0.
Exemple, sur notre super système multi-utilisateur, il faut obligatoirement les droits super-user pour installer un logiciel ! C'est à dire que les gens qui viennent sur notre plate-forme perdent certaines libertés.
[^] # Re: Compilés statiquement
Posté par Anonyme . Évalué à 1.
Et tu peux très bien installer un logiciel en tant que simple utilisateur en le compilant ou en utilisant un autopackage.
[^] # Re: Compilés statiquement
Posté par B16F4RV4RD1N . Évalué à 2.
oui, à condition qu'il existe.
lorsque j'ai vu autopackage pour la première fois, je me suis dit "quelle m****, on n'a vraiment pas besoin de cela avec un bon système de paquetages", et puis finalement je trouve que c'est quand même un plus, même si cela ne peut pas et ne doit pas se substituer aux paquets officiels des distributions. Mais cela devrait se généraliser.
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: Compilés statiquement
Posté par Misc (site web personnel) . Évalué à 2.
> certaines libertés.
Et gagnent une certaine protection.
Franchement, toute les distros utilisent des utilisateurs sans priviléges, il y a soit une raison valable, soit une cabale sécrete. Et je doute que la cabale existe.
Pour info : http://club.mandriva.com/xwiki/bin/view/KB/AdminAroot.
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 2.
Non mais des fois ...
Il faut arreter de croire que tout va tomber du ciel sans avoir à se bouger le petit doigt. Moi j'aimerais des chaussures qui me font courir le 100m en 10" mais sans que j'aie besoin d'arreter les pizzas et sans prendre d'annabos. Décidement, les chaussures c'est quand même vraiment pas au point et pas libre (au sens je peux courrir à la vitesse que je veux).
Je ne vois pas en quoi ta distribution est mal foutue ou pas facile d'utilisation sous pretexte que le fournisseur du jeu ne fournit pas de binaire pour elle. Tu as pourtant pu installer ton jeu grace à la mise à disposition des sources, des outils nécessaires à leur compilation, et à tes compétances de geek (le monde du libre quoi), alors qu'avec une solution binaire (comme le binaire Windows), tu peux toujours courir pour le faire tourner sur une version non supportée.
Je veux bien que beaucoup de trucs soient améliorables, mais faut pas pousser mémé dans les orties non plus.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Justement, il est impossible de fournir un binaire pour chaque distro. C'est ça le problème. Comme on ne peut pas faire ça, il faut proposer aux utilisateurs un format binaire multi-distro. Ce que demande les utilisateurs, c'est de télécharger un programme pour 'linux', l'installer et que ça marche. C'est une fonctionnalité essentielle. Tant qu'on ne sait pas offrir ça, je ne vois pas comment on peut avancer sur le desktop grand public.
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 3.
A ton avis, pourquoi te faut-il faire un paquet par distribution ? Parce qu'elles ont un système de gestion de paquet différent ou parce qu'elles ont une politique de gestion différente due à des objectifs et approches différents ? Crois tu qu'un quelconque dispositif technique permet de régler ce problème ?
Je suis sur que non car le problème n'est pas technique.
Et puis, je ne vois pas pourquoi il faudrait fournir un binaire par distro... C'est justement aux mainteneurs des paquets de distro d'assurer la génération de ces binaires non ?
Tu dis : Ce que demande les utilisateurs, c'est de télécharger un programme pour 'linux', l'installer et que ça marche. C'est une fonctionnalité essentielle.
Et ? N'est-ce pas ce qu'il se passe à l'heure actuelle ? J'utilise une fedora au boulot, si je veux installer un soft c'est relativement simple : yum install machintruc. Des collegues utilisent ubuntu / debian => apt-get install trucmuche pour les superhéros, clipo clipo dans l'outil graphique pour les 'utilisateurs lambda'.
J'utilise une slackware à la maison : cd d'install ou ftp, installpkg et c'est installé.
Il n'y a pas de paquet fourni par la distro ? wget trucmuche.tar.gz, tar zxf, ./configure, make; make install => ça marche dans 99% des cas. Si j'ai la forme, je fais même le paquet pour les copains slackeux.
La fonctionnalité essentielle, on a pas attendu rpm/deb pour l'avoir.
"ouais mais heu, il faut être informaticien pour arriver à compiler"
Oui et alors ? Soit tu choisis ta distro en fonction de tes besoins (comme par exemple les softs qu'elle intègre, la facilité d'installation de ces softs, etc) soit tu es un consommateur crétin et là, je ne vois pas pourquoi on devrait faire un effort puisque dans 5 minutes ce sera autre chose qui sera innaceptable, innadmissible et indigne d'une distribution gnagnagna.
Tant qu'on ne sait pas offrir ça, je ne vois pas comment on peut avancer sur le desktop grand public.
Et bien justement, beaucoup de distributions (la grande majorité même), ne visent pas le grand public. 90% des utilisateurs de linux en ont rien a faire du fait que linux soit ou non grand public tant que ça leur convient à eux... Pour ma part, je n'ai pas envie d'être emmerbété par des délire du style LSB (support RPM obligatoire, support init system V obligatoire, un rep /media qui fait bien rigoler....) juste parce que 4 tondus veulent voir linux sur les PC des autres.
Et les distributions qui visent le grand public (genre ubuntu, mandriva, debian...) fournissent déjà un système de type yum/apt pour installer sous format binaire en 2 clics de souris et s'efforcent de fournir le plus grand nombre de paquets binaires possibles.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 4.
En général pour rien. Pour la plupart des applications, les packageurs se contentent de recompiler. Dans beaucoup de cas, les logiciels ne sont même pas testés (je parle des contribs, pas des paquets au coeur de la distro).
Pas de chance, par exemple pour GCompris tu vas récuperer une version 8.2 qui date de 2 mois et qui contient des bug majeurs corrigé depuis. Pfiou, et après j'ai des utilisateurs qui me disent que GCompris plante ! C'est soit une mauvaise distro, soit le système de distribution des logiciels qui est à revoir. Moi j'ai choisi l'option 2.
C'est un non sens. Les utilisateurs ne savent pas à l'avance des logiciels dont ils ont besoin et il s'en crée tous les jours des nouveaux.
Choisir sa distro en fonction des logiciels quelle contient et une autre démonstration que le système de distribution des logiciels n'est pas satisfaisant.
Effectivement, je pense que Linux et les logiciels libres ont leurs place sur le PC de tout le monde, c'est pour ça qu'il faut trouver une solution à ce problème de distribution.
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 2.
Je choisis l'option 3 : si j'ai besoin de GCompris dernière mouture, c'est que la distro n'est pas adaptée à mes besoins.
Pas de chance, par exemple pour GCompris tu vas récuperer une version 8.2 qui date de 2 mois et qui contient des bug majeurs corrigé depuis.
Pire que ça je pense : j'utilise une FC4... :)
Mais si ce retard existe, ne serait pas parce personne n'est prêt à passer du temps à gérer le package Fedora ? Si oui, pourquoi un des développeurs de GCompris ne s'y collent pas ? Si c'est parce c'est trop lourd, pourquoi ne pas dire à tes utilisateurs râleurs que s'ils veulent une version à jour, ils doivent utiliser la distro X ou Y (celle qui supporte le mieux GCompris) plutot qu'utiliser Fedora ou encore compiler les sources ?
C'est un non sens. Les utilisateurs ne savent pas à l'avance des logiciels dont ils ont besoin et il s'en crée tous les jours des nouveaux.
Alors là, j'hallucine un peu. Pour moi c'est plutot le concept de "se créer des besoins" qui est un non sens.
Investir dans un matériel qui coute entre 50% et 100% d'un mois de salaire moyen sans savoir ce que tu vas en faire, c'est soit du hobbyisme, soit de la fièvre acheteuse et ça sort un peu du cadre "l'informatique est un outil qui répond à un besoin et pas une fin en soi". Or, il me semble un peu normal que ce soit au hobbyiste de se bouger pour avoir ce qu'il veut non ? Il faudrait pas non plus qu'on lui paye son abonnement ADSL tant qu'on y est ?
Tout travail mérite salaire : en fun, en femmes folles de nos beaux corps de geeks en gloriole ou en pognon ou ce que tu veux.
Par exemple, me trompè-je en supposant que si tu ne t'es pas toi même collé à la gestion d'un paquet Fedora alors que tu es développeur GCompris et que tu connais le problème, c'est parce que tu n'y trouvais pas ton compte et que tu préférais faire autre chose de plus fun/interessant/rentable autour de GCompris ?
Choisir sa distro en fonction des logiciels quelle contient et une autre démonstration que le système de distribution des logiciels n'est pas satisfaisant.
Il me semble que cette limitation n'est pas due a un problème technique. Comme je le disais au dessus, chaque distro est construite selon une philosophie (libre, simple, automatique...) et en fonction d'un but a atteindre (maléable, orientée utilisateur néophyte, informatique embarquée etc...).
Peux tu m'expliquer comment tu peux imaginer qu'un système universel de gestion de packages puisse exister en conservant l'actuelle diversité de distributions ? Et si tu trouves qu'une diversité de distributions (une balkanisation comme ils disent dans les livres) est néfaste, alors pourquoi s'occuper de porter ailleurs que sur la distro qui te semble la mieux ?
Ton systeme va imposer des contraintes pour certaines distributions en totale contradiction avec leur philosophie (comme le fait la LSB en demandant le support de rpm par exemple, ou l'existance de /etc/rc.X).
Appellons tes packages miracle Install++. J'utilise Barbux, distribution orientée dinos-qui-font-tout-à-la-main-sur-TI99-4A. Le fait même d'utiliser Install++ est en contradiction avec la philosophie de Barbux.
Si j'utilise Barbux et que je pleure que ça s'installe pas chez moi parce que y a une dépendance avec Install++, que vas tu me répondre ? Qu'Install++ n'est pas satisfaisant et qu'il faut aussi adapter GCompris (ça va être chaud de faire tenir l'interface dans 4Ko) ou tu va me dire qu'il faut pas abuser et qu'il faut que je me débrouille avec les sources ?
De toutes façons, au final, l'intéret d'Install++ sera amoindri puisque il existera des distros qui ne le supportent pas et il aura manqué en partie son but. Les seules distros qui le supporteront seront des distros aux buts et philosophies semblables (hohoho.ogg, il y en aura au moins 2 ou 3 j'espère :) ).
Au mieux, Install++ diminuera le nombre de boulets qui te gonfleront parce que "ça marche paaas" mais ça n'améliorera pas techniquement les systèmes actuels.
Everyone wants results, but no one is willing to do what it takes
to get them.
-- Dirty Harry
[^] # Re: Compilés statiquement
Posté par Zenitram (site web personnel) . Évalué à 3.
Parce qu'aucun developpeur n'a toutes les distribs?
Parce que c'est de la perte de temps de devoir tester sur toutes les distibs car il n'y a pas de standart d'install?
On dirait des anneries de quelqu'un qui n'a jamais eu des problèmes de developpeur, et qui sort des préjugés tous fait.
En face, il y a un gars qui sort un logiciel, et qui en chie pour.
Mais bien sûr, l'utilisateur il va changer de Distrib pour GCompris...
Mieux : si A fonctionne sur X et B sur Y, tu choisis X ou Y? les deux? super pratique ta solution irréalisable. C'est du n'importe quoi, c'est de la théorie fumeuse.
Le geek compile, l'utilisateur veut installer sans faire de technique.
Pour le moment, on pense déja à pouvoir seulement l'installer, sans respecter la philosophie, brut de fonderie, et c'est déja dur.
Bref, tu proposes des solutions (quoique...) non réalisables, qui ne réponde pas au besoin demandé : un gars tombe sur un site d'un logiciel, toruve les screenshots jolis, et veut essayer, et le developpeur ne veut pas devoir se taper un package par distrib.
La question reste toujours entière...
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 3.
Disons que j'ai eu des problemes de développeur (aucun depuis quelques années, certes) et que j'ai jamais voulu mettre la main dans des problèmes plus gros encore. Supporter 36 plates formes c'est un bordel infernal et ça demande pas mal de temps et de compétances que je n'ai pas et que je n'ai aucune raison d'acquerir.
Plutot que de mettre la main dedans, je préfere me restreindre à une seule plate forme. Et dans ce cadre, je trouve que les deux formats que je connais un peu sont assez bien foutus (rpm et tgz) et repondent plutot bien au problème pour lequel ils ont été conçus : installer un soft avec ou sans dépendances.
Parce qu'aucun developpeur n'a toutes les distribs?(...)standard d'install
N'est-ce pas ce que je dis ? Que tu préferes faire autre chose que de te taper un investissement trop lourd pour le gain que tu en retires ? Je ne connais personne capable de bosser longtemps pour rien.
En face, il y a un gars qui sort un logiciel, et qui en chie pour.
J'imagine très bien, mais je ne vois pas en quoi tu te devrais te sentir aggressé par mes propos. Loin de moi l'idée de dénigrer ton boulot (surtout que je ne connais GCompris que de nom).
Mais ce n'est pas parce que je respecte ton travail que je ne vais pas contester des idées que je trouve mauvaises surtout quand elles risquent d'avoir un impact sur ma vie a moi. Et franchement, s'il y a une idée que je trouve néfaste, c'est de faire croire que la technique (ou pire : l'ergonomie) peut dispenser d'un minimum de formation à l'usage d'un outil.
Quand je vois ce que cette fausse idée fait dans le milieu professionnel ou éducatif (par ex : mettre des gens derrière un ordinateur sans formation ou avec juste une 'formation bureautique'...), je me dis que sans elle je passerais plus de temps à coder qu'à décoincer des mulots.
Le plus grand mal qu'à pu faire le marketting à l'informatique, c'est de faire croire au grand public que c'est accessible sans effort. On a vu le résultat avec le HTML et les pages web => tout le monde à produit des pages web yahourt, ce qui entraine des problèmes techniques et amène à avoir des navigateurs monstrueux et qui au final ne sont quand même pas foutus d'afficher toute forme de HTML yaourt.
Il faut bien se mettre dans la tête qu'avoir une calculatrice ne rend pas mathématicien et que certains problèmes exigent des connaissances en math pour les résoudre.
Mais bien sûr, l'utilisateur il va changer de Distrib pour GCompris...
S'il en a vraiment envie : oui. Sinon non et il se débrouille. Ils sont bien passés à Windows XP ou Linux trucmuche parce que c'est plus chouette ....
Et puis, ma solution irréalisable c'est celle qu'on utilise en production parce que s'il y a un réel besoin alors on se donne les moyens de le satisfaire. Si on se les donne pas : soit on s'en passe parce qu'on juge le besoin non rentable à satisfaire, soit c'est un projet foireux.
Le geek compile, l'utilisateur veut installer sans faire de technique.
L'utilisateur il veut un peu le beurre et l'argent du beurre. Je ne vois pas en quoi c'est un dû que ce soit toi qui te bouges le cul pour qu'il puisse satisfaire ses caprices. Or j'ai l'impression que beaucoup prennent la chose comme ça.
Je ne dis pas qu'il faut lui mettre des bâtons dans les roues et l'empêcher d'accèder à ce qu'il veut. Je dis que plutot que de te pourrir la vie à lui faire de l'assistanat et à le rendre dépendant d'outils particuliers, il faut l'aiguiller vers de la formation et le responsabiliser.
Chacun fait un pas vers l'autre et c'est mieux pour tout le monde :
- tu as des utilisateurs moins boulets et tu peux te concentrer sur ce qui te plait
- tes utilisateurs ne dépendent ni de toi, ni des quelques programmeurs de Install++ et de leur bon vouloir.
Pour le moment, on pense déja à pouvoir seulement l'installer, sans respecter la philosophie, brut de fonderie, et c'est déja dur.
Beh je comprend tout à fait que tu aies d'autres chats à fouettter que de t'occuper de packages Fedora. Je te souhaite de trouver rapidement une solution à tes problèmes.
un gars tombe sur un site d'un logiciel, toruve les screenshots jolis, et veut essayer, et le developpeur ne veut pas devoir se taper un package par distrib.
Je trouve que ce sont deux problèmes distincts et que ma solution non technique est réalisable pour pas cher en plus de répondre aux deux problèmes :
- je conseille l'utilisateur de se tourner vers des logiciels qui correspondent plus à sa manière de fonctionner (installer les trucs rigolos qu'il voit sur le net) puisque c'est ce qu'il lui semble important
- le développeur n'a plus a se taper un package par distrib : il s'occupe des fonctionnalités son soft plutot que de problèmes de portage. Si quelqu'un trouve -vraiment- dommage que le logiciel n'apparait pas dans sa distrib il se débrouillera pour trouver une solution globale ou individuelle.
Du travail collaboratif efficace en quelque sorte : chacun s'occupe du problème qui l'interesse le plus.
N'est-ce pas ainsi que ça fonctionne déjà ? J'espère que ce ne sont pas les développeurs du noyau ou de xorg qui s'occupent des packages des différentes distribs...
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 2.
[^] # Re: Compilés statiquement
Posté par ʭ ☯ . Évalué à 3.
J'ai un ordinateur avec GNU/Linux. Tout va bien, mais comment m'installer Rosegarden? Zut, c'est pas dans la liste des programmes disponibles.
1. Je change de distribution, cad que je paie quelqu'un pour m'installer le navigateur et rosegarden.
2. Je me mets pas à la musique.
Je veux Gcompris, mais il plante dans la version de mon ordi.
1. Je paie quelqu'un pour me configurer l'ordinateur pour utiliser Firefox + Rosegarden + Gcompris.
STOP! J'ai trouvé : Linux est prêt pour le public, si celui-ci accepter d'acheter un service plutôt qu'une boiboîte : 60 ¤ pour une install de logiciel libre plutôt que 60¤ pour l'équivalent proprio. Oui, mais les logiciels piratés sont gratuits, eux. Donc le libre peut coûter plus cher au "grand public".
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 4.
Surtout que bon, je ne vois pas pourquoi un guitariste aurait besoin de savoir tendre des cordes : il est là pour jouer pas pour réparer des guitares...
Passer du temps à apprendre à connaitre, changer et tendre des cordes de guitare pour pouvoir en jouer te semble-t-il quelque chose de normal ?
Ou préfèrerais-tu qu'on te donne systématiquement avec chaque guitare le service du changement de corde et là maintenant sur le champ ? Et ce, même si tu joues de la guitare avec un caillou pour médiator ?
J'imagine qu'on préfère souvent la solution 2, mais bon on n'est pas dans le monde des bisounours.
Je te ferais remarquer que le problème du nouveau besoin :
1- n'est pas lié au libre : j'ai acheté un mac et j'ai besoin d'MS Access un an plus tard pour mon stage, je fais comment ? Je vais a la fnac et je leur dit que la fnac c'est mal foutu parce qu'il n'est pas marqué que sur mac il n'y a pas access ?
2- n'est pas lié à l'informatique : je n'ai qu'une moto et je deviens papa de triplés, je jette mes gosses ou je passe le permis et j'achète une voiture pour pouvoir les balader ? (investissements financiers et personnels sans retour garanti : tu peux échouer au permis)
Pourquoi dans ces cas là ça ne pose de problème à personne ? Un changement de besoins (réels ou artificiels) entraine un systématiquement un investissement de la part de la personne. Ca ne choque personne (enfin j'espère).
Explique moi pourquoi en informatique ce serait différent ? Qu'est-ce qui fait qu'en informatique tout est possible (et particulièrement quand ce n'est pas à toi de réaliser la solution miracle) ? Ne te vient-il pas à l'idée que l'informatique est soumise à des contraintes et que tout n'est pas possible ?
Certaines contraintes sont mathématiques (mais heu pourquoi vous n'êtes pas foutu de me pondre un logiciel qui me donne l'emploi du temps optimal ?), d'autres humaines (mais heu pourquoi le soft que vous faites pour le fun il ne correspond pas à mes besoins à moi ?).
Pour ma part je suis intimement convaincu que certaines choses ne sont pas sollutionnables (c'est moche mais français :) ) par une pirouette technique y compris en informatique mais qu'elles se règlent avec un minimum de formation.
1. Je paie quelqu'un pour me configurer l'ordinateur pour utiliser Firefox + Rosegarden + Gcompris.
Bah oui. Ou tu le fais toi même, ou tu trouves quelqu'un qui à la gentillesse de te le faire. Dans ce dernier cas, rappelle toi que ce n'est pas un dû. Ce n'est pas parce que le ton voisin est maçon tu as le droit d'exiger de lui qu'il t'agrandisse gratos la maison comme tu le souhaites sous prétexte que tu as lu quelque part que monter des parpaings c'est à la portée du premier crétin venu.
Quand à la fin du message, si le grand public vient sur du libre parce que c'est gratuit, faudra lui expliquer qu'il se fourre le doigt dans l'oeil.
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Pour les problème technique, je ne suis pas en expert. Si tu es a compris pourquoi c'est important, c'est déjà une bonne chose, il y a des gens très compétents dans le monde Linux qui j'en suis sur vont prendre ce probleme à bras le corps et venir avec des solutions.
Ce qui m'enerve le plus ce que nous nous persuadons tous que la situation actuelle est optimale et tolérable pour les utilisateurs grand public.
[^] # Re: Compilés statiquement
Posté par CrEv (site web personnel) . Évalué à 2.
- compiler gcompris sous fedora core 4
ou
- faire un paquet pour fedora core 4
?
Car ce n'est pas du tout la même chose...
Si c'est la première solution, le problème est donc que gcompris ne peut pas s'installer avec les version de fc4. Si c'est le deuxième points, alors c'est étrange car en général ce qui se compile se met en paquet (assez) facilement.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 2.
tu m'expliques comment un système de distribution des logiciels va régler ça ?
> > Soit tu choisis ta distro en fonction de tes besoins
> C'est un non sens. Les utilisateurs ne savent pas à l'avance des logiciels dont ils ont besoin et il s'en crée tous les jours des nouveaux.
> Choisir sa distro en fonction des logiciels quelle contient et une autre démonstration que le système de distribution des logiciels n'est pas satisfaisant.
ben justement si, si tu n'en sais pas plus tu en prends une grand public avec une bonne présence en France pour diverses raisons et tu évites une distribution spécialisée chilienne ou du viet-nam. quand tu prends une voiture tu fais pareil... ou tu devrais.
[^] # Re: Compilés statiquement
Posté par B16F4RV4RD1N . Évalué à 1.
ben justement, toi tu t'en moques et cela ne te concerne pas car justement si tu as une plateforme matérielle farfelue, c'est que tu aimes bien mettre les mains dans le cambouis et tout recompiler toi-même, donc cela ne sera pas un facteur limitant pour toi
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: Compilés statiquement
Posté par Toufou (site web personnel) . Évalué à 2.
Doit-je comprendre que ceux qui ne comprennent pas l'intéret de la compatibilité au niveau source vont nous réinventer une compatibilité binaire en moins bien ?
[^] # Re: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 4.
[^] # Re: Compilés statiquement
Posté par Zenitram (site web personnel) . Évalué à 2.
Je dirais plutot qu'on veut un truc qui s'installe facilement partout, sans ligne de commande.
Binaire ou source, à la limite source c'est mieux pour l'optimisation tout ca...
Mais l'utilisateur ne doit faire que "cliquer" sur un fichier executable, et hop installé, avec au pire un ecran d'avancement sans aucun mot technique.
[^] # Re: Compilés statiquement
Posté par Misc (site web personnel) . Évalué à 1.
Pour faire faire un truc, dans le libre et ailleurs, soit tu réussi à convaincre les gens, soit tu le fait.
Convaincre les gens, ç'est soit les payer, leur ordonner sur la base de ton autorité, ou les convaincre avec des arguments percutants.
Et si ça marche pas, le libre te laisse la possiblité de faire les choses toi même.
Comme pour le moment, l'option 1 ne marche pas, il te reste l'option 2. Si tellement de gens veulent ça et on déja réfléchit au probléme, alors, ça devrait pas être compliqué de trouver de l'aide parmi toute ces personnes.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 0.
j'ai du mal à voir comment on peut me dire qu'un BSD, ou un Solaris, ou un BeOS c'est farfelu et donc ma croix ma bannière et qu'ensuite on vienne me dire que mémé ne doit pas s'embeter à devoir choisir son Linux un minimum parce que ca doit marcher et puis c'est tout.
et puis euh bon, je me demande comment on peut faire une lecon à grand-mere de pas installer un .exe qui traine sur internet, mais un .rpm isolé et déconnecté de toute certification ou recommandation indépendante sur un site inconnu, tout va bien
[^] # Re: Compilés statiquement
Posté par B16F4RV4RD1N . Évalué à 0.
Ou alors elle a trouvé cela dans le grenier ?
Et si elle trouve un jour client irc qui n'écrit qu'en utf8, tu la kickes quand même ?
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: Compilés statiquement
Posté par Gniarf . Évalué à 1.
là on veut me faire croire que Mémé peut se retrouver sous "Linux" par miracle, accident ou installation par son petit Benjamin et ensuite qu'elle doit pouvoir se débrouiller toute seule comme une grande avec sa box sans jamais rien lire ou apprendre d'autre que cliquer sur un menu "installer des logiciels".
et en particulier ne pas se contenter des softs proposés par sa distribution, d'éventuelles sections "contrib" packagés par des tiers mais toujours pour sa distribution, ou du "click-and-run" prémaché genre Lindows/Linspire.
là vous lui demandez de pouvoir installer le premier package binaire venu sur Interneeeet, sans le moindre garde-fou.
comme sous Windows en fait.
et que tout se passe bien.
et vous trouvez que c'est une bonne idée, et que c'est même indispensable. pour sa liberté et son confort
moi je dis "foutaises".
[^] # Re: Compilés statiquement
Posté par B16F4RV4RD1N . Évalué à 2.
on demande juste 2 choses, c'est :
1/ que des applications sous forme klik ou autopackages soient plus généralisées pour aider ceux qui démarrent avec linux à ne pas se prendre la tête à compiler le programme, car parfois ce n'est pas juste un configure make make install. Par exemple au début cela ne fonctionne pas parce qu'il faut le paquet sdl-devel, et une fois ce dernier installé, cela ne fonctionne toujours pas parce qu'il faut également compiler la bibliothèque jacklib-midi-kazoo-soundfont-devel, qui manque de chance n'est pas dans les dépôts de sa distribution, et dépend de perl-xml-infinitesimal-algebra-parser, elle non plus absente de la distribution... etc.
2/ que ces applications binaires puissent trouver des dépôts sûr par exemple sur sourceforge, et de toute façon qu'elles ne s'installent que dans l'espace utilisateur, et non pas sur tout le système (cf. klik). Ce qui limiterait les risques de malware, après on ne peut pas empêcher n'importe qui de proposer des paquets peu sûr, si les gens installent tout et n'importe quoi à tout et à travers, effectivement cela deviendra comme windows. Il y a encore des gens qui s'installent des spywares alors qu'ils pourraient trouver de meilleures applications sur framasoft.net . Mais même un script shell cela peut compromettre toute une machine.
Ce qui n'empêchera pas des paranoïaques comme toi de continuer à compiler depuis les sources (que tu audites sans doute avant d'installer) si cela leur chante, ou d'utiliser les dépôts de leur distribution (avec clés rsa, pgp etc)
Et laisse mémé tranquille, elle est en train de finir de tester le nouveau amiga one qu'elle va t'offrir à noël, face de poulpe.
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: Compilés statiquement
Posté par Thomas Douillard . Évalué à 1.
Tu peux m'expliquer la différence entre compiler le premier logiciel venu sur le net et installer le premier binaire venu, pour quelqu'un qui a bêtement appris la procédure de compilation sans se poser de questions ? et oui, c'est possible. Il y a pas beaucoup plus de gardes feux dans un cas que dans l'autre.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 1.
dans un premier temps, oui. quand tu as appris à faire du vélo on t'a mis deux petites roues pour stabiliser ta conduite, on te les a enlevé plus tard. pareil ici, tu regardes ce que le CD t'a installé, tu regardes ce que le site de la distribution propose d'autre, et ensuite seulement tu pars à l'aventure.
si tu commences de suite à vouloir installer des bidules à moitié morts comme egoboo ou ularn, ou des trucs avec 53 dépendances qui seront en avance ou en retard sur ta distribution, forcément, la pente sera rude.
et dans ce cas, tu ne vas plus prétendre être un utilisateur qui se fout de l'informatique comme de leur première culotte. pareil que d'essayer d'installer Oracle sans connaitre la moindre commande d'administration système
> Tu peux m'expliquer la différence entre compiler le premier logiciel venu sur le net et installer le premier binaire venu, pour quelqu'un qui a bêtement appris la procédure de compilation sans se poser de questions ?
le problème est que tu parles d'un site inconnu/pas de confiance, ce n'est pas un problème de compiler ou pas compiler. si ton utilisateur est un con à tendance jean-kevin qui veut installer un truc marqué super elite tool de naxor, ben on ne peut rien pour lui. et on parle justement d'utilisateurs je-clique-sur-tout-ce-qui-bouge
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 2.
Non, on parle d'utilisateurs qui ont une bonne raison d'installer un logiciel pas packagé.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 1.
et le comportement évoqué au début est bien un "je clique sur tout ce qui bouge et surtout sans réflechir, je veux utiliser mon ordinateur et surtout pas mon cerveau, apprendre le minimum est déjà de trop, bouh pourquoi ca marche pas ouin ouin c'est de la merde linux vive windows"
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 2.
Un truc marginal veut pas nécessairement dire "le truc de jacky qui sert à rien." Là, ce genre de solution a l'air intéresant : simplification du boulot pour le concepteur du logiciel, installation en quelques clics pour l'utilisateur.
[^] # Re: Compilés statiquement
Posté par Juke (site web personnel) . Évalué à 3.
Tu apprends à le faire toi même ?
Tu le compile à l'arrache ?
Tu utilise autre chose ?
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 3.
Indice : la balance penche plus vers les gens qui y conaissent rien à l'info que vers les autres. Alors si tu veux te déplacer/ qu'on t'apelle pour installer un logiciel à chaque fois en tant que spécialiste du quartier, libre à toi. Perso je préfère faciliter l'autonomie des gens en leur simplifiant la vie.
Le "tu utilises autre chose" est un pis aller qui consiste à ne pas répondre au problème, et qui n'es pas forcément aplliquable de surcroit. L'autre chose peut être "un système proprio" dans ce cas.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 2.
je me prends par la main et je me procure ces poulpes autrement tout en blindant l'aquarium en question parce qu'ils vont faire des ravages.
et si je veux euh disons Access sur disons un Macintosh avec euh MacOS 9 ? là c'est pas un soft marginal et l'éditeur est connu.
ben là je peux pas.
le monde est imparfait, faudra faire avec. si tout le monde se fout de ce soft pourtant si interessant pour toi il va falloir payer de ta personne, en te mettant au boulot toi aussi ou en incitant quelqu'un d'autre à le faire, éventuellement contre finances ou diverses faveurs culinaires. si ça te fait reculer, c'est qu'il n'était finalement pas si interessant que ça.
surtout je ne vois pas ce que klik ou autopackage va changer si ton soft est tellement marginal qu'aucun libriste ne prendra la peine de faire des paquets pour ces bidules, et encore moins l'auteur du logiciel. là, tu fais quoi ? à part être un gros nazi et les harceler en leur cassant les couilles parce que toi tu as une super solution super maligne super intelligente mais que ce n'est super pas à toi de t'y coller.
ils sont déjà au courant de ces initiatives, rassure-toi. si ça ne les interpelle pas plus que ça, s'ils ne sont pas convaincus, s'ils ont d'autres priorités, s'ils sont déjà surchargés, ce n'est pas la solution technique en elle-même qui va régler ces problèmes humains de manque de ressources.
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 2.
Et si une solution technique permet de réduire ces efforts pour tout le monde, tu dis merde ?
T'as pas compris le principe. C'est plus simple pour un développeur de faire UN package, genre klik ou autopackage, que 50 pour 50 distributions. Il le fera sans doute plus volontiers si le système en question marche, est répandu (installé par défaut dans la distrib par exemple.)
L'informatique en entier n'est-elle pas une solution technique à un manque de ressource, à la base au moins ?
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à 1.
si ça me semble une solution de merde, je ne vais pas me gêner. mais la discussion a dépassé ce stade.
T'as pas compris le principe. C'est plus simple pour un développeur de faire UN package, genre klik ou autopackage, que 50 pour 50 distributions. Il le fera sans doute plus volontiers si le système en question marche, est répandu (installé par défaut dans la distrib par exemple.)
prends moi pour un âne aussi. le fait est que ton petit développeur va avoir ses priorités comme mettre à jour son site web du projet et lire son courrier et continuer à avancer. c'est un être humain, son temps est limité, il est débordé. tu dis qu'un paquet klik ou autopackage lui fera gagner du temps par rapport à 50 paquets pour 50 distributions mais pour commencer il ne fera PAS 50 ni même 5 ou 2 paquets bien propres. s'il fournit un .deb et un .rpm en même temps ça va déjà être un sacré mutant. alors de la même façon qu'il ne fait pas ces 50 paquets, il ne fera un paquet klik que s'il a le temps de le faire et si pour diverses raisons ça apparait au sommet de sa pile de choses à faire, pile déjà très très haute. et si lui ne fait pas de paquet klik et personne d'autre non plus ben le souci sera toujours là.
vos klik-évangélistes il faut qu'ils fassent eux-même ces paquets klik au moins au début pour fournir un squelette au développeur plutot que crier partout "klik est grand ! gloire à klik !" et ne rien faire de concret parce qu'ils estiment que c'est à chaque développeur de pondre un paquet klik et que c'est trop compliqué de s'impliquer dans chaque petit projet à comprendre comment le compiler et l'installer alors qu'on est finalement en train de parler d'un 233ème Tetris ou de projets nettement à la rue.
ce n'est pas à ces promoteurs de klik ou autopackage de faire des paquets ou d'aider les développeurs isolés parce que en gros ils ne savent pas faire et que de toute façon c'est trop de boulot à aller contacter tous les petits projets un par un ? bah pourquoi ça serait au développeur de le faire si lui le place en 437ème position sur sa liste de choses auxquelles penser un jour ? juste parce que c'est plus pratique d'imaginer ça comme ça dans ce plan idéal de domination du monde ? c'est comme vouloir l'envoyer prendre des cours de dessin parce que son jeu est moche au lieu de lui fournir des graphismes.
votre croisade c'est comme essayer de convaincre les auteurs de projets qui ont leurs propres sites web de faire des pages conforme au W3C - ou de remplacer les GIF par des PNG à l'époque de cette grande croisade. pour ceux à qui ça ne parle pas, pour ceux qui n'auront pas le temps, ce genre de demande passera nettement en dernière position, voire à la trappe. malgré les meilleures raisons du monde.
[^] # Re: Compilés statiquement
Posté par Thomas Douillard . Évalué à 2.
C'est amha simplement le genre de truc qui peut s'imposer si ça devient populaire auprès des utilisateurs. Genre à terme ça peut s'intégrer à des IDE orientés ll genre kdevelop. Si il n'y a qu'un système de ce genre populaire, l'hypothèse devient très plausible, il y a déja des trucs pour générer des tar.gz sources de ce genre.
Pour prendre l'exemple de windows, personne imagine distribure un logiciel sans faire au minimum un .zip, ou un installeur .exe dans l'immense majorité des cas. Un système incontournable de distribution en attendant la consécration d'être intégré dans les distribs.
(ceci était de la science fiction)
[^] # Re: Compilés statiquement
Posté par Misc (site web personnel) . Évalué à 2.
je propose même de dire que tout les softs trop gros pour passer sur un 56k sont non libre ( ah on me dit dans l'oreille que ç'est pas le sens qu'on entends d'habitude, et que ça fait pas sérieux d'essayer de faire une confusion à ce niveau )
[^] # Re: Compilés statiquement
Posté par B16F4RV4RD1N . Évalué à 4.
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: Compilés statiquement
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
Ce n'est peut être pas optimal mais l'utilisateur s'en fout. Au moins il peut utiliser le logiciel qu'il vient de voir sur un site.
Ce qui n'est pas optimal c'est la situation actuelle ou il faut attendre qu'une tierce personne ai l'envie et les compètences de faire un paquet pour ta distribution pour pouvoir enfin installer un logiciel.
[^] # Re: Compilés statiquement
Posté par Gniarf . Évalué à -2.
[^] # Re: Compilés statiquement
Posté par Misc (site web personnel) . Évalué à 2.
> tierce personne ai l'envie et les compètences de faire un paquet pour ta
> distribution pour pouvoir enfin installer
Tout comme il a fallu attendre qu'une tierce personne fasse la distribution en elle même, les tests, compile, et qu'une autre tierce personne fasse le soft.
Et en vérité, que plus d'une tierce personne pour tout ça.
Et pourtant, personne ne va dire "la programmation, c'est pas optimal, faut encore que quelqu'un fasse les programmes pour l'utilisateur". Alors qu'il y a également une dépendance sur les tierces personnes ( les dévelopeurs en l'occurence ).
# PC-BSD ?
Posté par Anthony F. . Évalué à 1.
Sous Linux il me semble qu'il existe autopackage et un autre dont le nom m'échappe.
[^] # Re: PC-BSD ?
Posté par Manger sur pattes . Évalué à 1.
# J'utiliserai Wine
Posté par Vador Dark (site web personnel) . Évalué à 5.
# quel jeu ?
Posté par BAud (site web personnel) . Évalué à 3.
# Multiples paquets
Posté par grognon . Évalué à 10.
Je ne sais pas ce que l'avenir nous réserve, mais j'espère que les distributions se mettront un jour ou l'autre autour d'une table pour attaquer vraiment le problème. Sans vouloir polémiquer, je trouve que le système actuel n'est pas bien loin de rendre "captifs" les utilisateurs et les développeurs, et je rêve d'un monde linux "libéré" de ces incompatibilités. ça viendra, j'en suis sûr, mais il va falloir être patient.
[^] # Re: Multiples paquets
Posté par manatlan (site web personnel) . Évalué à 2.
J'ai reussi à faire un package deb, en hackant un deb existant ;-)
(maintenant je pourrai faire mieux en suivant ce tuto : http://showmedo.com/videos/video?name=linuxJensMakingDeb&(...) )
Le rpm est généré en alien'ant le deb (et pose prob sur certaines distribs)
Après c'est des contribs (arch, ebuild, ...)
Je ne me vois pas générer chaque type de paquet et tester dans une VM chaque paquet pour sa distrib ...
ce n'est pas "smart" qui est censé réglé ce prob à terme ?
[^] # Re: Multiples paquets
Posté par Anonyme . Évalué à -2.
Vous croyez quoi ? qu'un logiciel se développe avec un petit amateur dans son coin qui fait tous les paquets grâce aux 50 distribs installées sur son PC ?
Ben non, sa se passe pas comme sa le développement logiciel, on appuie pas sur F7 pour avoir un joli binaire qui passe partout : il faut du travail et des contributeurs pour développer un logiciel digne du nom.
J'ai vraiment l'impression que ce journal n'est visité que par des gens qui développent en java sous windows.
[^] # Re: Multiples paquets
Posté par Bruno Coudoin (site web personnel) . Évalué à 3.
[^] # Re: Multiples paquets
Posté par Zenitram (site web personnel) . Évalué à 3.
On lit vraiment de tout... Montre-nous ce que tu as fait, on en rediscute.
Bruno, lui, est face à des problemes, pas theoriques.
Alors, pour reprendre ton alusion, une fois le soft developpé, on appuie effectivement sur F7 pour avoir un truc facilement installable sur 95% des clients. Après, on en chie à devoir se coltiner tous les pckages pour X distrib, chacune reprensentant un faible pourcentage.
C'est une énorme perte de temps, ca gave, point.
Vous voulez avoir un Linux chez tout le monde? Ne continuez pas à sous-estimer les logiciels hors distribs, c'est cette communauté la qui fait vivre MS, qui fera fuir un client lambda qui aura trouvé LE petit logiciel pratique qu'il ne veut pas quitter, et dont le developpeur en a mare des geeks linuxiens qui ne savent meme pas pondre un standart d'installation.
[^] # Re: Multiples paquets
Posté par Anonyme . Évalué à 1.
C'est dommage d'ailleurs, moi même je n'ai aucun moyen d'évaluer la pertinence de vos commentaires.
[^] # Re: Multiples paquets
Posté par Gniarf . Évalué à 1.
bravo, tu as isolé le problème. ce sont ces cons de codeurs du dimanche qui refusent de se rendre compte des difficultés logistiques de la distribution de logiciels et croient que quelques conventions magiques vont tout régler au lieu d'essayer de se trouver de l'aide sous forme de quelques gentils packageurs et de voir avec eux pourquoi parfois ils n'arrivent pas à faire un beau paquet bien propre. parce que des fois l'appli elle sera franchement bancale si intégrée telle quelle dans la distribution.
et en plus ils préfèrent faire des versions Windows parce que c'est plus simple. sales traitres !
qu'on les fusille !
[^] # Re: Multiples paquets
Posté par Gniarf . Évalué à 0.
> On lit vraiment de tout... Montre-nous ce que tu as fait, on en rediscute.
et vlan, une attaque ad hominen, ca manquait.
> Bruno, lui, est face à des problemes, pas theoriques.
> Alors, pour reprendre ton alusion, une fois le soft developpé, on appuie effectivement sur F7 pour avoir un truc facilement installable sur 95% des clients. Après, on en chie à devoir se coltiner tous les pckages pour X distrib, chacune reprensentant un faible pourcentage.
> C'est une énorme perte de temps, ca gave, point.
c'est parce que tu es à coté de tes pompes. développer un soft pour chez toi ca va effectivement être 95 % du boulot, maintenant si tu veux que d'autres l'utilisent, tu vas te rendre compte que le développement c'est juste 30 % du boulot. ou même moins.
et le reste c'est le rendre disponible pour les autres et assurer le support derrière, même si c'est juste un forum ou une mailing list. parce que quand ton truc va merdouiller ici ou là pour une raison inconnue, les rigolades vont commencer.
si tu trouves que ca te gave et que c'est une énorme perte de temps, si ça ne t'interesse pas, ne t'en occupe pas, ce n'est pas plus compliqué que ça. d'autres viendront bien tirer les marrons du feu si ça les interesse. mais si ça ne t'interesse pas, ne viens pas prétendre que tu souhaites que tout le monde utilise ton soft, hein, faut pas s'arreter comme ça au milieu du chemin, bonhomme.
[^] # Re: Multiples paquets
Posté par taratatatata . Évalué à 0.
Faudra pas s'étonner si Windows et OSX sont les plateformes majoritaires sur le desktop.
[^] # Re: Multiples paquets
Posté par Gniarf . Évalué à 1.
et qu'il y a plus d'une centaine de Linux si on commence à détailler les différentes versions successives de distributions majeures, les bureaux utilisés, parce que grand-mère elle ne va pas jeter sa Mandriva de l'an dernier qui marche très bien juste parce que le temps passe et qu'une nouvelle vient de sortir. surtout si c'est fiston qui lui a installé.
[^] # Re: Multiples paquets
Posté par Misc (site web personnel) . Évalué à 2.
Oui, et les distributions vivent dans un monde de bisounours avec des problémes purement théoriques ?
Ce qui pose probléme à bruno, c'est qu'il y a un truc entre lui et l'user, et qu'il a pas le controle de ce que fait ce truc. La seul chose qu'il controle, c'est le code source de son soft.
Les problémes que je lit, c'est "on peut pas faire un binaire qui tourne partout". Pourquoi ? Parce que les binaires dépendent de libs différentes.
Donc le probléme vient pas des distributions, mais des libs.
Soit des libs qui changent d'abi tout les 2 mois, auquel cas ils devraient voir avec les développeurs, soit des libs qui restent compatibles, mais qui rajoutent des nouvelles fonctions dispos que dans la derniére version, auquel cas, il devrait voir avec lui même pour ne pas utiliser les fonctions sauf si elles sont suffisament répandus.
Taper sur les distributions qui donnent du temps pour distribuer les logiciels, c'est n'importe quoi et légerement ingrat.
Du point de vue d'un développeur isolé, ça semble simple : "tout les distros incluent les deps de mon soft, et voila".
Sauf que ... des developpeurs, il y en a des tonnes. Et chacun a son avis différents sur ce qu'il faut utiliser comme version, pour des raisons X ou Y, parfois fondé, parfois pas.
Alors, avant de taper sur les distributions pour leur demander de faire leur 4 volontés parce que c'est les devs, les devs devraient d'abord se mettre d'accord entre eux. Les distributions sont la pour harmoniser le bordel crée par les devs, pas par elle-mêmes.
Chacun est libre de faire le travail qu'il veut, de la façon qu'il veut.
Si une distribution n'étant qu'un socle de base serait si utile, pourquoi personne n'en a fait une ?
Et si par hasard quelqu'un en a fait une, pourquoi
1) elle n'a pas décollé
2) les développeurs ne se sont pas fédéré autour de cette distribution ( en partant du principe qu'une majorité de devs partage les opinions de bruno, ce dont je doute aussi ).
[^] # Re: Multiples paquets
Posté par taratatatata . Évalué à 1.
[^] # Re: Multiples paquets
Posté par manatlan (site web personnel) . Évalué à 4.
j'ose esperer que tu blaguais ...
Pour ma part (jbrout), c'est un programme que je faisais uniquement pour moi et mes besoins. Puis je me suis dit que ça pourrait peut être servir à d'autres ...
Et c'est là, que ça commencé à se compliquer. Alors si en plus de coder son appli, il faut en plus s'occuper du site, s'occuper des news, manager le forum, répondre aux mails/questions, et en plus packager pour chaque distrib ... c'est 80% de COM, 20% de codage ...
On s'en rends pas compte de suite, mais rien que releaser en gpl, c'est un boulot de ouf ... Si en plus faut se coltiner chaque distrib, chaque type de paquet et les moults dépendances, c'est énorme.
Certes je me suis interessé à essayer de faire un paquet deb, pk qqpart ça m'interessait (pk ces les paquets de ma distrib), mais tu n'imagines pas à quel point, faire un paquet rpm ou arch ça ne m'interesse pas (et je me force, à contre coeur, à faire un paquet windows (alors que je n'ai même plus windows) uniquement pk c'est historique (mon prog ratissait win au début des temps))... (et pour ta gouvernes, qu'on utilise ou pas mon programme, tu n'as pas idée à quel point ça me passe au dessus de la tête ...). Par contre je suis hyper reconnaissant des apports envoyé par la communauté (autres paquets, doc, support ...), et ça, ça me motive ...
# autopackage !
Posté par snt . Évalué à 4.
[^] # Re: autopackage !
Posté par B16F4RV4RD1N . Évalué à 3.
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
# La joie de Linux...
Posté par Zenitram (site web personnel) . Évalué à 2.
Il faut en permanence adapter, autoconf ne faisant pas tout.
Et surtout, "tape make, make install", ca fait vraiment... Geek.
Bon, les gars de http://autopackage.org/ ont l'air de se dire la même chose, j'ai pas encore testé car pour le moment ce que j'ai sorti en Linux est trop en version "beta", mais je pense que c'est la bonne solution pour sortir de l'univers "geek".
Notamment utilisé par Gaim.
# Distribution GNU/Linux = plate forme fermée
Posté par Bruno Coudoin (site web personnel) . Évalué à 6.
Je vois maintenant, les distributions comme des plates-formes fermées. On peut y installer tout les logiciels que l'on désire, à condition qu'ils soient fournis par votre distribution. C'est assez limité. Même si on trouve le logiciel dont nous avons besoin, c'est parfois des version anciennes ou trop récente.
Je me rend compte que le système de packaging n'est pas adapté au grand public, il est parfait pour gérer la base d'un système d'exploitation, mais pas pour que les utilisateurs puissent installer rapidement et facilement n'importe quel logiciel.
D'un point de vu développeur, le packaging des distros pose aussi un problème. C'est un intermédiaire entre le projet et l'utilisateur. Dés lors, l'utilisateur ne sais plus ou reporter son problème, est-ce un problème du logiciel de la distro ou du packaging. En plus cela crée un délai inutile, par exemple sur GCompris, entre le moment ou un utilisateur recoit un logiciel via sa distro, il est courant que nous ayons déjà sortie une nouvelle version.
Autre problème, seules les versions stables sont packagées. Cela limite la collaboration avec nos utilisateurs car il ne savent pas compiler. Donc on fait des beta qui ne peuvent pas être testé pas nos utilisateurs.
Depuis quelques mois, nous livrons un paquet au format autopackage. Ce n'est pas parfait mais au moins cela permet à nos utilisateurs de pouvoir utiliser notre logiciel, quelque soit leur distribution.
La guerre fait rage entre ce type de packaging alternatif et les distributions qui voient d'un mauvais oeil que des logiciels soient installé hors de leur système de paquet. Idéalement il faudrait installer les logiciels ailleurs que dans /usr mais malheureusement, les distros ne le supporte pas ou mal. Très difficile de faire apparaisse un logiciel dans le menu s'il n'est pas installé dans /usr.
Un espoir vient du coté du LSB qui prend le problème très au sérieux. La proposition pour résumer et de créer un système de packaging de second niveau qui utiliserait une API fournie pas celui de premier niveau pour installer et gérer les logiciels. On pourrait alors installer un paquet multi-distro à condition que le système de paquet principal implémente bien cette API.
Vous pouvez en savoir plus sur cette approche sur le blog de Ian Murdock http://ianmurdock.com/?p=388
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par CrEv (site web personnel) . Évalué à 4.
Au contraire, pour quelqu'un qui n'y connait vraiment rien c'est hyper simple. Il click sur son icone "Installer des logiciels", le choisi et hop c'est fini.
Maintenant évidement s'il veux "n'importe quel logiciel" c'est une autre histoire.
Mais pour les besoins classiques, pour quelqu'un ne connaissant pas grand chose ça va tout seul.
C'est pour ça que très souvent, l'utilisateur reporte son problème sur la distro, ce qui indique au packager le problème qui lui le règle si c'est un problème de package ou remonte vers les développeurs (ou redescend les patch). En tout cas c'est comme ça que je le vois.
Alors là par contre, je trouve cela vraiment tout à fait normal.
Pour moi une version en développement ne doit être packagée que pour des distrib en développement ou des utilisateurs compétants (pouvant en fait eux même compiler ou packager en réalité).
Je ne sais pas trop ce qui se passe mais depuis quelques temps, on voit fleurir des beta pour le grand public (google en tête, suivi par crosoft, adobe, ...)
Je trouve ça complètement idiot et surtout très bon pour flinguer direct un soft
- c'est de la merde ça plante
- normal c'est une beta
- une quoi ? je sais pas moi j'ai trouvé dans la rubrique téléchargement, c'est la dernière version et y'a rien qui marche !
Sinon (cette partie s'adresse plus au journal en lui-même) il "suffit" parfois de demander si quelqu'un voudrais pas faire un paquet d'un logiciel donné pour une distrib donnée. Je pense qu'il peut toujours y avoir quelqu'un intéressé par le logiciel et ayant les compétences pour le packager... outre le fait que ça profiterai à un plus grand nombre
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
Ben oui, l'utilisateur il veut ça, et il a raison. Il n'a pas envie d'attendre que son logiciel ou la version du logiciel soit packagée pour sa distro. Quelle frustration, tu suis un projet, tu veux aider mais tu peux même pas installer le logiciel.
Je suis d'accord avec toi mais comment on fait pour demander à des utilisateurs de tester un logiciel AVANT qu'il ne devienne stable et rentre dans la distro, si justement le seul moyen de tester et de l'avoir via la distro. Ça se mort la queue.
Ça marche bien losrque les geeks sont aussi utilisateurs du logiciel en question. Dans le cas de GCompris par exemple, les utilisateurs sont des parents, des professeurs et des enfants qui souvent ne savent pas compiler, alors comment je fait pour leur demander de tester !
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par CrEv (site web personnel) . Évalué à 3.
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par Juke (site web personnel) . Évalué à 2.
Ce n'est par contre pas le même principe pour du logiciel proprio ou demandant absolument une stabilité et une perrinité des données.
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par Zenitram (site web personnel) . Évalué à 2.
Le besoin classique d'un utilisateur grand public est de pouvoir installer la petite appli sympa trouvé sur un petit site web.
Tu mélange le besoin du geek qui a l'appli dans le package et tout car d'autres geeks en ont besoin aussi, et le non-geek...
Encore un mélange.
Pour moi, les beta ca sert aussi a faire une version pour les traducteurs par exemple, pour qu'ils puissent traduire.
Ca va peut-etre t'étonner, mais mes traducteur ne connaissent pas le mot "GCC" ou "make". Ce sont des traducteurs, et ils doivet tester leur traduction avant de me l'envoyer.
Tu fais comment avec eux? La distribution va refuser d'intégrer la version car Beta (normal), mes traducteurs ne savent pas compiler.
même exemple pour vérifier qu'une fonctionnalité demandée par un utilisateur fonctionne bien sur un environnement donné sur lequel je n'ai pas accès, il faut bien le tester avant de diffuser...
Les version beta, non, ce n'est pas fait que pour les geeks.
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par CrEv (site web personnel) . Évalué à 3.
Non, je ne pense pas mélanger les deux.
Je dis juste que sur une distrib classique (suse, mandriva, debian, gentoo, ...) les paquets répondent à 95% des besoins (à mon avis).
Je suis d'accord qu'il reste un problème pour les 5 derniers %, qui contiennent souvent des jeux par exemple.
C'est vrai, c'est fait pour les geeks et les beta-testeurs... ;-)
Je ne pense toujours pas mélanger.
Pour moi je pense qu'il n'y a pas forcément besoin d'une version pour traduire.
J'ai fais un peu joujou avec qt4 par exemple et pour traduire, il n'y a aucun besoin de jouer avec l'exécutable, il suffit juste que le développeur génère les informations de traduction.
Ensuite pour l'idée d'une fonctionnalité pour un utilisateur spécifique, si c'est un cas vraiment exéptionnel, il suffit de générer une version static destinée juste à faire du test par exemple.
Mais je maintient que les versions beta "grand publiques" sont idiotes.
En réalité elles servent actuellement de pub, de démo mais jamais de béta. Et qu'on ne me sorte pas les béta d'environnement de dev par exemple car dans ce cas on est plus du tout dans le cadre de grand publique...
[^] # Re: Distribution GNU/Linux = plate forme fermée
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne sais pas pour toi, mes mes traducteurs aiment "voir" ce qu'ils font, tester si leur traduction marche, (pas trop long, que ca va bien dans le contexte etc...), donc ont besoin d'une version de test, toujorus snas compiler.
Venant de la programmation Windows, je m'essaye actuellement sous Linux en diffusant du 100% statique. Essaye ca :
http://sourceforge.net/project/showfiles.php?group_id=86862&(...)
Ca marche chez toi? tant mieux. Chez d'autres, c'est pas la bonne version de libc ou je sais pas quoi.
Et tout est en statique (pour le moment, mon code n'est pas pret pour s'adapter partout, donc je fais que du statique)
Impossible de filer un binaire qui marche.
Je n'ai pas encore testé autopackage car il faut apprendre à s'en servir et avoir du code "propre", je testerai.
Mais pour le moment, j'ai un excutable qui marche pour tous sous windows, idem pour Mac, et pour Linux... Un binaire qui marche une fois sur deux, pour les autres from source... Tout sauf sexy.
Heuresement que c'est par principe que je veux fournir une version sur tous les OS, sinon j'aurai abandonné la version Linux depuis un moment, trop chiante à faire. Je comprend à 100% les gens faisant que sous Windows, voire Mac, et pas Linux.
A vous de ovus poser la question du pourquoi Linux reste si petit en nombre, peut-etre est-ce simplement parce qu'il ne répond pas au besoin, et non à cause d'un monopole, qui sait...
# Ça marche dans l'autre sens aussi.
Posté par Nicolas Schoonbroodt . Évalué à 1.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Bruno Coudoin (site web personnel) . Évalué à 0.
Ici on parle d'une cible grand public, il n'y a aucune bonne raison d'avoir un compilateur sur la machine des utilisateurs.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Nicolas Schoonbroodt . Évalué à 3.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Nicolas Schoonbroodt . Évalué à 7.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Thomas Douillard . Évalué à 1.
L'argument qui tue. Pour moi c'est du "mais euh, c'est eux qu'on commencés".
Tu fais comment pour envoyer une carte de voeux électronique à ta tante ? tu la lui fais dans un format ou elle doit téléchager un logiciel, ses dépendances et compiler le tout, en lui promettant de faire le trajet jusqu'a chez elle si elle s'en sort pas, ou tu lui envoie un mail html ?
Un compilateur facile à utiliser ? Peut être, encore faut-il que tu ais les sources des paquets de dev des libs, que tu apprennes aussi à ton grand public à se servir d'un terminal avant qu'il se soit barré en courant, etc.
Sinon tu peux masquer la compilation des sources par une interface qui fait tout ça pour lui de manière plus ou moins intelligente. il cliquerait sur le tar.gz/whatever, et c'est tout. Et il se mangerait des message du style "veuillez installer la lib bidule en faisant un triple saut périlleux arrière, j'arrive pas à la compiler".
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Gniarf . Évalué à -1.
t'as pas l'impression d'être un peu un gogo de consommateur final ? un mouton friand de toutes les dernieres conneries pseudo-hype à la mode ? et déjà dépassées en fait ? en résumé un gros con ? surtout si tu sais qu'elle n'a pas de quoi la lire ?
nan mais bientot on va se faire engueuler si on n'arrive pas à lire les présentations Keynote ou Freelance Graphics aussi. allez vous pendre.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Thomas Douillard . Évalué à 2.
Cela dit t'as compris le message. Et ouais, donc tu essayes pas de compliquer inutilement la vie des gens. Et ça te dérange pas d'essayer d'apprendre à des gens qui se foutent de l'informatique comme de leur première culotte à compiler un logiciel ?
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Gniarf . Évalué à 1.
je n'ai pas conseillé à ces gens qui se foutent de l'informatique de compiler un logiciel. du tout. je leur dis en gros d'y aller molo, dans un premier temps. de comprendre un peu, un minimum, leur système (je ne parle même pas des droits des fichiers ou répertoires ici), et de ne pas chercher à installer des "paquets" au hasard sur le net.
s'ils veulent sortir de ce que la distribution propose directement (ses paquets) ou indirectement (dépots tiers, "contrib"), de quelques éditeurs genre Adobe (Acrobat Reader), c'est effectivement le désert, à part quelques sites genre happypenguin ou framasoft
contrairement à ce que tu crois, ce n'est pas un dépot genre autopackage ou klik qui va les sauver pour l'instant. il y a plusieurs raisons techniques et logistiques qui me font lourdement douter du bien-fondé comme du succès de ces tentatives mais bon hein, je ne vais pas les empêcher non plus.
par conséquent, s'ils veulent un choix large d'applications, ils choisissent une distribution connue, répandue. et avec un bon support du français s'ils commencent à taper du pied et vomir de la bile quand ils voient de l'anglais.
alors les "han la la, grand-mère elle va pas choisir sa distribution en fonction de ses besoins non plus hein elle n'a pas à s'embeter avec ce genre de contraintes techniques vachtement compliquées" je me marre. elle fait comme elle veut (ou subit les délires de fiston) mais la suite est courue d'avance.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Gniarf . Évalué à 1.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Thomas Douillard . Évalué à 1.
[^] # Re: Ça marche dans l'autre sens aussi.
Posté par Cali_Mero . Évalué à 2.
Sinon, teste un jour Kinstaller, tu pourrais changer d'avis !
# Utiliser un système non libre...
Posté par Maclag . Évalué à 4.
De mon point de vue, dans le pire des cas on considère que chaque distribution est un système à part entière, et on ne dit plus "dispo sous linux", mais "dispo sous debian/ubuntu/mandriva/redhat/suse/autre/pas/de/troll/merci/bonne/journée"
La différence, c'est qu'il me semble beaucoup, mais alors beaucoup plus simple d'obtenir un logiciel pour sa distribution s'il a déjà été compilé pour une autre, que de l'avoir sous windows s'il a été compilé sous linux...
Conclusion: un paquet pour la distrib préférée du dév., un binaire statique (ou un autopackage si le coeur lui en dit) et les sources. Essaie d'expliquer à l'utilisateur "lambda" sous son windows tellement plus simple: "il vous faut d'abord installer cygwin, puis gtk2, puis..."
[^] # Re: Utiliser un système non libre...
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
C'est pour cela que les logiciels windows et mac sont livrés dans un format binaire et facilement installable, c'est la règle sur ces plates-formes.
[^] # Re: Utiliser un système non libre...
Posté par Zenitram (site web personnel) . Évalué à 2.
L'utilisateur télécharge le binaire, l'exécute et hop.
D'un point de vue utilisateur, il s'en fou des sources. Il cherche pas à compiler, il cherche à ce que ça marche.
A vouloir trop faire les fanatiques de l'open-source, on en perd le besoin de l'utilisateur qui cherche un petit logiciel jamais intégré dans une distribution... Et la, que ce soit coté développeur ou utilisateur, Microsoft (ou Apple avec les .dmg universels, c'est pareil) marque un gros point.
"Linux, c'est pour geek, je peux installer Apache en 10 secondes mais rien à foutre d'un serveur web, je veux ma petite appli la sur ce site, qui n'est pas dans la distrib, je suis un utilisateur, pas un admin de serveur!"
[^] # Re: Utiliser un système non libre...
Posté par animal_omega . Évalué à 2.
il faudrait sacrifier cette chere diversité qui a mon avis fait la force des LL (theorie de l'evolution) dans le but de n'avoir qu'un binaire pour les logiciels proprio ?
[^] # Re: Utiliser un système non libre...
Posté par Zenitram (site web personnel) . Évalué à 2.
Ici, on parle d'un problème technique, résolvable techniquement sans pour autant sacrifier la diversité.
Avoir des problemes de dependance, ce n'est pas de la diversité, c'est du masochisme de geek.
Pour le moment, Autopackage a l'air de faire son bonhomme de chemin parce que malgrès les geeks qui critiquent mais ne proposent rien pour simplifier les installations de logiciel non packagés, eux ont l'air de savoir ce que veut le non-geek...
[^] # Re: Utiliser un système non libre...
Posté par Misc (site web personnel) . Évalué à 2.
Prenons au pif tout les logiciels que je lance sur le pc de mes parents depuis 1 heure :
gajim => autopackage ( pas pour la 0.11, mais bon, il y a un vieuw )
konqueror => rien, j'ai pas trouvé
plugin flash => rien, pas trouvé
wesnoth => pas d'autopackage
openoffice => pas d'autopackage.
j'ai pas vraiment l'impression que ç'est répandu. Pour être franc, gajim est le seul soft ou ça parle d'autopackage sur la page.
Par contre, en cherchant des paquets, je suis tombé sur d'autres alternatives, comme ça : http://oblisk.codu.org/ ou ça http://klik.atekon.de/ .
Klik me semble plus propre techniquement.
Par curiosité, j'ai quand même regardé l'autopackage de gajim. Histoire de pas mourir idiot, et parce que même si d'autres ont deja expliqué ce qui ne va pas ( http://www.licquia.org/archives/2005/03/27/autopackage-consi(...) ), il veut mieux vérifier par soi même.
Alors, deja, le script a commencé à me demander mon mot de passe root. Bon, j'ai refusé de le donner. Ça a continué, en simple user, c'est une bonne chose.
Il a commencé à me télecharger les trucs manquants, jusqu'ici, rien d'anormal, j'aurais fait pareil.
Aprés, premier bémol mineur, il modifie ma conf bash. Bon, ça arrive. Ça m'embete pas vraiment car j'utilise zsh, mais soit. Pour info, il installe tout dans ~/.local/. Bien sur, zsh n'etant pas modifié, je doit lancer bash, ou adapter leur script.
Deuxiéme probléme, il me dit "pour déinstaller le logiciel, il suffit de lancer tel soft à tel endroit dans le menu". Trés bien, en effet, le soft est la. Mais... il n'y a rien dans le menu du soft. Pas trés user friendly.
Dieu merci, je suis un ubergeek, et je repere un outil appelé package : "package remove gajim", et si je fait fit des warnings, je voit que ça marche.
Refaisons un essai, avec cette fois ci une tache moins facile. Retirons dbus-python, gnome-python-gconf, et python-sqlite, 3 paquets listés comme dépendances de gajim. Et hop, voyons comment ça marche.
Et paf, un message d'erreur :
"Erreur: Could not find 'Python interface for the SQLite'. Try using the native package manager for Mandriva Linux (urpmi) to install a package with similar name to 'pysqlite'. ".
Pas trés user friendly, amha.
J'installe python-sqlite, et je relance, ça marche. Sauf que bien sur, gajim-remote ne marche pas sans dbus, mais c'est pas grave, ç'est juste un bug mineur.
Avant dernier essai, j'installe l'autopackage , et je retire une dependance, sqlite par exemple. De temps en temps, ça arrive que les gens fassent le ménage, et donc, on va voir si c'est assez robuste.
Lancons gajim... et paf, une backtrace. Donc robustesse zero.
Et final round, soyons super taquin, je vais lancer l'installation sur ma cooker. Pour info, sur cette cooker, il y a un python 2.5 en état de marche. Comme il y aura sur les prochaines distributions qui sortent sous peu. D'abord, le paquet ne s'installe pas. Soit, il bloque, j'ai pas la patience, je fait ctrl C, et je le retire.
Je recommence, le soft se bloque encore, bon, pas grave, gajim est installé.
Et surprise, ça marche encore. En mode réduit ( pas d'icone, pas de correction ) mais ça marche.
Néanmoins, le test n'est pas trés concluant, à mon sens. Car aprés tout, la, ça a marché parce que python est interprété, donc les risques d'incompatibilité sont mineures. Mais si il y a autre chose (comme l'exemple du tray icon de gajim ) qui requiert une version différente d'une lib ( la libpython ), la, ben c'est foutu.
Non seulement autopackage ne le voit pas, mais en plus, l'user ne peut rien faire, sauf à trouver un paquet de python 2.4, et la,ça risque de foutre le bordel.
À coté de ça, le format autopackage souffre de divers lacunes, par exemple, je ne voit pas d'options de vérification des signatures des paquets, pas de gestionnaire centralisé qui pourrait palier au manque de publicité sur les sites web, et surtout, aucun mecanisme de gestion des mises à jours.
Si jamais une faille de secu dans gajim apparait, je suis bon pour mettre à jour à la main, en me tenant au courant. ( et qu'on vienne pas me dire "les applis clientes, c'est pas important pour la sécu", je n'aurais que 2 lettres comme réponse : I E ).
Pour moi, il y a donc des raisons pour refuser d'utiliser autopackage, et pour conseiller aux gens de faire pareil. L'idée même de voir un telecharger.com bis ne m'enchante pas des masses.
[^] # Re: Utiliser un système non libre...
Posté par B16F4RV4RD1N . Évalué à 2.
et pourquoi pas kde en autopackage tant que tu y es ? ;)
Je pense qu'autopackage est bien pour les petits projets (non intégrés dans les distrib), des versions "bleeding edge" de certains programmes, ou des programmes nouveaux. Des programmes phares comme openoffice, gimp, firefox etc, qui sont disponibles dans *toutes* les distributions n'ont pas spécialement besoin de ce genre de paquets.
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: Utiliser un système non libre...
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
[^] # Re: Utiliser un système non libre...
Posté par animal_omega . Évalué à 1.
Je suppose que tu parles de logiciels libres etant donné que tu parles de cette liberté. Tu connais beaucoup de logiciels libres qui ne sont pas dispo dans les principales distro ?
Et du coup je suis bien content de pouvoir avoir une gestion de dependance evoluée, de mise a jour automatique etc... que m'offre deb ou rpm.
[^] # Re: Utiliser un système non libre...
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Avec le développement de GCompris, je suis bien placé pour savoir qu'il manque toujours un paquet pour une distro.
Pour le reste, qui te parles de te passer de ton système de paquet actuel, personne. S'il te satisfait, continue à l'utiliser pour la ou il est efficace.
[^] # Re: Utiliser un système non libre...
Posté par Zenitram (site web personnel) . Évalué à 2.
- d'un coté les utilisateurs "de base" dont soit les softs packagés dans leur distribs leur suffisent, soit ils ont la compétence nécessaire pour compiler.
- De l'autre, des développeurs qui ne sont pas encore "certifiés" dans les distribs, et qui doivent eux se taper toutes les distribs tout seul, avec tous les problèmes associés, ces developpeurs faisant des softs pour des non-geeks, aucun geek ne vient leur proposer de fair un package pour leur distrib. Dans ce monde, il y a aussi les gens qui veulent un logiciel pas dans la distrib, et qui ne savent pas compiler.
Deux mondes qui ne voient pas du tout la même chose... Dommage.
Rien à voir, ton apprentissage d'auto-package a été long?
[^] # Re: Utiliser un système non libre...
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Pour autopackage, c'est très simple et bien documenté. Ce qui prend le plus de temps c'est de rendre ton logiciel (au fait tu travailles sur quoi ?) relogeable.
Aussi suprenant que cela puisse paraitre, les logiciels sous linux doivent être installé à l'endroit pour lequel ils ont été compilé (au moment du configure). Sinon, il ne savent pas trouver leurs données.
[^] # Re: Utiliser un système non libre...
Posté par CrEv (site web personnel) . Évalué à 2.
Au contraire. Le système de paquet, avec gestion des dépendances et la facilité d'installation fait qu'il est bien plus facile pour installer un programme sous linux à mon sens.
Par contre oui, ça a un prix, celui de devoir rajouter une couche de packaging, soit pour le développeur, soit par une équipe externe.
Mais pour l'utilisateur c'est quand même mieux je trouve.
A noter tout de même que même sous windows il faut faire des paquets, avec nsis par exemple. D'ailleurs, n'est-il pas possible tout simplement d'utiliser des installeurs comme ceux de loki ? Pour avoir installé des progs avec, c'est aussi simple que sous windows (dans le sens ou tu l'entend)
[^] # Re: Utiliser un système non libre...
Posté par Zenitram (site web personnel) . Évalué à 1.
Ben non. Pour reprendre texto la phrase de Bruno : l'utilisateur voit un soft sur un site web, voit les screenshots, et veux l'installer.
Sous Windows/Mac, c'est clic, telechargé, clic, installé.
Sous Linux, c'est lancer le packet manager (différent de celui de son voisin, bien entendu), chercher, package pas trouvé, abandon. Le seul moment où ca marche, c'est quand le package est dispo pour la distribution. Et encore, taper le nom du soft dans le gestionnaire de paquet est plus chiant que de cliquer deux/trois fois dans son navigateur Internet.
Ce que tu dis, c'est mieux pour l'utilisateur geek. Pas pour Mr tout le monde qui surfe sur le net et qui découvre des noms de logiciels qu'il ne connaissait pas avant.
[^] # Re: Utiliser un système non libre...
Posté par CrEv (site web personnel) . Évalué à 2.
Heu là... non !
Je ne pense pas que dans une distrib on trouve que des softs de geeks fait pas des geeks, packagés par des geeks.
Parfois il suffit d'aller sur l'irc (par exemple) d'une distrib en disant : "je développe le soft xxxxxxx et j'aimerais qu'il soit dispo sur cette distrib. Pouvez-vous le packager / m'aider à le packager / ... ?"
Je suis peut-être complètement naïf mais je pense que c'est le meilleur moyen pour obtenir (indirectement ou non) un paquet correct.
Et je pense qu'un certain nombre de softs sont également packagés par des personnes ne les utilisant pas. A mon avis, il suffit de montrer que le soft a un intéret.
[^] # Re: Utiliser un système non libre...
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui.
Il y a des milliers de softs pas dans les distros, et surtouts des milliers de softs pas à jour dans les distros...
[^] # Re: Utiliser un système non libre...
Posté par dinomasque . Évalué à 3.
Le site qui propose au téléchargement Winamp9.023952beta_crack.warez.exe truffé de virus, de chevaux de troie et autres saloperies ?
Je suis bien content, quand ma mère décide d'installer un nouveau logiciel, qu'elle puisse le choisir dans le catalogue officiel du magasin d'état de boubountou. Non seulement c'est beaucoup plus facile pour elle (plein d'applications triées par catégories sont disponibles dans un et un seul endroit) mais en plus je sais qu'elle ne va pas sagouiner son ordinateur avec tout un tas de cochonneries comme du temps ou elle était sous Windows.
BeOS le faisait il y a 20 ans !
[^] # bon alors suggestions...
Posté par Maclag . Évalué à 2.
Je commence par la plus tordue:
1 - les "grandes" distribs (entendre par là celles que le grand public non initié installe en premier, pas de troll comme d'hab, merci!) mettent à disposition des "fermes de compilation" semi-publique (à savoir tout développeur d'un projet utilisable devrait avoir le droit d'y créer un compte) et dotée d'outils destinés à faciliter la création des paquets
ex: mandriva (au hasard! pas de troll! merci!!!) met à dispo une batterie de serveurs pour les projets moins en vue, avec des outils pour créer les paquets pour leurs distributions facilement
Tordu, parce que ça va nécessiter pas mal de ressources, tant matérielles qu'humaines!
2 - le système de gestion de paquet convivial...
quand l'utilisateur "lambda" (ou autre d'ailleurs) clique sur le beau projet (disons un .rpm/.deb ce que vous voulez pas de troll merci), le gestionnaire suit la procédure suivante:
A - il regarde dans les sources "officielles" configurées sur la distro si y'aurait pas un paquet avec un nom identique au numéro de version près
B1 - si oui, forcément, il privilégie le paquet issu des sources
B2 - si non, il tente d'installer depuis la source internet
B2a - cool, ça marche!
B2b - et merde, ça va pas!
B2b-1 chercher un autopackage du même nom dans le même répertoire et l'installer s'il existe
B2b-2a si oui cool on y va (voire question à part: peut-on envisager de reconstruire un .deb/.rpm/.autre à partir d'un autopackage à coups de ldd et autre?? histoire de garder les dépendances, tout ça)
B2b-2b ben nan, y'a pas, faut se farcir les sources. ajouter dans le TODO:
faire un prog révolutionnaire qui comprend tout seul et sans script comment faire un paquet à partir des sources!!
B2c - envoi automatique d'un point sur un compteur de wishlist du côté du système de gestion de bug officiel de la distrib (avec enregistrement de l'IP, histoire qu'un boulet ne clique pas 2000 fois pour le même projet de traduction en temps réel de langage de baleine en suricate)
Et non! Je n'enverrai pas de patch! Suis pas programmeur, moi! Suis suggestionneur!! :-D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.