jeudi 02 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Amélioration en vue pour l'installation de logiciel sur GNU/Linux.

Posté par Bruno Coudoin (page perso, ). Modéré le 04 janvier 2007.
0
Qui n'a jamais été déçu de ne pas pouvoir installer la dernière mouture d'un logiciel annoncé ici même ?

Les systèmes de gestion de paquet que nous trouvons couramment dans nos distributions - comme apt-get ou urpmi - ont certes de nombreux avantages mais aussi des limitations. Il n'est par exemple pas simple d'avoir les dernières versions des logiciels et on se retrouve limité à la sélection des paquets de sa distribution ; or aucune ne propose l'ensemble des Logiciels Libres existants.

La nécessité de fournir des paquets binaires multi-distribution est encore plus demandée par les éditeurs de logiciels propriétaires désireux de fournir une version GNU/Linux.

Partant de ce constat, un groupe de travail a été formé au niveau du projet LSB (Linux Standard Base) et de son organisation parente le FSG (Free Standard Group) afin de rendre la vie plus facile aux utilisateurs et aux développeurs.

> Lire la suite (326 commentaires, moyenne: 2,8).   [dépêche : 1170 caractères]

Des personnes-clés se sont rencontrées à Berlin le mois dernier pour discuter du futur système de packaging. L'approche retenue est de se baser sur l'existant et d'ajouter des ponts entre les systèmes de paquets habituels et les besoins des développeurs.

L'idée de base est d'ajouter une API commune dans les différent systèmes de paquets. Cette API permettrait à un logiciel de pouvoir s'enregistrer auprès du système de paquets.

Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.

Ainsi, si un projet cible une version donnée de la LSB et qu'il existe un installeur multi-distribution, la seule contrainte pour un utilisateur sera d'avoir une distribution qui supporte cette version de la LSB.

Tout n'est pas réglé car le problème n'est pas simple. Pour ceux qui sont intéressés, le FSG a créé un groupe de travail sur le sujet et vient de relancer une liste de discussion.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] Beurk

Posté par Grumbl (page perso, ) le 04/01/2007 à 09:39. (lien). Évalué à -1.

"La nécessité de fournir des paquets binaires multi-distribution est encore plus demandée par les éditeurs de logiciels propriétaires désireux de fournir une version GNU/Linux."


Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?

Chaque distribution est libre de faire les risettes qu'elle voudra aux ogres qu'elle voudra séduire, mais je ne vois vraiment pas l'intérêt de standardiser dans ce secteur.

Bonne chance à ceux qui essaieront : ils ne seront pas les premiers, ils ne seront sans doute pas les derniers.

Au fait, Java, c'était pas sensé servir à ça aussi ?

Difficile

Posté par yoho (page perso, ) le 04/01/2007 à 09:56. (lien). Évalué à 10.

Le problème est qu'on parle toujours des dépendances sans réellement réaliser qu'elles sont complètement différentes d'un système à un autre. Certains gestionnaire de paquetages peuvent "suggérer" l'installation d'autres paquetages. Des logiciels ont été divisés en plusieurs parties dans certaines distro (libifiés, par exemple), dans d'autres non. Je ne vois vraiment pas comment on peut résoudre tous ces problèmes sinon en contraignant toutes les distros à se ressembler complètement.

.

Posté par ccomb (Jabber id, page perso, ) le 04/01/2007 à 10:05. (lien). Évalué à 4.

Il existe http://autopackage.org qui marche déjà pas trop mal. Avec interface graphique et tout. En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers.

Faux problèmes à mon sens.

Posté par hervé Couvelard (Jabber id, page perso, ) le 04/01/2007 à 10:38. (lien). Évalué à 10.

Je crois que c'est un peu 'politique marketing' car il y a un moyen de faire des binaires multi-plateforme : c'est de compiler en static et de fournir les libs dans un bon gros .tgz

