Tout d'abord, même si ce journal réalise, plus bas, une comparaison avec Win---s, il ne s'agit pas d'un Troll mais d'une réflexion à 0,2 centimes sur l'avenir de Linux et des Unix en général.
Programmeur Unix et Windows, il m'est bien évidemment arrivé de comparer les deux systèmes et surtout leur interface de programmation.
Linux implémente de multiples normes Posix, BSD et autres qui finissent par rendre l'interface de programmation extrêmement complexe à utiliser. Il y a très peu d'homogénéité dans les appels systèmes et les objets manipuler (descripteur de fichier, handle de thread, sémaphore/message IPC,
). Résultat impossible, par exemple, d'attendre simultanément la fin d'un thread ou la mort d'un processus ou l'arriver d'un signal ou de données sur une socket, car tous ces objets sont représentés par des objets différents (tout du moins en apparence). La notion de Handle à la Windows étant beaucoup plus souple.
Mais Linux et certainement bien d'autres Unix ont une conception interne moderne qui permet de réaliser des traitements génériques sur beaucoup d'objets du noyau grâce à un approche objet (bien qu'écrit en C). Il ne serait donc pas, enfin je pense, si difficile de fournir une interface de programmation beaucoup plus homogène qui cohabiterait avec celles disponibles aujourd'hui et permettrait de manipuler les mêmes objets noyau avec plus de souplesse.
J'ai certains collègues qui sont fervents utilisateurs de Linux mais qui préfèrent largement programmer sous Windows justement car c'est beaucoup plus simple. J'ai vu plusieurs projets réalisés sous Windows uniquement car le coût de la partie développement était estimé inférieur sous Windows que sous Unix/Linux. Alors certes la compatibilité et le respect des normes c'est essentiel, mais il va bien falloir que Linux et d'autre OS se décident à fournir une API système mieux pensée sous peine de disparaître.
Voilà c'était ma réflexion à 0,2 centimes !
Journal API de programmation système et Linux : et si
20
fév.
2004
# Re: API de programmation système et Linux : et si
Posté par Fabimaru (site web personnel) . Évalué à 1.
# Re: API de programmation système et Linux : et si
Posté par aille . Évalué à 8.
Regardons par exemple DirectX.
- La compatibilité n'est pas assurée entre les versions : dans Direct3D, tout un mode d'utilisation a disparu entre la version 5 et la version 6.
- Les fonctions ont des noms ésotériques, en plus de trainer des casserolles dus à des erreurs de conception du début : LP.... pour signifier le "long pointer" du DOS, des fonctions foo32 et foo16, xxxXxxx3 et xxxXxxx2 parce que l'interface a changé entre 2 versions ...
- Des problèmes pointeresques hallucinants, qui rendent le portage impossible vers quoique ce soit. On me répondra que ce n'est pas grave, windows est standard... avec lui-même !
- Extension des normes... pour mieux enfermer le programmeur sur la plate-forme.
-Documentation.... comment dire..... fleuve. Pour ma part, je préfère la qualité à la quantité. OU carrément pas de doc parce que la fonction n'est pas implémentée ! (c'est du vécu)
Sous linux, on se retrouve avec un florilège de bibliothèques qui font les mêmes choses, mais en réalité il n'y en a que 2 ou 3 qui valent le coup de s'y intéresser, et qui sont dédiées à un besoin clairement établi. Pour ces lib, l'interface est en général assez bien pensée, et en cas de soucis, il y a toujours moyen de s'adresser à une mailing-list, ou la réponse vient bien plus vite que d'aller chercher quoi que ce soit sur msdn (je préfère ne pas en parler, de celui-là). Etrangement, tous les langages/lib que j'ai vues ont l'air de beaucoup plus se soucier de la compatilibité que Microsoft de ses clients !!
Et la doc !!!! Ahhh !!!! Un vrai bonheur !!!! Simple, direct, efficace !!!
Bref, pour moi, c'est sans retour. Linux, sinon rien !
[^] # Re: API de programmation système et Linux : et si
Posté par Michael Hauspie . Évalué à 4.
Par contre, je suis complètement convaincu par l'API de DirectX ! Etant donné que tu ne cites que la version 5 ou 6 (qui je te l'accorde avaient une API horrible), je suppose que tu n'as pas regardé la tête de l'API depuis directx 8...
Elle est claire, complètement objet et PARFAITEMENT documentée (de même que le reste de l'API win32, perso j'aime les MSDN). En ce qui concerne la notation hongroise, même si je n'adhère pas car je ne trouve pas ca esthétique :), il faut bien décider d'une norme de programmation quand on programme en équipe. Je ne trouve d'ailleur pas plus élégante la norme du kernel linux (et je sais de quoi je parle pour avoir développé 1 ou 2 modules...) mais c'est une norme, un choix fait par une équipe de développeur, et ce n'est a mon sens pas critiquable... On pourrait critiquer un source sans norme qui n'ecrit jamais deux fois de la même façon les mêmes choses....
Pour ce qui est de la portabilité (même si ce n'etait pas du tout le sujet du thread...) je dirait simplement que l'API unix est compatible... avec les Linux/Unix like... Moi quand je fais du X11 sous windows, ca marche pas.... Pour prendre un autre exemple, OpenGL est portable d'un point de vue OS, en effet... qu'en est il d'un point de vue hardware ? En effet, si on veut faire de la 3D évoluée en GL, il faut passer par les extensions... donc oublier la portabilité ATI/nVidia... l'API de GL, si elle est de toute beauté, n'en est pas moins en retard d'au moins 5 ans....
Tout ca pour conclure que oui, je suis d'accord avec le fait qu'une API légèrement mieux pensée ne pourrait faire que du bien aux Unix/Linux...
[^] # Re: API de programmation système et Linux : et si
Posté par Jux (site web personnel) . Évalué à 1.
Meme chose en Direct3d, toutes les cartes ne supportent pas Directx9 .
Les extensions OpenGL sont just un moyen d'avoir les fonctionnalités avant le truc officiel (le multi-texturing est en extensions ARB avant la 1.3, après, c'est intégré directement). Ce serait comme utiliser des fonctions de Directx9 depuis Directx8.
Ensuite, la majorité des extensions ARB sont supportés par les carte graphiques ( ma GeForce2GO support les vertex shader (ARB_vertex_program)).
Après, c'est si tu veux vraiment faire quelque chose de super-spécifique avec une carte...
Pis bon, tu regardes les extensions dans les deux grandes marques (ATI et nvidia). A par le préfixe devant, ce sont les mêmes...
Pis pour la portabilité, me semble que Doom III tourne sur Nvidia et ATI, quake 3, ut2003/2004 aussi d'ailleurs :-P
Ensuite, niveau retard, je n'en suis pas convaincu... Enfin, un peu, mais pas 5 ans. La preuve : ut2003 affiche __exactement__ la même chose en direct3d ou OpenGL, Doom III est l'un des plus beau jeux que j'ai vu tourner et c'est de l'OpenGL, va faire un tour du côté d'Ogre si tu veux de la réfléxion fresnel en OpenGL ...
[^] # Re: API de programmation système et Linux : et si ?
Posté par calandoa . Évalué à 3.
Il y a effectivement des trucs assez chiants sous linux, du style ouvrir une socket ou récupérer la taille d'un fichier avec les appels C standards (bien qu'on puisse toujours utiliser une surcouche de bibliothèques) et c'est énervant de se dire qu'en 2004 on se tape encore une api préhistorique... malheuresement il n'y a aucun nouveau standard en vue pour améliorer cet état des choses bien que certaines bibliothèques comme la glib soient assez courantes pour pouvoir les utiliser.
Sous windows (plus précisement avec les MFC) même si le code est plus concis et faire une application simple prend moins de temps, je trouve l'api particulièrement crad. Le code généré par le wizard est absolument incompréhensible, les fichiers sources regorgent de macros qu'on est censé modifier que par l'interface graphique, les appels peuvent être contraire à la philo du c++ (par ex: pour transformer le curseur souris en sablier, on instancie juste en local une variable d'un type particulier. Le constructeur change le curseur, et le destructeur exécuté automatiquement à la fin de la fonction le restaure : c'est peut être rapide, mais c'est surtout affreusement crad). Le résultat est que pour une application conséquente, le code devient un véritable bordel et il est particulièrement difficile de comprendre ce qui s'y passe pour pouvoir le debug'er...
En gros je dirais que sous windows c'est plutôt pratique, et sous unix/linux c'est plus carré
Par contre concernant le support, y a pas photo... entre les forums sur le net basés sur l'entraide entre dév et une hotline où il faut filer son num de CB, le choix est vite fait...
[^] # Re: API de programmation système et Linux : et si ?
Posté par pasBill pasGates . Évalué à 1.
Euh tu sais qu'il y a des forums MS ou les devs MS trainent ainsi qu'un tas de gens qui developpent sous Windows(newsgroups).
[^] # Re: API de programmation système et Linux : et si ?
Posté par gnujsa . Évalué à 1.
Comme quoi la légendaire communauté du libre... c'est peut être pas pareil...
# Re: API de programmation système et Linux : et si
Posté par Epsos . Évalué à 3.
Utiliser une librairie d'abstraction type ACE qui rend tout ca transparent pour l'utilisateur et multi plateforme...
[^] # Re: API de programmation système et Linux : et si
Posté par kesako . Évalué à 1.
[^] # Re: API de programmation système et Linux : et si
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 2.
qui contient wxBase qui permet aussi de gerer tout ce qui n'est pas graphique
# Re: API de programmation système et Linux : et si
Posté par kolter (site web personnel, Mastodon) . Évalué à 7.
déjà ce que j'apprécie avec Unix/Linux c'est que l'API est libre, claire, documentée, localisé (des fois non négligeables pour les trucs pointus).... et accessible rapidement un coup de man ou de info et le tour est joué..... (et je parle pas des outils qui me permettent de m'en servir qui sont aussi libre, le compilo, l'éditeur...)
en général l'API système est faite de petites "briques" de bases qui font chacune des choses simples..... bienque j'admette qu'il y' quelque fonctions fourre-tout....
et c'est là qu'est pour moi la modularité.....
contrairement à toi qui pense que la modularité est dans des fonctions de plus au niveau qui utilise les briques de bases pour faire des trucs classiques qui sont dans l'API système de Windows, mais bon ça reste une question goût....
en ce moment je développe un truc système, c'est à dire faire fonctionner ça http://www.magicball.de/(...) (via port série) sous Linux (et autre unix) et je suis bien content d'avoir une api simple et fonctionne toujours aussi bien sur mon pc de bureau que sur mon petit portable 486 4 Mo de RAM (sous slack) sans avoir à rajouter quoi que ce soit sauf libiconv (mais c'est plus très système).....
Alors certes la compatibilité et le respect des normes c'est essentiel, mais il va bien falloir que Linux et d'autre OS se décident à fournir une API système mieux pensée sous peine de disparaître.
rien ne t'empêche d'en faire une surcouche (si ce n'est déjà fait) mais la compatibilité ascendante, je doute qu'elle disparaisse.....
M.
[^] # Re: API de programmation système et Linux : et si
Posté par Boke Bocadillo (site web personnel) . Évalué à 1.
ca marche a 360° sur les deux axes?
[^] # Re: API de programmation système et Linux : et si
Posté par kolter (site web personnel, Mastodon) . Évalué à 2.
M.
[^] # Re: API de programmation système et Linux : et si
Posté par un_brice (site web personnel) . Évalué à 1.
T'est dev là bas et t'as accès aux produits pas encore comercialisés ?
Et sinon, elle seras vendue en France ?
[^] # Re: API de programmation système et Linux : et si
Posté par kolter (site web personnel, Mastodon) . Évalué à 2.
c'est fait par une boite allemande http://www.lumino.de/(...) mais je suis pas sur qui le commercialise encore....
enfin, j'en ai trois et comme j'ai rien trouvé pour le faire fonctionner sur mon OS, je m'y suis mis....
M.
# Re: API de programmation système et Linux : et si
Posté par . Takhi . Évalué à 5.
La Glib me semble etre une jolie surcouche à de nombreux elements systemes .. que ca doit réseau, fichiers, tu as un systeme de boucle d'events... Ca nous a rendu service en tout cas :)
[^] # Re: API de programmation système et Linux : et si
Posté par fredix . Évalué à 1.
http://gnetlibrary.org/(...)
Bref des solutions portables existent il suffit de chercher un peu .............
# Re: API de programmation système et Linux : et si
Posté par Benoit . Évalué à 1.
L'utilisation d'une couche d'abstraction revient à tenter de simplifier une situation devenue compliquée sans aucune raison. La gestion est bien faite dans le noyau, l'API complique tout donc je remets une couche pour tenter tant bien que mal de simplifier la chose. Chercher l'erreur.
Un doux rêve serait que Linux devienne leader dans le domaine en offrant, en sus des anciennes, une nouvelle API homogène et agréable à utiliser qui finirait par être adopté par d'autre Unix.
[^] # Re: API de programmation système et Linux : et si
Posté par kolter (site web personnel, Mastodon) . Évalué à 3.
et puis si tu veux mettre linux dans de l'embarqué t'as besoin d'une API simple, rapide qui génère le moins de code binaire possible alors c'est très bien comme c'est.....
pour les malades de l'objet, c'est déjà fait... qt propose déjà pas mal de fonctions système de base....
cété ma visoin, après c'est une question de goût
on aura peut être bientôt une norme POSIX objet... qui sait ?
M.
[^] # Re: API de programmation système et Linux : et si
Posté par Benoit . Évalué à 2.
Il ne faut pas confondre facilités offertes par un langage et technique de programmation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.