Les autotools sont franchement superbes. Couplé avec CDBS, le .deb est d'un simplicité déconcertante.
Non la faut arreter. Les autotools sont surement pas superbe. Problèmes incéssant de rétro-compatibilité. Moi qui suit le premier à être pour le lachage des vieilles API je dois bien dire que avec ça je suis plutôt bien embetté. Dès qu'il y a une nouvelle release faut bricoler un truc qui tiens d'un hack en semi bash-script dans les configure.ac pour faire passer les compiles sur les 3 ou 4 dernière sous versions des autotools (soit des debianeux aux gentooistes).
C'est justement le but des autotools de faire quelque chose multi-plateformes ET multi-versionnages...
Alors oui ils sont puissant, tout le monde en a l'habitude et il n'y a pas un seul equivalent potable à l'horizon. Mais ça reste un réel problème.
Et en ce qui concerne les .deb il faut arreter de croire que Debian est la seule distrib binaire qui existe. Je ne sais pas comment sont fait les .rpm mais en tout cas les .deb sont très loin d'être un bon format, entre dpkg et sa db ridicule qui est lente et se brise pour un rien, les scripts bash et perl qui bricole un peu avant et apres l'installation des paquets histoire de faire du pseudo 0config, le tas de fichiers de config qui trainent sur quasiment toutes les sources libres (ce fameux dossier "debian" qui traine de partout... heureusement que les autres distrib ne font pas pareil) et la cerise dans tout ça c'est apt qui est d'une incapacité déconcertante (par exemple verifier l'espace disque nécessaire _total_ AVANT de lancer une install pour pas s'arreter au milieu comme un con). Et encore NON aptitude et smart ne valent pas mieux.
[pub]
Personnelement je suis passer d'un tout apt/dpkg à pacman par Arch et ben je suis jamais repartis. Un système à la FreeBSD port+binaire mais en propre et qui marche.
[/pub]
Vrai. Ce qui serait chouette, c'est un format commun XML de description d'interface (XUL ?)
Encore une fois. Si on pouvait eviter de mettre du XML pour tout et surtout n'importe quoi ce serait bien. Franchement n'importe qu'elle appli en XUL est lente pour se lancer (et ça au moins c'est commun à toutes les plateformes supportées). Avoir un fichier XML commun pour tout les toolkits reviendrais à perdre du temps à parser un truc qui ne peut même pas exploiter les points fort de chacuns parce qu'il doit être interropérable. Gtk à ses Glade, Qt ses Kdevelop développer en Glade/PyGtk ou en Kdevelop/C++ c'est simple, extrement rapide et franchement accessible à n'importe qui.
A propos de FDO
Il y a du bon et du mauvais dedans. DBus et HAL font partis du bon. Côté mauvais FDO est quand même très gnomistes et certaines propositions de specs passe à la trappe sans raison (par exemple celles conernant le trayer).
Bien que ça commence à venir, il manque aussi un peu de volonté par les developeurs qui ne suivent pas forcément toutes les normes (exemple le path du dossier de config, histoire d'arreter de remplir les home avec des .machins)
Et en ce qui conerne l'idée du journal : il vaut mieux avoir des developeurs qui perdent du temps à forker et a travailler dans différentes directions. Même si c'est contre-productif. Imagine les tous sur un projet commun, ils passeraient leurs temps a se tirer dans les pattes et on aurait qu'un seul projet qui partirait dans tous les sens. Ca ferait des programmes avec des menu de 3km de long, un seul bouton dans la toolbar et le tout qui se gère entierement au clavier.
Il n'y a peut être qu'1% d'utilisateurs sous linux/bsd/etc.. mais au moins ce 1% est satisfait parce que son desktop fait ce qu'il veut. Les 99% autres eux si ils en sont content c'est uniquement parce qu'ils n'ont aucun élément de comparaison.
[^] # Re: Vive le développement libre !
Posté par moo2 . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 0.
Non la faut arreter. Les autotools sont surement pas superbe. Problèmes incéssant de rétro-compatibilité. Moi qui suit le premier à être pour le lachage des vieilles API je dois bien dire que avec ça je suis plutôt bien embetté. Dès qu'il y a une nouvelle release faut bricoler un truc qui tiens d'un hack en semi bash-script dans les configure.ac pour faire passer les compiles sur les 3 ou 4 dernière sous versions des autotools (soit des debianeux aux gentooistes).
C'est justement le but des autotools de faire quelque chose multi-plateformes ET multi-versionnages...
Alors oui ils sont puissant, tout le monde en a l'habitude et il n'y a pas un seul equivalent potable à l'horizon. Mais ça reste un réel problème.
Et en ce qui concerne les .deb il faut arreter de croire que Debian est la seule distrib binaire qui existe. Je ne sais pas comment sont fait les .rpm mais en tout cas les .deb sont très loin d'être un bon format, entre dpkg et sa db ridicule qui est lente et se brise pour un rien, les scripts bash et perl qui bricole un peu avant et apres l'installation des paquets histoire de faire du pseudo 0config, le tas de fichiers de config qui trainent sur quasiment toutes les sources libres (ce fameux dossier "debian" qui traine de partout... heureusement que les autres distrib ne font pas pareil) et la cerise dans tout ça c'est apt qui est d'une incapacité déconcertante (par exemple verifier l'espace disque nécessaire _total_ AVANT de lancer une install pour pas s'arreter au milieu comme un con). Et encore NON aptitude et smart ne valent pas mieux.
[pub]
Personnelement je suis passer d'un tout apt/dpkg à pacman par Arch et ben je suis jamais repartis. Un système à la FreeBSD port+binaire mais en propre et qui marche.
[/pub]
Encore une fois. Si on pouvait eviter de mettre du XML pour tout et surtout n'importe quoi ce serait bien. Franchement n'importe qu'elle appli en XUL est lente pour se lancer (et ça au moins c'est commun à toutes les plateformes supportées). Avoir un fichier XML commun pour tout les toolkits reviendrais à perdre du temps à parser un truc qui ne peut même pas exploiter les points fort de chacuns parce qu'il doit être interropérable. Gtk à ses Glade, Qt ses Kdevelop développer en Glade/PyGtk ou en Kdevelop/C++ c'est simple, extrement rapide et franchement accessible à n'importe qui.
A propos de FDO
Il y a du bon et du mauvais dedans. DBus et HAL font partis du bon. Côté mauvais FDO est quand même très gnomistes et certaines propositions de specs passe à la trappe sans raison (par exemple celles conernant le trayer).
Bien que ça commence à venir, il manque aussi un peu de volonté par les developeurs qui ne suivent pas forcément toutes les normes (exemple le path du dossier de config, histoire d'arreter de remplir les home avec des .machins)
Et en ce qui conerne l'idée du journal : il vaut mieux avoir des developeurs qui perdent du temps à forker et a travailler dans différentes directions. Même si c'est contre-productif. Imagine les tous sur un projet commun, ils passeraient leurs temps a se tirer dans les pattes et on aurait qu'un seul projet qui partirait dans tous les sens. Ca ferait des programmes avec des menu de 3km de long, un seul bouton dans la toolbar et le tout qui se gère entierement au clavier.
Il n'y a peut être qu'1% d'utilisateurs sous linux/bsd/etc.. mais au moins ce 1% est satisfait parce que son desktop fait ce qu'il veut. Les 99% autres eux si ils en sont content c'est uniquement parce qu'ils n'ont aucun élément de comparaison.