De nombreux jeux le font (par exemple http://www.landes-eternelles.com ) avec des binaires linux. D'autres 'gros'jeux ont été annoncés ici même avec des binaires universels) des petis émulateurs sortis il y a 3-5 ans et fournis en binaires fonctionnent encore, Openoffice, firefox, etc.... il y a autopackage .. (comment fait skype ou nero ?)

Mainenant que certains veulent se faire mousser en révolutionnant encore une fois de plus le bouzin peut amener amélioration par effets de bords, mais ce n'est pas le désert non plus et ce ne sont pas des sauveurs du monde de l'univers.

Ce que j'en voie avec ma mauvaise fois trollesque légendaires, c'est un moyen pour LSB (et ses principaux promoteurs) de 'reprendre un peu le devant de la scène' dans un univers linux libre qui s'éclate sous l'effet d'un nombre croissant de distributions communiquantes, et de positionnement, face au respect de la gpl, parfois divergents.

Il est clair que les logiciels proprios qui veulent canibaliser le libre (prime au premier entrant) sont les premiers interessés d'une initiative comme cela. Par effet de 'renommé' ce groupe de travail communiquerait (peut être avec raison, question de goûts) facilement sur les grosses boites proprios qui porteraient des applis proprios sous linux, ce qui fragiliserait un peu le délicat écosystème (dans le sens économique) du libre.

Maintenant je ne pense pas que cela n'apportera rien, mais je ne pense pas non plus que cela apportera plus que la sortie du dernier wormux ou de j'enveuxpas.
Effectivement cela pourrait sembler permettre aux 'petits' de plus facilement de distribuer des package tout prêts, mais plutôt que
-de réinventer la roue
- aller à l'encontre de la philosophie linux, et aller vers un système windows clicliclic.exe fini
- aller vers un moyens de standardiser le linux de base et donc le rendre plus sensible aux virus car 'génétiquement' plus proches les uns des autres ave une api exprès pour installer sur toutes les machines
- donner aux distributions un point de fixation supplémentaire [ le driver graphique proprio nouvelle version qu'il faut attendre ET la nouvelle version du packageur miracle)

....il serait plus judiceux de mettre en place des 'fermes de compilation' pour préparer les binaires facilement.

Par exemple ce qui pourrait être le plus smart dans mes fantasmes les plus torrides : Chaque destribution founirait un ou plusieurs machine de compilation. En tant qu'utilisateur, je choisie un logiciel Lambda. Je me connecte sur le site et je donne la config de ma machine (avec un script shell qui vérifie les versions de mes libs), le serveur fait un chroot avec les versions identiques aux miennes et lance la compilation, fait le package et me distribue le package (le stock pour ne pas refaire le même travail) en travaillant directement depuis les sources de l'applis. Ensuite il met ce package à dispo en téléchargement avec les infos qui vont bien. Et hop, plus de soucis de libs, plus de soucis de distribution pour les dév. On peut même penser qu'il puisse y avoir des machines qui prennent les sources et lancent une compilation sur toutes les distributions et 'centralisent' les erreurs pour faire des corrections générales. [ cela résoudrait une grande partie des soucis, laissant que les problèmes particuliers]. Comme l'utilisateur Lambda utilise une machine 'toute prête et pas tunée, cela marcherait pour 95% des cas, respecterais la philosophie linux, pas de static, compile from source etc...., et soulagerait les dev et les utilisateurs.

happy

Posté par phentex () le 04/01/2007 à 10:52. (lien). Évalué à 4.

Je suis content qu'on évoque les problèmes de situation et d'installation d'un programme hétérogènes selon les distro, et qu'on parle des nombreux systèmes de packaging.
Alors, bien sûr, linux, libre, plein de distros, toussaaaa... OK.

La prolifération de systèmes de packaging, de distros, etc... concurrents sous couvert de caractère libre et de diversité, est ce qui a permis à Linux de prendre l'envol qu'il a aujourd'hui.
Le problème, c'est (ça va sans doute vous paraître totalement utopique ) si cette diversité, du fait que des milliers de programmeurs d'horizons différents (besoins différents, approches différentes,...), ne sert pas à une sorte de réunification positive à un moment donné, profitant de tous les bons éléments et bonnes idées de cette diversité, et éliminant les doublons inutiles et les faux pas (qui font que parfois faut 5 programmes pour faire 1 chose bien complètement), alors clairement on court vers un bordel absolument monstre. Ne serait ce qu'à l'heure actuelle, comment expliquer à quelqu'un qui débarque de windows, qu'il n'y a pas 1 "Linux" mais pleins de distributions, qui font toutes plus ou moins la même chose. L'utilisateur average Joe qui n'en a absolument rien à ciré de l'état d'esprit communautaire, de la philosophie (aussi louable soit elle), qui veut juste un système qui fonctionne, et pas avoir à payer une license Windows, et ben s'il a pas un informaticien sous le bras pour le guider vers une distribution newbie-enabled comme Ubuntu ou Mandriva, il est largué (=> "Linux" caytrocompliké => back2vinedause).

Je parle en connaissance de cause, il y a deux jour, j'ai été confronté à une jeune femme (qui à 20 ans ne trouve pas naturel de dézipper un fichier à l'aide du menu contextuel clic-droit sous windows) qui m'a posé la question suivante:
"Tu utilises Linucsee. Ah oui, mais c'est quoi ce truc? Ca doit être la dernière mode des informaticien ou quelque chose du genre? Pourquoi les gens quittent windows pour Linux???? M'enfin je comprend pas" (le plus naturellement possible)
...

Après coup, pardonnez moi cette petite disgression

--
ggggnnnnnnnnnnnnnnnnn (interprétation libre)

Ça n'arriveras jamais

Posté par Misc (page perso, ) le 04/01/2007 à 10:56. (lien). Évalué à 10.

Trés franchement, plus je voit ce genre de choses, plus je doute que ça arrive.

Pour le moment, la seule façon dont ce genre de choses est arrivé est
1) une intégration proche de zéro avec la plateforme ( tarball binaire )
2) un monopole sur le produit sous jacent ( windows )

