... des prog. compatibles pour toutes les distribs??
je sais qu'il y a une question d'environnement WM...
mais de temps à autre, je tombe sur des executables déjà compilés cross distrib.
 
désolé si cette question a déjà été posée, si c'est le cas on lock

parce que le statique c'est lourd

les lib X11/xorg ne sont elles pas suffisantes pour tous les usages?

tu sais faire une interface graphique rien qu'avec les libs xorg toi ?

Mais wouaï...
Et pis du cross compatible windows et macOs...
Ah pis Solaris aussi pendant qu'on y est...

l0g4n, on est vendredi mais ce sera pas trolly sur ce topic.

dans un passé bien reculé mais pas si lointain, j'ai fait un programme simple avec des lib X11.
des boutons, des affichages de résultats, des dessins... en gros je refaisais un GUI de gplot

 
Non.    

 
en gros, des programmes java

et l'argu.? exemple?
c'est qd même une vraie question 4me

nan ,
à la louche des jeux (quake4, racer.nl)
xclock ==> bon d'accord
...mais qd même ça existe  : firefox? je pense n'a pas besoin de connaitre son environnement WM
pour fonctionner tout seul comme un grand

 
Ben, je regarde les dépendance de gedit:
  Dépend: libart-2.0-2
  Dépend: libaspell15
  Dépend: libatk1.0-0
  Dépend: libaudiofile0
  Dépend: libbonobo2-0
  Dépend: libbonoboui2-0
  Dépend: libc6
  Dépend: libeel2-2
 |Dépend: libesd0
  Dépend: libesd-alsa0
  Dépend: libfontconfig1
  Dépend: libfreetype6
  Dépend: libgail-common
  Dépend: libgail17
  Dépend: libgconf2-4
  Dépend: libgcrypt7
  Dépend: libglade2-0
  Dépend: libglib2.0-0
  Dépend: libgnome-keyring0
  Dépend: libgnome2-0
  Dépend: libgnomecanvas2-0
  Dépend: libgnomeprint2.2-0
  Dépend: libgnomeprintui2.2-0
  Dépend: libgnomeui-0
  Dépend: libgnomevfs2-0
  Dépend: libgnutls10
  Dépend: libgpg-error0
  Dépend: libgtk2.0-0
  Dépend: libgtksourceview1.0-0
 |Dépend: libice6
  Dépend: xlibs
  Dépend: libjpeg62
  Dépend: liborbit2
  Dépend: libpango1.0-0
  Dépend: libpopt0
 |Dépend: libsm6
  Dépend: xlibs
  Dépend: libtasn1-2
 |Dépend: libx11-6
  Dépend: xlibs
 |Dépend: libxext6
  Dépend: xlibs
  Dépend: libxml2
  Dépend: libxrender1
  Dépend: zlib1g
  Dépend: scrollkeeper
  Dépend: gedit-common
 
Il y a un peu plus que la xlib.
 
 
 
 
 
 
 

donc selon ce constat on ne pourrais pas fabriquer un simple editeur de texte qui ne dépendrais que
de X11 et libc : tu me permets d'en douter?

firefox il est en gtk instream

 
Puis tu vois les dev se retaper le dessin des widgets, réécrire le parsing des différents format de fichier, l'accès aux sources de données à chaque nouveau programme...

 
Si c'est possible, mais c'est idiot.

Nan mais réinventer la roue à chaque fois, c'est un peu lourd quoi.

argument de progueux (je n'ai pas d'encontre à ce propos) , certes et pour les millions users finaux?

xemacs?

 
Note qu'utiliser des librairies autres que celles de bases permet au progueux de proposer aux utilisateurs finaux une interface unifiées, des temps de chargement diminuées, et des releases plus fréquentes, (comme il n'ont pas à réinventer la roue, il développe plus vite.)

 
Ceci dit, rien ne t'oblige à utiliser des programmes utilisant autre chose que la xlib, on peut en effet survivre avec twm, xemacs et des xterm.  

firefox est un bon exemple.
 
Regarde sa taille sur le site de mozilla et la taille sur ta distrib. Sous la distrib, c'est beaucoup plus petit. Dans la version de Mozilla, la partie "graphique" de gtk est inclue tandis que sous la distrib ben c'est partagé.
 
