Je sais pas vraiment de quoi tu parles.. la compilation de gcc ou compiler avec gcc? Parce que make, autotools t'en as pas besoin avec gcc. T'es pas obligé d'avoir des Makefile. Tu peux faire du scons, du distcc par exemple. Ou alors tu fais un shell script a la main. Et gcc ne dépend pas du tout de Linux. Je sais pas où t'as été chercher ça. C'est plutôt l'inverse car Linux utilise des spécificités de gcc. C'est aussi pour ça que Clang par exemple est obligé de se plier à ses spécificités s'il veut un jour pouvoir le remplacer complètement.
Pour compiler gcc il faut au moins le compilateur C de Unix "cc".. et c'est tout.

Concernant GNAT je n'en sais rien.. jamais fais de l'ADA de ma vie.

Puis tu dis que tu ne vois pas de grosses différences de vitesse en passant de 2 à 4.. je comprend pas.. vitesse de quoi? Compilation, exécution des softs? Si tu parles des optimisations des softs, vu que beaucoup d'architectures n'étaient pas supportées avec le 2.95 c'est difficile de comparer. Sans compter tous les jeux d'instructions qui n'existaient pas a l'époque. Maintenant si tu compiles avec exactement la même architecture et sous-architecture alors t'auras forcément une différence mais relative. Ca dépend aussi le genre de soft, si tu as compilé gcc avec cloog/ppl par exemple (qui lui existe que depuis gcc 4.4, alors niveau nouveautés y en a.. sans compter que cloog/ppl est indépendant de l'architecture.. toi qui dit que ca avance que sur le x86.. bah je trouve pas). Genre ARM, tous les jeux d'instructions sont supportés, je sais pas ce que tu veux de plus. Comme NEON, c'est sûr qu'avec un vieux gcc t'auras aucune chance vu que ca n'existait pas.

Maintenant si tu parles de la vitesse a laquelle gcc compile. Forcément plus il y a d'astuces pour optimiser le code, plus ca sera long à compiler.

Pour terminer, gcc est toujours très à jour sur tous les derniers standards avant même leurs sorties officielles.

PS: pour la petite histoire, gcc a même été porté sur le Smaky (et tout ce qui est en C dans le Smaky est compilé avec celui-ci).

fbianco a écrit:

tguillod a écrit:

Pour octave, ce n'est vraiment pas une alternative à matlab (environ 10% des fonctions je pense). La partie graphique est totalement hétérogène. Des choses qui sont faisables en 1h avec matlab pour demander la journée avec octave. De plus octave n'est pas indépendant de matlab: plein de fonctions sont pas documentés et on est obligé de lire le code pour voir ce que ca fait (faut pas être pressé) ou lire la doc de matlab (en priant pour que ce soit pareil).
A part ca je conseillerais octave pour les lycées. Là il y a pas besoin de plus (dans mon ancien lycée on avait des vieux maple et c'était pas top). Mais après matlab/mathematica sont vraiment indispendable (et ca tourne très bien sous unix).

Je fais mes graphiques et calcul avec ipython+pylab. Le collège où j'étais qui faisait du TurboPascal à l'époque est passé à Python pour le cour d'application des maths ! C'est super d'avoir appris cela. Sinon je pense qu'octave fait bien plus que 10%, j'avais fais tourner des scripts matlab sans problème il y a déjà 3 ans.

Maintenant il y a ceux qui n'aime pas Octave parce qu'il n'y a pas les gadgets tel que Simulink. Ou alors le toolkit pour modéliser les filtres numérique et analogique (ca empêche pas de tout pouvoir faire depuis les commandes). Un Simulink c'est vachement pratique, c'est bien clair..
Mais Scilab permet de faire un peu comme Simulink d'ailleurs. C'est une alternative complète a Matlab et Octave.

Pour revenir au bureau sous GNI/Linux. Il est multiple. Il y a d'abord le fait que pendant longtemps la plupart des distribution proposaient des kernels qui étaient optimisés pour faire des serveurs, beaucoup de bande passante et une latence relativement élevée, alors qu'avec un bureau il est préférable d'avoir une latence plus faible et une meilleure réactivité, même si cela implique rmoins de bande passante.

Les premiers bureaux Linux étaient souvent basés sur fvwm. Les distributions se donnaient la peine de faire de configurations fvwm qui tenaient la route. Puis les gnome et kde sont arrivés, avec leurs nombreuses sur couches. Ils ont été adoptés par les distributions puis par les utilisateurs. Les anciens gestionnaires de fenêtres ont continué leur évolution. Le tout s'est passé généralement bien, même si parfois de manière un peu chaotique. Dans l''ensemble tout a très biien été jusqu'au passage de kde3 à kde4.

Linux était avant ce passage l'OS qui se développait le plus rapidement sur le marché du desktop. Comme kde4 n'est pas compatible avec kde3, de nombreux logiciels ont simplement disparu, leurs développeurs estimant probablement qu'ils ont autre chose à faire de leur temps libre que de refaire la partie la moins intéressante de leurs logiciels, le GUI. D'autres logiciels ont vu des versions très abouties  et riche en fonctionnalité, même si parfois un peu bogué (par exemple kaffeine), être remplacé par des versions qui n'offrent pas le quart des fonctions proposées dans les versions kde3, et ceci alors qu'ils parlent aujourd'hui de passer à wayland.

Hasard ou pas, je n'en sais rien, mais toujours est-il que le fait est là: depuis le passage de kde3 à kde4, Linux n'est plus l'OS dont les part sur le marché du desktop augmente le plus.

Ensuite il faut bien voir que du hardware au bureau, Linux est un ensemble de couches superposées relativement complexes. J'utilise Linux depuis mon 386 et j'ai donc suivi toute l'évolution. Fvwm, *box, les premières version d'enlightenment, puis gnome, je n'ai jamais supporté sa politique de focus de la souris, donc je ne l'ai jamais vraiment utilisé, puis kde. Je me suis aussi fatigué de kde, car même s'il propose de nombreuses options de configurations, ses fonctions de base comme les politique de placement de fenêtre et de focus de la souris sont tellement pauvres par rapport à fvwm, qu'en comparaison elles sont boguées.

De plus, aucun autre gestionnaire de fenêtre ne peut rivalisé avec fvwm en terme de souplesse. Fvwm est non seulement un excellent gestionnaire de fenêtre, il est en même temps un véritable tool-kit pour la Xlib. Je me suis mis à la recherche d'alternatives, fluxbox, puis xfce, et après avoir piqué une colère monumentale parce qu'un update de xfce m'avait fait perdre toutes les modifications du menu des applications, j'en suis revenu à fvwm avec fvwm-crystal. Après avoir contribué quelques nouvelles fonctions comme les contrôles de mplayer, alsaplayer et alsamixer, ainsi que rendu compatible de menu des applications de fvwm-crystal avec la norme freedesktop, je suis de fil en aiguille devenu le principal développeur de cette chose.

À propos du menu des applications, fvwm-crystal est le seul bureau GNU/Linux qui prend en compte de façon complète les catégories additionnelles de la norme freedesktop, et ceci dans n'importe qu'elle distributions. Ce qui en fait le menu des applications qui nécessite le moins de maintenance de la part de l'utilisateur. Cette norme est un peu bordelique. Elle repose sur un double mécanisme, des fichiers de menu dans /etc/xdg/menus et /usr/share/desktop, fournis par les bureaux et/ou par les distributions. À ce niveau là, elle est très difficile à implémenter car chaque bureau à ses particularités qui les rendent plus ou moins incompatibles avec les autres. En plus, il y a les fichiers desktop fournis par les applications dans /usr/share/applications. Avec fvwm-crystal, après avoir envisagé de porter le système de menu de Debian sous fvwm-crystal, j'ai pris le parti de ne pas fournir de fichier de menus et de ne m'intéresser qu'aux fichiers fournis par les applications. Le résultat est une bien bien plus grande compatibilité avec les catégories additionnelles de la norme que n'importe quel bureau et même que le menu de Debian. Si une application n'apparaît pas dans la bonne catégorie, c'est parce que le fichier desktop fourni par cette application ne contient pas la bonne catégorie. Et de toute façon, il apparaitra aussi dans la mauvaise catégorie avec les autres bureaux.

Cet exemple du système de menu xdg qui n'est implémenté que de façon partielle par les bureaux et par les distributions n'est qu'un exemple parmi d'autre de fonctions qui ne sont implémentée qu'en parie, et dont l'implémentation ne sera jamais terminée. Je trouve personnellement bien plus important d'avoir le support de ces catégories additionnelles que de pouvoir faire tourner mon bureau dans tous les sens, car cela me permet de ne pas perdre mon temps avec la maintenance du menu.

Dans mon travail de développement de fvwm-crystal, je me suis rapidement rendu compte que les gestionnaires de session comme gdm ou kdm interféraient avec mon travail. Ils piratent certaines des données que je m'attendais à trouver dans les fichiers de log, rendant ainsi le débogage impossible. J'en suis donc revenu au bon vieux startx. L'avantage d'un système comme startx est sa simplicité. De plus il est possible de le scripter dans tous les sens, donc il est en fait beaucoup plus souple et flexible que les logins graphiques.

Puis il y a consolekit qui est arrivé. Startx ne fonctionnait plus avec fvwm, car celui-ci ne lançait pas consolekit, et à partir du moment ou polkit et consolekit sont installés, ils veulent tout gérer. Après avoir rencontré d'autre petit problème avec ces deux stupides logiciels qui pensent mieux savoir que l'utilisateur ce qu'il veut faire, problèmes comme l'impossibilité chronique d'accéder aux imprimantes déjà configurées après un update du système, j'ai fini par virer *kit et ce genre de problèmes ont été définitivement éliminés.

Et maintenant nous avons d'un côté l'usine à gaz de qualité bêta nommée systemd qui arrive dans la majorité des distributions binaires, c'est ça et gnome ou pas de systemd et pas de gnome. et wayland qui pointe le bout de son nez. Sur wayland, sa couche de compatibilité avec X, vu la complexité de X et de ses nombreuses extensions, ne sera jamais ni complète ni terminée. Ce qui nous ramène à une situation comparable à celle du passage de kde3 à kde4 : quels programmeurs vont faire l'effort, sur leur temps libre, de porter leurs applications sur wayland, et ainsi de refaire ce qu'ils ont déjà fait et qui consiste généralement en la partie la moins intéressante de leurs programmes?

Rien qu'à cause de cela, je pense que X a encore de beaux jours devant lui. Ce ne sera d'ailleurs pas forcément sous linux mais peut-être sous d'autres systèmes comme BSD. Pour le moment, la seule chose qui me retient encore sous Linux, c'est que de nombreux softs que j'utilise comme le GEDA où des logiciels audio ne sont pas portls sous BSD. Mais si linux continue à décourager des développeurs en cassant leurs programmes, j'en connais plusieurs qui sont passés sous BSD, ou sont en train de migrer, cela pourrait changer. On verra bien.

Quand au problème de système cassé après des updates, je n'ai jamais connus cela sous gentoo. Par contre avec les distributions binaires, c'est un tout autre problème. C'est la raison principale qui m'a fait passer sous gentoo. L'utilisateur de bureau typique dont je suis installe généralement, en plus des dépôts de la distribution, plusieurs autres dépôts complémentaires. Plus le nombre de ces dépôts augmente, plus cela devient un casse-tête chinois pour apt ou rpm de satisfaire les dépendances entre des dépôts distants, car moins il y a de chance que ces dépôts soient synchronisés.

Avec une distribution source comme gentoo, ce problème n'existe pas car le dépôt, c'est ce qui est installé dans la machine, et quand un programme est cassé suite à un update, portage le repère et se  charge de le recompiler et de le réinstallé, garantissant ainsi la cohérence du système. Ce qui donne qu'à l'arrivée, pour du bureau, gentoo en testing (l'équivalent de debian unstable, lequel n'existe pas sous gentoo) est plus stable que debian stable. Tout en étant plus rapide, mais on peut arriver à une vitesse très proche sous les distributions binaires simplement en installant son propre kernel.

Un exemple typique de la complexité parfois délirante de Linux est l'audio. Il y a différents serveurs sons, ALSA et tous les autres, qui tous s'appuient sur ALSA. Le résultat final pour l'utilisateur non averti est qu'il est plus facile de s'y perdre que d'avoir un système fonctionnel. Et comme souvent sous Linux, les principaux protagonistes, la LAD, ne sont même pas consultés quand il s'agit de développer de nouvelles fonctions, et quand ils sont consultés, ils se font traités de desktp haters par des gens qui feraient peut-être mieux de faire de la politique que du logiciel. Si je compare pulseausio avec JACK, JACK existait depuis longtemps quand pulseaudio a débarqué. des efforts importants ont été fournis pour développer pulseaudio, lequel ne sera jamais capable de fournir une latence constante du son. Au premier xrun, la latence de pluseaudio augmente, et le seul moyen pour la faire redescendre est de stopper et redémarrer pulseaudio. Ceci implique que pulseaudio, s'il est suffisant pour un usage de base, ne sera jamais un serveur son professionnel.

Dans la même temps, ALSA et JACK ont continué d'être perfectionnés, et il est aujourd'hui possible avec quelques lignes dans ~/.asoundrc, en utilisant le plugin PCM jack d'ALSA, d'interfacer ALSA et JACK de façon stable et sans latence additionnelle mesurable, et de retrouver ainsi les applications ALSA dans le graphe de JACK, ce qui permet de profiter des avantages de JACK que sont l'exécution synchrone de tous ses clients et une latence constante, ainsi que de sa souplesse d’interconnexion, toutes des caractéristiques qui font de JACK le meilleur serveur son professionnel de tous.

Je suis convaincu que si les gens qui se sont lancés dans pulseaudio avaient tenu compte des remarques des développeur de la LAD, bien moins d'efforts auraient été nécessaires pour développer quelque chose de meilleur que ce serveur son non professionnel qu'est pulseaudio. Toutes les briques de base existaient déjà dans ALSA et JACK. En fait cette solution professionnelle et flexible existe, ce sont les développeurs d'ALSA et de JACK qui l'ont développée: Tuto: router un flux ALSA vers JACK.

Dernière modification par libre (23 Feb 2014 02:36:53)