Imaginer que toutes les distributions linux et tout les distributeurs vont se mettre d'accord et sacrifier leur indépendance technologique pour respecter une norme arbitraire, c'est surréaliste.

Les distributions innovent, changent des trucs. Soit elles vont renoncer à ça, et je pense que ça sera le début de la fin, soit elles vont continuer à le faire, et les distributeurs vont être moins intégrés.

Exemple tout con ? Les scripts d'init parrallléles de Mandriva, à mettre en concordance avec upstrart chez ubuntu. Les 2 distributions devraient ne pas utiliser ça parce que ç'est potentiellement incompatible avec la lsb ?
Et donc, dire non à leur utilisateurs qui réclament ça depuis longtemps ?

Ou le faire, et donc avoir des bugs subtiles causés par les softs qui ne sont pas adaptés, ni testés avec ça ?

Car il ne faut pas oublier une chose. Avoir une norme, ç'est bien. Mais ça implique aussi de faire des tests sur chaque plateforme, et chaque distribution. Sauf à vouloir proposer des softs non testés, en plus d'être moins intégré.

De plus, comme j'ai déja dit dans la discussion précédente sur le sujet, ça va aussi limiter séverement les developpeurs dans l'usage des nouvelles libs.

Et ça, je pense que ça va faire grincer des dents.
On va se retrouver avec le probléme sauf qu'au lieu d'avoir des utilisateurs frustrés, ça sera des developpeurs frustrés. Frustrés de devoir garder des vielles libs pour faire du code pour les utilisateurs, frustrés de ne pas pouvoir utilisé le dernier truc trop fort de gstreamer, de cairo, car non dispo dans la norme.

Et trés franchement, entre frustrer les gens qui codent et font avancer le libre, ou les gens qui se contente d'utiliser, mon choix est vite fait, surtout pour un truc aussi futile que l'utilisation du dernier soft à la mode.

Et je ne parle pas du fait que si personne n'utilise les libs, les bugs ne seront pas remontés, donc le logiciel libre ira moins vite, avec du soft de moins bonne qualité, mais... avec des softs installables directement. Toute ressemblance avec la situation actuelle sur un os propriétaire est fortuite.

Beuh

Posté par Martyanoff Nicolas (Jabber id, page perso, ) le 04/01/2007 à 10:59. (lien). Évalué à 5.

Je ne voudrais pas passer pour le crétin de service, mais qu'est-ce qu'on fait des gens comme moi qui n'en ont rien à taper des binaires, et aiment compiler leurs paquets aux petits oignons (pas pour les perfs, hein, mais pour pouvoir dégager les features qui ne servent à rien et éviter les dépendances alakon) ?

/me voudrait un format modulaire, style petit fichier descriptif (j'ai pas dis ebuil) permettant au choix de compiler sois-même (à bin si j'ai dis ebuild) ou d'aller automatiquement pomper un binaire compatible avec la machine sur un ftp quivabien.

On peut voir une interface simple:

pkg_install --compile vim (le choix du package est fait dans un but de propagande :p)
pkg_install --binary vim

Et hop, tout le monde a ce qu'il veut.
Gros avantage, on peut comme ça garder tous les descriptifs de paquets en local et faire des recherche rapide dessus (eix en force).

