SDL (Simple DirectMedia Layer) est une bibliothèque multiplateforme orientée vers les jeux vidéo.
Elle permet de gérer la majorité des aspects nécessaire au développement afin de rendre le code portable. Elle fournit ainsi des API pour prendre en charge l'affichage, le son, les différents événements d'entrée (clavier, manette, souris…), les interactions avec le gestionnaire de fenêtre ; ainsi que des bibliothèques optionnelles de facilité (pour le réseau, les polices de caractère, les formats d'images, le mixage de son).
Après une très longue période de maturation, SDL 2.0 arrive enfin ! Pour cette version 2, en plus d'un mise à niveau majeure de l'API, la licence passe de la LGPL v2 à la licence zlib afin de faciliter son adoption.
Les principaux changements
Plate-forme
Le support officiel des plate-formes iOS et Android est assuré. On notera également une mise à niveau de l'API pour profiter des spécificités de tels matériels comme les écrans tactiles, le niveau de batterie, ou l'utilisation du clavier virtuel.
Les plate-formes OS/2 et Mac OS 9 ne sont actuellement plus supportées, mais les patchs sont les bienvenus.
Sous Linux, SDL est traditionnellement conçu pour fonctionner avec un serveur X via la bibliothèque Xlib, mais des portages de la communauté sont en cours pour Wayland et pour Mir.
Binding
La bibliothèque est écrite en C et ne dispose pour le moment que de quelques bindings : pour Python, Pascal et C#. Nul doute que la situation va évoluer pour prendre en charge l'éventail de son ancêtre.
Système
- gestion de plusieurs écrans ;
- gestion de plusieurs fenêtres ;
- gestion de fenêtre à forme arbitraire (non rectangulaire) ;
- gestion des boites de dialogues ;
- gestion du dépôt de documents depuis le système (en glisser-déposer) ;
- gestion du presse-papier ;
- gestion de l'énergie (niveau de batterie) ;
- amélioration du traitement multifil ( multithreading ) ;
- API pour opération atomique (programmation sans verrou) ;
- API d'assert.
Vidéo
- API 3D (OpenGL 3 avec différents profils, OpenGL ES) ;
- API 2D accélérée matériellement ;
- gestion des contextes OpenGL ;
- meilleure gestion du plein écran.
Périphérique d'entrée
- gestion de plusieurs périphériques d'entrée ;
- gestion de la connexion à chaud de périphériques (ControllerDeviceEvent)
- gestion du retour de force dans les joysticks ;
- gestion des molettes de souris horizontales ;
- API pour mapper les contrôleurs
- gestion du multipoints.
Son
- gestion des systèmes sonores 7.1 ;
- gestion de plusieurs périphériques audio ;
- gestion de la capture audio ;
- l'API de lecture de CD audio a été retirée.
Recommandé pour les portages Linux
La bibliothèque SDL est, entre autre, maintenue par Sam Lantinga (précédemment chez Loki Software, puis Blizzard Entertainment) qui est aujourd'hui chez Valve Software. Steam, et les portages des jeux Valve utilisent évidement SDL. Le dernier, non le pire (enfin… les goûts et les couleurs) doit être Dota 2.
Dans une récente conférence présentée en polonais mais aux diapos en anglais, Leszek Godlewski (de The Farm 51) recommande d'utiliser SDL et Steam Linux runtime pour porter des jeux vers Linux.
Aller plus loin
- Site officiel (645 clics)
- Liste de jeu utilisant SDL (525 clics)
- SDL 1.2 to 2.0 Migration Guide (277 clics)
# SFML
Posté par MCMic (site web personnel) . Évalué à 10.
Juste un commentaire pour appeler à l'aide pour compléter la dépêche sur la version 2.0 de la SFML, qui est sortie il y a un moment maintenant : http://linuxfr.org/redaction/news/la-bibliotheque-sfml-est-sortie-en-version-2-0
La SFML étant en concurrence avec la SDL ça me paraissait approprié.
[^] # Re: SFML
Posté par Lutin . Évalué à 0.
Ils ne sont pas du tout en concurrence, l'un est un outil pour utiliser plus facilement le second (ou son pote openGL si le cœur nous en dit). La crème chantilly n'est pas en concurrence avec la boule de glace au chocolat.
[^] # Re: SFML
Posté par grim7reaper . Évalué à 5.
Non.
Jusqu’à preuve du contraire, la SFML n‘est pas basée sur la SDL.
[^] # Re: SFML
Posté par Lutin . Évalué à 2.
Ah oui en effet. Au temps pour moi, je croyais vraiment qu'elle s'occupait d'OpenGL ET de SDL.
# Tutoriel d'installation et de création d'un premier projet SDL 2.0
Posté par LittleWhite . Évalué à 8.
Bonjour à tous,
Si vous souhaitez vous lancer rapidement dans cette nouvelle version de la bibliothèque de jeux, vous pouvez découvrir un tutoriel tout en français sur sa compilation, son installation et sa configuration au sein d'un projet : http://alexandre-laurent.developpez.com/tutoriels/sdl-2/installation-et-configuration/
En espérant voir de nouvelles création avec cette bibliothèque :)
# Comment ça se passe du côté de Pygame ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
je n'ai encore jamais utilisé, mais ça m'intéresse quand même: est que pygame supporte SDL 2.0, ou est-ce que c'est en cours ? Sur leur site ils félicitent les auteurs de SDL 2, mais ne précisent pas si le support est en cours d'implémentation (ni si ça va casser les modules tiers).
Je vois aussi qu'il est question d'un pgreloaded (pygame reloaded) qui est apparemment un « pygame 2 », et qui implémente le support de SDL 2.0 (mais avec une API différente, je suppose qu'on peut donc dire adieu aux modules tiers). Qu'en est-il ? Est-ce que c'est à privilégier par rapport à Pygame ?
Bref, si quelqu'un qui suit/utilise tout ça peut en dire plus… Merci :)
[^] # Re: Comment ça se passe du côté de Pygame ?
Posté par MeV . Évalué à 1. Dernière modification le 21 août 2013 à 11:56.
Apparemment, le binding python "officiel" (PySDL2) est le successeur de pgreloaded.
[^] # Re: Comment ça se passe du côté de Pygame ?
Posté par xcomcmdr . Évalué à 1.
Même question du côté Ruby pour libgosu qui est plutôt un concurrent à la SDL, mais qui utilise sdl_ttf.
(quant à Rubygame, ça fait longtemps que c'est mort)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
La plupart des API C++ pour les jeux changent de version majeure: SDL, SFML, clanlib, allegro…
Malheureusement, contrairement aux beaux gosses qui font du Java ou du Python, les développeurs C++ n'ont pas de gestionnaire de dépendances.
Il va falloir des années avant que les distributions stables majeures intègrent ces nouvelles versions, d'où le dilemme du développeur qui commencerait un jeu aujourd'hui:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Spyhawk . Évalué à 5.
Je suis pas développeur, mais je connais un FPS écrit majoritairement en C qui propose au choix (via un fichier cmake) la possibilité au distributeur d'utiliser les "bundle libs" (libs embarquées?) à compiler en statique, ou alors d'utiliser les libs systèmes si elle sont disponibles.
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 4.
La première chose à mon avis et de savoir qu'en est-il de la compatibilité des ABI et des API. Est-ce qu'une appli SDL1.2 tourne avec SDL2 ? La dépêche ne dis rien là dessus en suite il faut voir si cela t'apporte réellement quelque chose de passer à la version supérieur. Obsolète c'est aller un peu vite en besogne, si ça marchait la semaine dernière ça doit encore pas trop mal marcher pendant quelques temps, non ?
Dernier point, il doit être possible d'architecturer ton logiciel pour avoir une couche d'abstraction entre une bibliothèque et le reste de ton application. Ça permet de changer de version de cette dernière à moindre frais. Le faire pour tout est probablement une mauvaise idée, mais pour une bibliothèque qui a tendance à évoluer un peu vite ça peut être intéressant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 7.
Nop. En fait, l'architecture a été complètement revue, le bliting ne se fait plus de la même manière, ainsi que l'usage des inputs. Même SDL_Main a été viré, donc tout programme SDL 1.2 doit être porté.
[^] # Re: le dilemme du dev
Posté par Adrien . Évalué à 2.
D'un point de vue de packageur, je dirais tu prends une config type (Debian stable, la dernière Fedora, etc.), et tu développes avec les version de lib inclut dans ta config type.
Ensuite, c'est aux packageurs des autres distributions de faire évoluer leurs versions.
Le seul soucis étant quand une nouvelle version de bibliothèque casse la compatibilité ascendante. Là il faudra gérer les cas « anciennes version » et « nouvelles versions », jusqu'à ce que la bibliothèque soit intégrée partout. Sinon certaines distributions resterons avec une ancienne version de ton logiciel, jusqu'au passage à la nouvelle bibliothèque.
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est valable pour les distribs linux où la version la plus stable et disponible est la mieux packagée. Pour les autres OS, c'est la dernière release qui compte. Si tu fais un jeu multiplateforme, ça devient vite l'enfer.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Adrien . Évalué à 3.
Je veux bien le croire. Tu peux aussi prendre comme référence la dernière version de la bibliothèque pour tes nouvelles versions. Si tu ne dépends pas de trop de bibliothèque, les distributions packagerons « avec un peu de retard », en prenant la dernière version de ton logiciel compatible avec l'éco-système déjà existant. Par contre ça oblige à maintenir des versions plus anciennes, ce qui est contraignant, mais pas forcément un mal.
[^] # Re: le dilemme du dev
Posté par fabien . Évalué à 5.
Moi perso, je garde mon baril de 1.2 quelques temps encore :
le temps qu'il arrive dans les distro majeurs, et qu'il y ai eut suffisement de retours.
A ce propos je voyais hier je sais plus trop où que celui qui avait implenté le "LogicalSize" voulait peut être revoir sa copie…
bref, je sais que je ne migre pas avant 2 ans ;)
Et d'ici là ils auront encore etoffé le guide de migration qui est déjà excellent.
[^] # Re: le dilemme du dev
Posté par Hobgoblins Master (Mastodon) . Évalué à 8. Dernière modification le 21 août 2013 à 16:02.
Comme beaucoup de « grosses » bibliothèques, il est probable que les distributions proposeront les deux versions en parallèle pendant un certain temps.
D’ailleurs Debian le fait déjà :
Donc pour un nouveau projet, il faut mieux à mon avis partir sur la nouvelle version afin d’éviter de se taper un portage dans deux ans.
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
C'est en unstable…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Hobgoblins Master (Mastodon) . Évalué à 6.
What else?
Plus sérieusement, je pense que pour commencer le dev d’un jeu (ou autre) aujourd’hui, il vaut mieux cibler unstable, de toute façon, si tu veux faire entrer un paquet dans la distribution, il arrivera par là. Je ne connais pas les plans pour une introduction de SDL2 dans backports, mais il y a quelques français dans le groupe de mainteneurs SDL pour Debian dont certains traînent un peu ici de temps en temps, on aura peut-être une réponse.
Après, c’est sûr que sans backport des bibliothèques, il va être difficile de dire à d’éventuels testeurs en stable (ou si ton projet est prêt avant deux ans), installez juste « watever-dev », puis
./configure && make && sudo make install, mais je ne suis pas sûr que la cible majoritaire pour ça ne soit pas déjà en testing au moins. Si le dev veux faire des paquets lui même, le travail supplémentaire pour intégrer les libs nécessaires dans le paquet et tout mettre dans /opt n’est pas forcément monstrueux (et de toute façon, si le jeu est multiplate-forme, ce sera un boulot obligatoire pour celles sans gestionnaire de paquet).Et là, on ne parle que de Debian, qui est l’une des distributions les plus « lentes » (mais je n’avais que ça pour illustrer le fait qu’avec soname et un packaging propre, on peut très bien avoir plusieurs version majeurs d’une lib sur un même système), si tu cibles Fedora, Arch, Ubuntu… qui ont toutes des cycles de 6 mois à un an maximum, il vaut également mieux cibler la dernière version majeure de la bibliothèque…
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Pour l'instant la seule solution sérieuse, c'est peut être d'attendre qu'un des projets de gestionnaire de dépendances pour C++ s'imposent et de faire du python/java/… en attendant.
https://github.com/Offirmo/cvm
https://github.com/bcachet/DMC
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par deronnax . Évalué à 5.
Malheureusement aucun de ce genre de projets n'arrive à décoller.
CVM n'a pas eu de commit depuis 4 mois, DMC depuis 7.
Dans le même genre, encore plus ambitieux, Ryppl, pourtant supporté par des mecs de Boost, semble également au point mort : pas de commit depuis 5 mois, et il ne passe plus grand chose depuis un temps (cf la ML).
Aura-t-on un jour un pip/gem pour C++ ?
[^] # Re: le dilemme du dev
Posté par dave_null (site web personnel) . Évalué à 3.
Comme il faut coder en C++, c'est pas très pratique et ça en démotive plus d'un :)
[^] # Re: le dilemme du dev
Posté par deronnax . Évalué à 1.
CVM est en shell, DMC quant à lui on ne sait pas, le projet n'a visiblement jamais dépassé le simple stade d'idée (pas une ligne de code à part les tests).
Ryppl était codé par des C++ enthusiasts (et la ML continue de recevoir des candidatures de volontaires), mais visiblement, déjà que le C++ ne se prêtait pas au jeu, Boost non plus, qui demandait un redécoupage et une modularisation (et Dieu sait que Boost est complexe) ainsi qu'un changement de système de build (de jam vers cmake), et l'équipe semble avoir baissé les bras devant le volume et la difficulté du travail (et le fait que l'initiateur du projet, Dave Abrahms, eut été recruté par Aplle).
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pourtant ce n'est pas si dur, je l'ai déjà fait d'ailleurs (mais pas en libre) :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par ariasuni . Évalué à 5.
Hérétique!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Non salarié.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 6.
Ah non, pitié, le pire du monde Python/PHP/Ruby en C++ ><
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Un gestionnaire de dépendance, c'est bien, même les langages plus nobles en ont (Haskell, OCaml, perl…).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 8.
Tu veux dire les machins qui font double/triple emploi avec le gestionnaire de paquets de ta distribution et des gestionnaires customs existants (genre pkg-config et compagnie) ?
À moins que tu parle des dépôts publics insécurisés ou tout le monde peut publier des backdoorées et télécharger sans aucune authentification de la somme de contrôle, voire sans somme de contrôle du tout ?
Sérieusement, ça apporte quoi par rapport à des projets éparpillés sur le net, mis à part de la centralisation ?
[^] # Re: le dilemme du dev
Posté par MyLordAngus . Évalué à 2.
Un des avantages que je vois au gestionnaire de paquets des langages de scripts comme Ruby ou Python est qu'il s'intègre très bien avec des outils pour isoler les environnements de programmation. Exemple avec ruby utilisé avec RVM (Ruby Version Manager) qui te permet d'avoir plusieurs versions de Ruby installées en parallèle. Couplé avec Gem (le "gestionnaire de paquets" de Ruby donc), on peut avoir des environnements bien définis entre différents travaux et on peut identifier les gems qui sont requis par un projet pour fonctionner et celles qui ne le sont pas. Une simple ligne de commande à taper ensuite pour changer de versions de ruby et de gems disponibles.
Bien sûr tout cela est faisable à la main, mais il faut être très strict pour bien savoir ce que l'on a installé comme extension, comment la désinstaller proprement et complètement, et garder toujours un environnement de travail qui s'éxecute correctement.
[^] # Re: le dilemme du dev
Posté par Adrien . Évalué à 3.
Quel est l'avantage par rapport à un dépot logiciel type deb ou rpm ?
A part réinventer la roue (en moins bien) je ne vois pas très bien, tout ce que tu raconte, c'est la base de tout gestionnaire de paquets…
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est portable et à jour?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Adrien . Évalué à 5.
Tout à fait.
Par exemple; on pourrait imaginer qu'un projet ait son propre dépot deb. Ainsi c'est à jour, avec un packaging bien fait tu gère tout à fait les différentes versions, c'est très très simple à inclure dans les distribution après.
La question de la portabilité n'a pas de sens : Au lieu de développer un truc genre gem pour toutes les plate-formes, on pourrait imaginer intégrer un truc genre dpkg ou rpm dans le langage en question, à première vue ça ne semble pas beaucoup plus difficile.
Au final je pense que c'est vraiment une quetsion de vision : le gestionnaire de paquet pense toute la chaine de distribution, ce qui peut être contraignant. Les gestionnaires genre gems ne pensent qu'à l'aspect "je balance mon truc vite fait". Evidemment ça va plus vite, mais bon c'est l'arrache totale.
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 1. Dernière modification le 23 août 2013 à 11:30.
J'attends le lancement d'un tel projet après seconde vue avec impatience :-)
Je ne connais pas bien gem, mais avec Maven & co, tu as un gestion des releases (pour bosser proprement) et des snapshots (pour l'arrache).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 5.
On peut imaginer pleins de choses. Mais les deb ça marche sur Debian et dérivé uniquement (et encore modulo quelques incompatibilités) plus RH&Fed avec alien. Là on parle de choses qui sont utilisé sur n'importe quelle distribution linux, sur XP/Vista/Seven/8, sur OS X et sur les BSD évidement. Ça fait une dizaine d'années que rpm est le standard LSB et assez peu de distribution en définitive s'en servent. Bref faut quand même pas mal d'imagination pour imaginer créer un dépôt deb et l'utiliser partout. Même si demain apt deviens utilisable et utilisé sur toutes les plateformes tu aura toujours un tas de problème :
Ça veut dire quoi « intégrer un truc genre dpkg ou rpm dans le langage en question » ? C'est un vrai question.
Je ne les connais pas tous, mais pour CPAN tu a une panoplie de test (exemple avec Mosse). Maven possède une gestion précise des releases assez contraignante mais conçu pour rendre le build aussi reproductible que possible. Je ne doute pas que les autres ont aussi leur critère dans leur coin.
Mais note que c'est nécessaire de pouvoir balancer ton truc vite fait sur ton dépôt à toi, pour pouvoir le partager avec ceux qui veulent développer leur logiciel sur la prochaine version de ta bibliothèque par exemple.
Bref c'est plus qu'une question de vision c'est une question de besoin. dpkg/rpm ne répondent pas à ces besoins entre autre car :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 7.
Quand tu utilise un langage dis portable. Te fader plus de packaging différent qu'il n'existe de système d'exploitation, ça n'a pas de sens.
deb, rpm et autres sont système, ils vont installer des trucs pour l'ensemble des utilisateurs utilisateurs système compris.
Toi tu es sur ta machine, tu veux utiliser la toute dernière version de dev de perl et de Moose, mais ta pas envie de casser ton système pour autant. Aucun gestionnaire de paquet de distribution ne gère ce genre de chose. Ce que tu peut éventuellement faire c'est créer un chroot et te faire toute ton installe.
Il est aussi bien plus pratique d'avoir dans les fichiers projets (ceux qui sont versionnés), la liste des dépendances qui sont ensuite automatiquement résolue de manière indépendante du système d'exploitation. Ça permet à tout les développeurs de travailler rapidement ensemble sans pour autant être forcé d'utiliser le même SE que les autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 7.
C++ n'est rien d'autre qu'une spécification sur le langage. Il n'y a pas d'implémentation de référence ou quoi que ce soit. Il n'y a pas de moyen standard pour compiler et lancer un logiciel. Le langage ne dicte par exemple pas que ton système doit supporter les bibliothèques dynamiques, et tu a des systèmes ou ce n'est pas le cas. Tu à des systèmes ou ton implémentation de la norme C++ est incomplète (pas d'exception, par exemple).
À partir de ce moment là, tu à un gros problème à gérer, rien que pour compiler et lancer un logiciel sans dépendances. Il te faut un système de build bloaté pour supporter plusieurs systèmes, plusieurs compilos (avec des bugs divers et variés) les architectures éxotiques sans virgule flottante matérielle, les bibliothèques standard avec plus ou moins de lacunes (parfois causées simplement par les limitations matérielles), la cross compilation (greuh), et ne parlons pas des options de compilation.
En fait, tu te retrouve avec tout les problèmes qu'ont les systèmes de builds, les distributions et les gestionnaires de paquets avec les logiciels C depuis 20 ans. Et à ce que je sache, personne n'a pour l'instant résolu le problème pour Windows, ou il y a encore plus de segmentation avec les compilos Visual C++ incompatibles entre eux.
Alors oui, quand je dit que ça fait double emploi avec
$PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.La seule vraie solution à ce problème, ça serait une meta distribution générique qui s'intègre avec tout les OS qui existent. Or on sais très bien que ça va poser encore plus de problème que ça va n'en résoudre.
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 1.
Je ne sais pas pour le C++, mais pour le C tu as cc qui est au moins un standard de fait sur les unix-like. Ensuite, rien ne t'empêche d'avoir un gestionnaire de dépendances qui pour chaque bibliothèque donne un certain nombre de prérequis système (architecture, gestion de tel ou tel fonctionnalité du langage, etc) et dans tes fichiers projet tu indique les prérequis de ton système cible. Ensuite c'est une gestion des dépendances tout ce qu'il y a de plus classique. La différence avec apt c'est qu'il peut se charger lui même de mettre tout ça dans un dossier à toi et choisir les directive du compilateur pour les inclures (une énorme partie existe déjà dans CMake).
Mais bon même si ça ne marche pas pour certains langages comme le C et le C++, ce n'est pas pour ça que c'est idiot dans les autres contrairement à ce que tu affirmais.
Non.
Dans ce commentaire tu dis que le C++ s'il en existait un pour du C++ ça ferrait double emplois avec le gestionnaire de paquet. Alors que dans les précédent tu disais que gem c'est de la merde fait pour les bouts de code fait à l'arrache.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 4.
Mais pas sous Windows. Or si il y a bien un OS qui à besoin d'un gestionnaire de dépendance de toute urgence, c'est bien cet OS (quoi que j'en pense). Le reste a déjà des gestionnaire de paquets…
Debian ça n'est pas qu'apt, il y a aussi toute la gestion de la compilation et de la cross compilation des paquets, en plus de l'infrastructure qui permet de compiler tout ça automatiquement.
D'ailleurs, Debian a (avait ?) discuté de la possibilité d'installer des paquets en tant qu'utilisateur. Comme quoi les problématiques ne sont pas aussi éloignées que tu ne le crois.
Dans le précédent aussi.
Je n'ai jamais dit ça. L'autre reproche principal que je faisais concerne la sécurité de certains dépôts de ces systèmes de dépendances, ou les utilisateurs exécutent automatiquement du code uploadable par n'importe qui sans aucune vérification ni cloisonnement.
Même si pour le coup, avec un langage aussi expert-friendly que C++, on va forcement avoir des problème de qualité des codes uploadés.
[^] # Re: le dilemme du dev
Posté par Juke (site web personnel) . Évalué à 6.
Et ça a donné quoi ?
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par Adrien . Évalué à 3.
Tu peux arriver au même résultat avec debian par exemple :
apt-get source superprojet
apt-get build-dep superprojet
cd superprojet
debuild -us -uc
(pas sûr de moi sur les commandes, mais l'idée est là)
En bonus, c'est sécurisé.
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
En malus, il faut que tous les devs soient sur debian et deviennent grand maître du packaging deb…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 1.
En quoi c'est plus sécurisé que les autres ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
En quoi est-ce plus sécurisé qu'un dépôt Maven avec signature PGP & co?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Je ne sais pas pourquoi tu es venu avec Maven dans la discussion. Cet outil n'a rien à voir avec Pip, Gem, et autres rustines mal-pensées.
C'est un peu comme si tu m'opposait Git dans une discussion autour des formats d'archives : ça n'a aucune pertinence.
Maintenant, Maven ne semble pas être un outil de diffusion automatique de vers, je n'ai donc pas d'opinion sur ce gestionnaire de build.
[^] # Re: le dilemme du dev
Posté par barmic . Évalué à 4.
Tu rigole ? C'est lui qui a commencer à parler des gestionnaires de version propre à des langages particulier et il a commencé avec python et java en exemple…
Pip, Gem, cpan et autres sont un sous-ensemble de ce que fait maven. Je crois que maven c'est plutôt gem + bundler + rake.
Mais au final comme on parle de gestion de dépendance du logiciel avec ces bibliothèques propre à un langage et indépendant du système d'exploitation, je ne vois pas en quoi il est pas pertinent (mis à part le fait qu'il ne rentre pas dans ton argumentation).
Faut arrêter les comparaisons c'est systématiquement foireux.
Les autres le sont plus ? Tu as des liens à ce sujet ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Un lien ? On peut trouver ce genre de blagues : https://bugzilla.redhat.com/show_bug.cgi?id=749378
Les comparaisons ne sont foireuses que pour ceux qui ne les comprennent pas.
Maven n'est pas pertinent parce qu'il ne va pas, au petit bonheur la chance, butiner sur des serveurs plus ou moins de confiance pour trouver comment satisfaire ses dépendances. Il faut spécifiquement indiquer à Maven quelles sources consulter pour étancher son désir de dépendance.
Alors qu'avec pip et compagnie, tu te retrouves souvent avec des scripts s'exécutant, provenant de serveurs dont tu n'as jamais entendu parler. Sans compter que ce sont généralement des serveurs où n'importe qui déposer une version d'un composant, sans qu'il n'y ait aucun contrôle. Tout ça parce que le comportement par défaut de PIP, c'est de jeter tout principe de sécurité de base et de se tremper joyeusement dans le premier paquet qui semble correspondre à ses désirs.
Oui, tu peux spécifier que tu ne veux pas installer, que tu ne veux que télécharger : mais ce n'est pas le comportement par défaut. Donc à la moindre erreur, s'il y a un ver qui traîne dans un paquet, tu le choppe à ton tour. Et évidement, il va se loger dans tes propres sources, que tu vas empaqueter dans un pip et uploadé (ou il va le faire tout seul, pour peut que ton trouseau de clés n'est pas protégé par une passphrase).
Pip, c'est comme la base de registre de MS Windows : une bonne idée à la base, une implémentation merdique à l'arrivée.
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Maven n'est pas pertinent parce qu'il est bien fait?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Disons qu'il est moins pire que les autres, parce que ces auteurs pratiquent une politique de sécurité raisonnable. Cependant, le problème des gestionnaires de paquets par dépôt reste ouvert, en ce sens qu'ils ne bénéficient pas des mises à jour de sécurité du système.
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 2.
Si c'était bien fait, il n'aurai pas besoin de télécharger le monde et répliquer le contenu de mon répertoire /usr/share/java déjà bien rempli par Debian.
Ça plus le fait que ça soit du Java quoi…
[^] # Re: le dilemme du dev
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Maven est un système portable. La prise en compte des spécificités de Debian est du ressort de… Debian!
Un système de build et gestion de dépendances pour Java écrit en Java, ça me semble logique. C'est pareil pour les autres: gem est en ruby, pip en python, cabal est en Haskell…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le dilemme du dev
Posté par ariasuni . Évalué à 1.
Pourquoi c'est une blague?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: le dilemme du dev
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Parce que c'est drôle, vicieux, etc.
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 2.
Debian à toute une infrastructure à base de logiciels libres, disponibles (et packagés pour Debian) pour permettre de construire des paquets dans des environnements isolés pour éviter qu'un rigolo te lance une backdoor lors d'un ./configure. Ils ne sont peut-être pas parfaits et entièrement sécurisés, mais c'est déjà bien mieux que certains gestionnaires de dépendances ou c'est totalement open bar. Par contre, ils ne te protégeront pas contre la compilation de code malveillant (ou de code tout simplement pourri).
[^] # Re: le dilemme du dev
Posté par Batchyx . Évalué à 2.
# nimage cassée
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Je ne vois pas le logo SDL dans la dépêche (oui, oui, j'ai bien le certificat de img.linuxfr.org)
Ces deux adresses (cache et originale) répondent toutes les deux par un 404.
http://img.linuxfr.org/img/687474703a2f2f7777772e6c696273646c2e6f72672f696d616765732f53444c5f6c6f676f2e706e67/SDL_logo.png
http://www.libsdl.org/images/SDL_logo.png
J'ai trouvé ces images là :
https://upload.wikimedia.org/wikipedia/fr/2/26/SDL_logo.png
http://www.libsdl.org/media/SDL_logo.png
http://wiki.libsdl.org/wiki_static/SDL_logo20_sm.png
La dernière est peut-être plus appropriée pour l'annonce de version, mais c'est la plus petite.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: nimage cassée
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Xlib,/XCB
Posté par barmic . Évalué à 4.
Il n'est pas prévu d'avoir un équivalent de Xlib/XCB, qui offre une abstraction du serveur d'affichage (au moins entre Xorg et Wayland) ? Voir réimplémenter Xlib ou XCB sur Wayland ? Je sais que chaque bibliothèque graphique va faire cette abstraction, mais ça me paraît dommage de ne pas le faire au niveau en dessous pour ça puisse profiter au plus grand nombre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Xlib,/XCB
Posté par davandg . Évalué à 1.
Justement, SDL est fait pour ça. Il abstrait meme de l'OS utilisé.
Wayland et Mir ont des couches de compatibilités pour que les applis X puissent tourner.
[^] # Re: Xlib,/XCB
Posté par barmic . Évalué à 4.
Qt aussi. Mais c'est du travail que chacun fait dans son coin et maintenu à l’extérieur du projet des serveur graphique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# facilité
Posté par cachou44 . Évalué à 5.
Ça fait plusieurs fois que je le vois utilisé dans ce sens (traduction de facility). Serait-il entré dans le dictionnaire ?
[^] # Re: facilité
Posté par xcomcmdr . Évalué à 0.
Je le vois plus souvent en anglais être utilisé pour ses autres sens. C'est souvent un faux ami.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: facilité
Posté par bayo . Évalué à 1.
En l’occurrence, c'est le mot français que j'ai mis, ce n'est pas une traduction. Mais "service" est peut-être plus convenable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.