Pour avoir des applis qui soient inter-distrib, il faudrait donc qu'elles intègrent beaucoup de libs. Et là l'occupation disque explose.

ok vous m'avez convaincu  
mais alors, si on met libc, xlib, sdl, gtk et qt en standard sur toutes les distrib. ya moyen de faire des applis
directement compilées et qui fonctionneraient "alone".
lorsque je change de distrib ça éviterait ainsi de retélécharger toutes ses applis via les packagers

LSB
 
mais bon de toutes façons les systèmes de gestions de paquetages c'est tellement plus agréable à utiliser que de devoir aller chercher sur le net telle ou telle appli pour devoir ensuite s'assurer qu'on est à jour...

Non mais y a le problème des versions de lib quand même
Sinon pour aller plus loin dans ton raisonnement, tu peux fournir ton programme compilé statiquement avec les libs necessaires,
t'as meme plus besoin d'avoir les libs sur le système. Mais vla la taille de tes executables
 
En fait, la quasi-totalité des distributions Linux ont fait le choix d'avoir des bibliothèques partagées (les fameux .so).
L'avantage c'est que si t'as 100 programmes qui utilisent la même lib, elle n'est pas installée 100 fois.
L'inconvénient c'est que ton programme est lié à une version donnée (enfin ca peut marcher avec plusieurs versions, tant que l'ABI reste identique).
 
Une solution serait de fournir les executables :
- compilé en statique (pas de bib. partagées)
- ou avec les versions des libs nécessaires (souvent le cas sous Windows, avec les paquets de DLLs qui vont bien).
 
Mais dans tous les cas, c'est un choix difficile, avec avantages et inconvénients des 2 cotés.

pas inintéressant, quand on considère le système comme un plateforme de dev et d'execution on specifie les ver. des libs et descompilateurs toussa.
D'où l'initiative lsb 3.
Mais bon il existe encore des divergences dans les fs entre distro donc le programme one size fits all n'existe pas.
 
Et puis merde c'est un écosystème, faut adapter sa toolchain et ses outils de paquetage à la distro, c'est chiant mais c'est comme ca ( et une fois mis en place, c'est pas compliqué ).
D'où l'intérêt des empaqueteurs qui ont un rôle dans cet écosystème ! Il n'est pas à négliger du tout .

c'est marrant que tu dises ca j'ai lu y a quelques jours un article wiki sur un gestionnaire de paquets "universel" ... tu penses que c'est voué à l'échec ?

 
Bah je vois mal comment ils veulent y arriver ... Chaque distro place ses fichiers de manière différente... Donc soit ils se créent un fichier de config qui dit que le /etc/init.d des Debian-like est /etc/rc.d sur Archlinux , et leur système fait la conversion tout seul (bonne chance pour que ça marche correctement), soit voilà quoi...
 
Je vois vraiment pas comment ça peut marcher,à part si on défini une norme et que toutes les distro intéressées s'y collent (mais de là à ce que ce soit valable pour toutes les distro, et que ce soit donc universel ...)

Et puis est-ce que ça a vraiment un intérêt ?
Les spécificités des distros tiennent pour une grande part à leurs différences sur la gestion des packages ; si il s'agit de tout niveler pour que tout le monde utilise le même package manager, autant utiliser une distrib unique.
 