J'ai tout faux ou pas ?

Tiens, Ian Murdock parmi les « personnes-clés »

Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 11:07. (lien). Évalué à 3.

Comment ne suis-je pas étonné de voir le fondateur de Debian et surtout de Progeny venir encore une fois à l'assaut avec sa prétendue compatibilité binaire que Marck Shuttelworth a déjà maintes fois démonté.
S'agissant principalement de Logiciels Libres, le modèle d'installation des logiciels sous Windows n'est guère applicable sous Linux.
Pour ce faire, il faudrait que les éditeurs de logiciels tiers fournissent des paquets binaires compatibles comme le font actuellement les éditeurs tiers de logiciels sous Windows, point barre. Évidemment, ils devront le faire pour chaque distribution, le problème soulevé est toujours le même...
Que ceux qui prétendent ainsi faciliter la vie de leurs utilisateurs fassent donc le nécessaire pour que ces derniers puissent trouver plus rapidemment des versions binaires des logiciels libres pour leurs distributions préférées au lieu d'ergoter sur un fumeux et éventuel « standard ».

Et pourquoi que ?

Posté par thoduv () le 04/01/2007 à 12:59. (lien). Évalué à 1.

J'ai jamais compris ce qui empechait les distribs d'avoir une base commune de libs importantes (ex: libc, libstdc++-quiestjamaislabonneversion, x11, gtk, ...) mises à jour en même temps pour "tout le monde", et qui permettrait d'avoir des binaires universels sans pour autant tout lier en static...
Autant les distributions permettent d'avoir une liberté de choix (de conception, enfin appelez ca comme vous voulez), mais sur des trucs de base comme ca, je vois pas le problème...
Quelqu'un peut expliquer ?

ça peut pas marcher ?

Posté par Jul (page perso, ) le 04/01/2007 à 13:10. (lien). Évalué à 3.

Voici un certain nombre de cas qui me disent que cela pose problème :

outils pour récupérer/manipuler en click a click des paramètres/réglages de la nouvelle carte trucmuche avec drivers proprio dans le kernel (au choix gadget HP sur cartes mères, overcloking/température sur nvidia, carte wifi ...) => J'aurais beau installé la partie user space en binaire si j'ai pas les drivers binaires je suis mal. Et l'on revient au fait qu'il fait résoudre les problèmes des blobs dans le kernel, et que cela ne marcherait peut être pas sur BSD x86 avec compatibilité binaire (qui est aussi un système libre), voire sur linux sparc64.... Donc la distribution de binaire pour ce secteur sera toujours moins intéressante que l'accès aux specs du hardware. (Cela coûtera en plus plus cher aux éditeurs).

Autres choses, imaginons une IHM de haut niveau. Comme il faut compiler tout en static, le binaire va réintégrer les librairies genre gtk, expat, sdl, ... non seulement la taille des install va exploser, mais quid des interactions (pour une appli qt par exemple) entre le nouveau desktop (KDE) et le binaire avec ses anciennes librairies. N'y a t'il pas des risques de devoir régler son système sur les applis binaires ? Du genre j'ai une appli métier qui utilise tel mécanisme donc je peux plus upgrader mon serveur qui est en DMZ. En tant que sysadmin, je serais pas chaud.

Pour les serveurs, (oracle par exemple) imaginons, c'est bien beau d'avoir les binaires, mais le sysadmin veut aussi une standardisation des emplacement de réglages (/etc/), des fichiers de log/pid, des scripts de démarrage, qu'en sera-t'il. Le démarrage sur un BSD (compatible binaire linux) qui se fait à la slackware, n'est pas le même que dans une RH ou une debian. De même pour la gestion des droits, il est parfois sain de créer un utilisateur local, avec toutes les contraintes et conventions par système, ça sent l'usiine à gaz.

Et que se passe-t'il quand une librairie (dont on on ne sait pas qu'elle est intégrée si le binaire est strippé) souffre d'une vulnérabilité ? On ne remet plus à jour une librairie, mais n applications ? En plus comment peut on faire confiance à des éditeurs propriétaires pour bien vouloir jouer le jeu de la transparence nécessaire à la sécu, alors qu'il livre la forme la plus obfuscated possible du code, c'est à dire un binaire ?
Ca va faire exploser le besoin en maintenance sur les serveurs (chic du boulot). Et déjà qu'on peut ne pas avoir confiance dans des logiciels même quand on a les sources, alors avec du binaire, faut être sacrément confiant. Vous vous sentez installer un logiciel sous forme binaire de gestion de DVD-rom fourni par sony vous ?


Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle

[+] Euh....faire comme PC-BSD ????

Posté par Nikoo () le 04/01/2007 à 14:37. (lien). Évalué à -1.

Euh, en fait ce que les gens souhaiteraient, c'est d'avoir sous Linux, un système d'installation désinstallation aussi simple que sous PC-BSD et son PBI : http://www.pcbsd.org/?p=learnpbi

Je cliques, ça s'installe, et c'est tout.
Je veux désinstaller, ça désinstalle, et c'est tout.

Le mieux : MacOSX : je cliques, ça installe. Je mets à la poubelle, c'est désinstallé (même si je ne sais pas si sous MacOSX ça soit si bien désintallé que ça : reste de libs, etc...).

On peut pas faire plus simple, et ça marche très bien.

Les pro-gestion des dépendances, les "je m'amuse avec apt, smart, urpmi", etc...., n'ont aucun argument valables face à cette demande.

Cela n'empêche d'ailleurs pas d'avoir des dépôts officiels, supportés, et d'autres genre "universals" ou "contrib".


Donc le LSB peut former un groupe de réflexion, etc... : la réflexion est déjà faite par d'autres. Il "suffit juste" de l'adapter à linux, et de se grouiller de le faire MAINTENANT, si on veut réellement que Linux est une visibilité suffisante auprès du public, et surtout des développeurs de jeux et des contructeurs matériels.

Beryl c'est bien.
Pouvoir l'installer facilement, c'est mieux. :p


Mes deux piécettes.

--
http://nikoolinux.zeblog.com/

Bon j'y vais aussi de mon petit commentaire

Posté par Yann LE MOIGNE () le 04/01/2007 à 15:46. (lien). Évalué à 4.

Une partie de la force des systèmes unix viens de sa philosophie modulaire. On ne réinvente pas la roue, on la réutilise. C'est bien pour cela que l'on "s'embête" à gérer des dépendances.