Après on peut imaginer un frontend universel, qui derrière utilise tous les package managers habituels, mais bon, l'intérêt me semble limité.
(c'est le but de PackageKit il me semble ?)

bien sur que ça a un intérêt    : il se trouve situé au niveau utilisateur et pas au niveau developpeur(s).
1 - cela rapprocherait les communautés, on serait pas obliger de poster/lire dans whatmille forums pour enfin
trouver LA réponse sur un pb de conf, de module...
2 - on pourrais enfin mettre en place un univers/logiciel de dev unifié, alors là je parle pas de make et gcc,
mais d'un front-end avec des patterns qui fonctionnent dans tous les cas de figure et version des lib.so, gtk ou qt
3 - les prog seraient donc dispo/installables plus facilement et plus rapidement au lieu d'attendre qu'un "packager" soit
dispo pour faire .rpm ou un .deb vu qu'une seule compil/build sera nécessaire au lieu d'en faire une pour chaque distrib.
4 - sauver la planete du réchauffement climatique quoi

 
Pour ma part, en résumé, oui. Tant qu'une techno ne s'impose pas toute seule cela veut dire que ce n'est pas la bonne ( je raisonne pas pour m$ qui impose des technos ), mais pour le libre. De plus, si il en existe plusieurs, c'est que tous ont leurs avantages. Un programme avec tous les avantages sans inconvénient, ca n'existe (malheureusement) pas.
D'ailleurs même le "one size fits all" n'est pas valable pour windows, pareil pour nux à cause du ".so hell" ou "dll hell" cad des conflits sur les versions de librairies (particulièrement sensible pour glibc ou libfortran par exemple.
 

 
+1
 
le standard, c'est LSB, mais pour le moment ce standard n'inclut pas de convention sur l'arborescence.
 

 
une surcouche n'est pas une mauvaise idée, faut qu'elle soit juste parfaitement codée et c'est autre chose.
 
puis linux est bien un écosystème donc qui vit avec tous ses packages managers, faut pas considérer ca comme la monoculture du soja ogm m$, nous il reste de la variété ( et c'est heureux )
 

 
pas faux... Mais c'est bien connu que le user de linux est un power user/dev. Pour les autres, ben ubuntu est pas mal, non ? D'ailleurs ils ont de bonnes idées quand à la gestion "grand public" des packages avecpar exemple le apt:// pour installer des paquets.

on peut être un power user, mais moi ce qui fait que je me décide pas à dev pour nux c'est que, il n'y a pas
de logiciel unifié d'une part et que pour diffuser mon prog. faut que je me tappe les spécifs de toutes les lib
version par version pour chaque distrib ou que je demande à des tiers de me le packager.
exemple :
- hey copain linuxien, j'ai dev un $uper logiciel qui compte les gouttes d'eau dehors qd il pleut... tu
le veux pour me le tester/debugguer?
- ouais envoi... (crak boum tac bipbipdezipplus tard) ...j'ai cassé ma mandriva la semaine dernière,
tu pourrais pas me l'envoyé (comprendre recompiler) pour gentoo  
- tu me fais [chier] , c'est quoi ton kernel number et ta version de libc??
- bah j'en sais rien, de toute façon la compil de ton log. a échoué (manque plein de dépendances ) pasque j'ai pas installé gtk+
tu comprends je voulais une power distrib. sans rien de superficiel...  
- bon bah je retourne à mon packager .rpm et le diffuser via sourceforge alors

Ben quand tu développes, tu ne diffuses que les sources. Ton fichier "configure" doit lui vérifier les dépendances à la compil.

Ensuite si une distrib' veut l'intégrer, c'est le boulot du packager de faire un .deb ou .rpm. Si ca passe, il l'intègre sinon il te dira qu'il a un problème.

EDIT: si le packager a un problème, il le dit mais rajoute la dépendance dans son paquet.

Développeur et Packager sont 2 rôles différents.

oui je me suis mal exprimé je parlais bien de package kit

voilà c'est un peu comme ca que je le voyais

c'est là que les pb commencent pour le(s) user(s) "lambda", dans le monde du logiciel, on ne dit pas
"prends les sources et compile le"  on dit plutot : "clique dessus et regarde ce qu'il se passe".
tout le monde n'installe pas de compilateur idoine sur sa machine linux. tu vois le pb?
autre exemple concret :
- j'ai un net-book qui me sers de diag., j'ai un eeexubuntu dessus. c'est une distrib. light sans compilateur (comprendre
sans les sources du kernel et les package d'include -dev...)
- j'avais trouvé un logiciel (freediag pour ne pas le citer), pour lequel je n'ai pas trouvé de .deb (ni même dans le packager); je n'ai pas
pu le compilé depuis mon netbook , j'ai du installé un eeexubuntu virtuel et rajouter tout les utils de dev, pour le compiler
depuis une autre machine et le transferer enfin et l'essayer en live; puis de toute façon, il n'a pas marché
à cause d'un pb de numero hexa hardware . donc j'utilise wine avec un logiciel win32.  
 
même chose pour un logiciel de gestion boursière écrit en python qui n'a jamais voulu fonctionné car
la version de python pour lequel il avait été prévu n'existait pas dans ma distrib. et qu'il fallait que je
me retappe des installs de dépendances à la stabilité douteuse.
 
j'ai beau être un power user têtu, ce genre de pratique me "fatigue"  

Passe au Mac

j'ai un iphone

Bah en plus