Certains disent "faut abandonner car ça rend linux plus compliqué que windows" (je schématise, mais l'idée est la).

Dois-je leur rappeler que les applications windows aussi utilise des dépendances ? Qui n'a pas eu d'erreur pour une dll manquante ? la mauvaise version de MsNANANA.dll ? Une dépendance vers un DirectX version N.N ? Voir même se retrouver bloquer car son Windows 98 ne peut pas recevoir tel version de tel bibliothèque ?

Alors, la modularité est plus poussées dans la communauté FLOSS, certe, et le problème ressort plus nettement, oui. Mais il n'est pas intrinsèquement différent selon les plateformes.

Etre modulaire implique d'assembler des modules, ça me semble assez limpide. Et si l'assemblage peut paraitre laborieux, au vu du travail économiser par cet architecture, cela me semble être la bonne voie.

A cela plusieurs solutions sont proposées. Et la liberté de choix est la. Personne n'interdit a un mainteneur souhaitant proposer son paquet au plus grand nombre, de faire un build static. Ceux qui trouvent cela malpropre s'en passerons, les autres seront heureux, devez vraiment vous tirer dans les pattes pour savoir qui a raison quand les deux, dans leur vision des choses, ont chacun raison ? N'est-ce pas la justement une expression de la liberté de nos système ? Si vous n'aviez pas le choix de la solution, et quelque soit cette solution imposée, vous la trouveriez adapté ! (voir les propos sur les installateurs windows, ça viens pas a l'idée de la personne de geuler car il a son logiciel sous une version compilé statiquement , puisqu'il n'y fait même pas attention)

Par contre, juste une note a l'attention de ceux qui proposent des solutions "source". En dehors du débat "propriétaire/libre", prenont OpenOffice.org ou firefox. Qui vas expliquer a un utilisateur lambda que linux prend 12 heures pour installer un traitement de texte ou un navigateur ? (pas la peine de ma flammer, personnellement j'utilise gentoo, mais je pense juste que cette approche a ses limites...)

autoriser l'installation sauvage de logiciels dans un répertoire prévu

Posté par - - () le 04/01/2007 à 16:11. (lien). Évalué à 1.

prenons /usr/local

que les distributions se mettent d'accord et normalisent une organisation de comment y placer une nouvelle application (par exemple Firefox)


/usr/local/firefox/share
/usr/local/firefox/bin
/usr/local/firefox/locale
/usr/local/firefox/misc
etc

des trucs genre jboss continueront à faire /usr/local/jboss/<ce que veulent les développeurs> parce que jboss respecte la norme java enterprise et n'est pas une "application" utilisateur.

bon

si Firefox a besoin d'une lib jugé "exotique", c 'est à dire que les concepteurs savent que libexotique.so c'est pas fourni dans les dernières redhat, ubuntu, mandriva, debian etc, ils le fourniront au sein de leur paquet firefox (dans /usr/local/firefox/lib )

si un développeur de firefox estime que , par exemple gtk 2.8, est devenu tellement banal et populaire (toutes les distribs depuis un bon moment l'intégrent) , il arrêtera de le fournir au sein de son propre paquet et fera confiance au système de dépendance de la distrib

il écrira sur son site "Attention firefox 5 super-roxor nécessite Redhat 7, Ubuntu 2012.10, Mandriva Extreme 5 edition, autre distribs possible mais pas garanties" et voilà


rien n'empeche la distrib de fournir eux même le firefox via son système de paquets

mais il faut accepter qu'une seule solution ne permet pas de résoudre tous les problemes
et il faut apprendre à consider Xlib, gnome, gtk, kde, qt, glib, libhal, udev etc comme UNE plateforme. si un truc est trop exotique pour l'époque, le developpeur DOIT la fournir au sein de sa super application.


merci pour votre attention.

Utilisation des applications sans 'installation'

Posté par Edouard Lampion () le 04/01/2007 à 17:50. (lien). Évalué à 5.

Est-ce que les approches comme klik (http://dot.kde.org/1126867980/) ou plus classiquement Java Web Start n'étaient pas imaginées pour simplifier l'instalation des applications pour l'utilisateur final ? Ca paraissait prometteur pour permettre justement de tester les versions dernier cri.

Pourtant, on ne peut pas dire que le succès soit au rendez-vous. Le déploiement reste une préocupation pour les développeurs, et le recours a ce genre de solution est faible, j'ai l'impression. J'ai le sentiment de voir plus souvent des packages pour les principales distributions, et un tarball des sources pour les autres dans la section download des projets.

La question est pourquoi ? Ce qu'il me vient à l'esprit, c'est que l'environnement proposé est trop limité, et que cela convient à faire des appliquettes, mais pas des logiciels ambitieux.

Je serais interessé par d'autres avis.

2 choses.

Posté par Barnabé () le 05/01/2007 à 08:52. (lien). Évalué à 6.

- 217 commentaires et pas un pour se rendre compte que le monde ne se résume pas au x86, ce qui rend la distribution directe du développeur à l'utilisateur utopique.

- La compilation d'un logiciel bien fait, ca peut prendre du temps, mais ca marche. C'est la diffusion de sources qui a fait que le logiciel libre existe, aussi pour une raison pragmatique : c'est le moyen le plus efficace et le plus simple de diffuser du logiciel pour des plateformes, des distributions non connues à priori.

Y a quand même autre chose à faire que des paquets.

Posté par d-jo (page perso, ) le 05/01/2007 à 09:39. (lien). Évalué à 3.

Franchement, je préfererai souvent que les distros supportent moins de logiciels mais que l'intégration et les outils de configuration soient plus poussés.

Avoir quinze serveurs de mail ça roxe, avoir Postfix/Cyrus bien configuré avec un outil puissant pour l'intégrer à son parc applicatif (LDAP, BDD, sécurité réseau, backup, toussa ...) c'est mieux.

Avoir 36 solutions de HD, loadballancing c'est bien, mais moi je veux juste agréger quelques liens ethernet. Il est ou l'outil pour faire ça ?

Avoir 295 environnement de bureau, c'est parfait. Moi j'aimerai bien pouvoir choisir à la création du compte utilisateur :
Etes-vous :
_ Un jean-kevin
_ Un neuneu
_ Un poweruser
_ Un geek
_ Un enfant

Et avoir un truc configuré et intégré correspondant à l'usage que je vais en faire.

Elle est ou la solution de controle parental dans l'environnement Desktop ? A oui faut installer squidguard ou privoxy ...

Une solution d'installation "universelle" économiserai bien du travail, permettrait d'éviter d'avoir à packager sans arret et donc de faire d'autres choses.