En fait, je reviens sur ce que j'ai dit: la gestion par défaut n'est pas satisfaisante, parce que mes collègues sont des windowsiens habitués ni à la ligne de commande ni à git, du coup… bah, créer un dépôt git en ligne de commande relève du parcours du combattant pour eux ( pourtant… "$ssh git@distant mkdir dépôt && cd dépôt && git init --bare" me semble pas compliqué… 'fin bref ) donc je vais sûrement partir à la recherche d'une solution leur permettant de clicouiller pour avoir un dépôt intégré direct dans redmine.
Mais bon, ça attendra au moins que j'aie fini avec les vm ( être dans une boîte qui fait du dev depuis près de 10 ans, et n'a ni versionning, ni environnement de tests, c'est un poil la loose quand même, donc je tente de corriger ça )
La réponse précédente fonctionne, donc je vais me permettre de ne pas suivre ce tuto ( ou alors plus tard quand j'aurai envie de creuser ).
Par contre je vais regarder pour le plug-in, ça m'intéresse, même si la gestion par défaut de redmine de git semble satisfaisante.
Ça marche! Enfin… et dire que c'était si simple -.- m'en vais de ce pas préciser ce détail sur leur wiki officiel, parce que je doute d'être le seul à qui cette info pourrait servir.
Plus qu'a finir de configurer la bête, mais je devrais m'en sortir je pense.
Il y a un paquet redmine pour Debian, mais c'est une ville version…
Et il y a les backports pour avoir une version à jour.
Quant à lire le FM, j'y ai passé plus que quelques paires d'heures, que ce soit à essayer de suivre les divers tutos sur le net, ou même le site officiel. D'ailleurs, avec le site officiel sur comment installer, ça marche nickel. Sauf qu'ils ne parlent pas de l'intégration avec un serveur http, la proc d'install est donc… hum, disons faiblement utile, ou juste utile pour ceux qui sont habitués à installer des appli ruby sur leurs serveurs http. Ce qui n'est pas mon cas.
Un howto… j'avoue, j'ai improvisé et c'est crade, mais ça marche.
En gros:
tu crées un dossier représentant ton futur paquet ( disons "foo" ).
Dedans tu crées un dossier "DEBIAN" ( caps-locké, important ) lui-même contenant un fichier "control" contenant un truc de ce genre:
Package: libgstreamer0.10-0
Version: 0.10.99
Section: libs
Priority: optional
Architecture: all
Description: fake package to avoid pulling all crap around gstreamer ( dbus, systemd, etc ) for nothing
A noter que j'ai fait ça à l'arrache, je devrais ajouter pour calmer apt* la ligne "Maintainer: …" mais cet exemple est un réel exemple de ma machine actuelle.
Une fois que tu as tout ça, tu remontes à la racine ( le dossier contenant "foo" ) et tu tapes: "$dpkg-deb -b foo".
Après, si tu voulais faire un vrai package, il suffirait de recréer l'arborescence dans laquelle tu comptes placer les fichiers du package dans "foo", par exemple: "foo/usr/bin/foo", "foo/etc/foo.config".
Pour chiader le truc, tu peux ajouter des hash md5 des fichiers dans le dossier DEBIAN, des signatures je ne sais plus où, etc etc.
Il y à aussi moyen de créer des scripts lancés à différents moment de l'installation/suppression, en ajoutant les fichiers dans DEBIAN ( même si le man de dpkg précise qu'il n'est pas à destination des mainteneurs, c'est assez éclairant sur ces fonctionnalités de base ).
Rien de bien compliqué en somme, sauf que ton paquet ne passera pas le standard de qualité Debian, donc ne finira pas dans le repo officiel. Mais au moins, les gens ( ou toi pour tes scripts et config ) pourront l'installer.
Malheureusement, l'idée de les avoir mises à côté est plutôt regrettable, parce qu'elle pousse à penser à tort que ça a une importance, alors que pas du tout d'après mon expérience, et a même l'inconvénient de surcharger une main,
Marrant, je crois me souvenir que bépo ( ainsi que dvorak ) cherchaient à mettre les touches les plus utilisées sur la ligne maîtresse ( ou je sais plus comment ils appellent ça, bref, celle avec les guides ).
Bah c'est un peu ce que fait vim avec hjkl: les touches les plus utilisées, celles pour se déplacer, sont situées sur cette ligne.
Par contre, c'est vrai, on ne peux pas se déplacer des deux mains du coup. Mais sinon, ça me semble aussi pertinent que de mettre toutes les lettres les plus utilisées sur la même ligne.
À part bouffer un peu de place sur le disque dur, ça ne pose aucun problème.
C'est sûr, c'est aussi ce que l'on me disais il y a 8 ans en cours au sujet de la RAM, d'ailleurs, au pire l'utilisateur rachète de la RAM. Sauf que, maintenant, il y a des systèmes moins performants, mais tenant sur moins de place physique. Moins de dépendances, moins de code chargé potentiellement, permet de faire tenir plus de logiciels sur, par exemple, une carte SD.
Bon, après, c'est aussi ma manie à moi, je l'assume :) on s'amuse comme on peut, pas vrai?
Je le sais bien, c'est pour ça que j'ai fait des fake packages pour dconf et gstreamer. Genre opera et claws qui dépendent de gstreamer, donc de dconf, donc de dbus, alors que je sais pertinemment que je ne m'en sers pas et que ça marche sans, ça m'embête.
Pour dconf, je ne sais plus c'est quoi, mais pareil, bizarrement, le système marche tout seul sans.
J'avais aussi fait la même chose pour mars shooter ( très bon jeu d'ailleurs, bien amusant ) et sa dépendance hard sur une pléthore de fontes. Après discussion avec le mainteneur, il s'avère qu'il s'agissait d'un choix pour être sûr que l'utilisateur ait les fontes de sa langue.
Par contre, vu de ma fenêtre, l'install graphique idéale grand public, c'est celle qui ne pose pas d'autre question que "je fais ça, ça te va? (si tu ne sais pas, clique sur oui") avec des questions du niveau "Tu habites en France et tu veux un système en Français. Oui ou non?".
En même temps, c'est le cas. Avec Debian, les questions que l'install te pose ont des valeurs par défaut tout à fait acceptables, pour un non bidouilleur ( même si c'est un peu contraire à l'esprit de la communauté au final, puisque j'ai l'impression que les gens sur la ml sont quand même du genre à bricoler leur distro ).
La seul réelle question posée, c'est la langue, et ça, ça risque pas de changer, et pour cause: il n'y à aucun moyen de deviner la langue de l'utilisateur sans réseau, et le réseau est configuré après la langue et le clavier. Et même deviner la langue via le réseau, je crois que Debian n'apprécie pas ( me semble avoir vue la question posée à une époque ) pour des problématiques de sécurité ( accès réseau sans demander? ) et de fiabilité ( qui me dit que je ne dois pas passer par un proxy, qui fausserai potentiellement les données? Et si je suis à l'étranger? ).
Pour moi, Debian fait déjà ce que tu demandes. On pourrait juste regretter que le choix par défaut ne soit pas le mode simpliste ( il en existe un, qui ne pose quasi aucune question ) mais comme je l'ai dis, j'ai l'impression que c'est un peu contraire à l'esprit de la communauté Debian, même si elle est toujours prête à aider même les gens avec le moins de connaissance.
Hum… archives auto-extractible, compilation statique. Un peu comme ce que fait NVidia avec ses pilotes, sauf qu'il est possible de faire moins complexe ( pas de besoin de compilation, après tout ).
Et pour certains langages ( ruby notamment ), tu as même des package manager dédié au langage. Comment ça communique avec le système par contre, aucune idée.
Sinon, je pense qu'un dev qui fait les packages uniquement pour sa distro, sans envoyer chier les contributeurs potentiels qui soumettrons des paquets pour leurs distros, se prend pas la tête et à un truc simple à installer pour les utilisateurs. A fortiori s'il utilise l'une des distros qui servent de base à la plupart, c'est à dire debian ou fedora ( je suppose imaginairement que c'est Debian, mais manquant de chiffres… ).
D'ailleurs, quelqu'un qui connaît ( mieux que moi ce serait pas dur, et me suis jamais penché sur cette option ) Debian saurait probablement automatiser le build à partir des sources, il semblerait que c'est ce qu'ils font dans le repo officiel. Donc, il y aurait moyen de faire un paquet source pour toutes les filles de Debian automatiquement ( cross compilation, VMs, etc. )
Je n'ai pas encore testé, mais ça m'a donné envie: je suis toujours partant pour alléger mon système.
Hors, 2 manip dans aptitude ( debian testing avec quelques paquets stables ( des libs de dev principalement ) ) montrent que ton journal n'est pas mensonger sur la suppression de code. Si je supprime mplayer et toutes ses dépendances, puis que je fais semblant de le remettre, j'ajoute 27 dépendances.
En annulant les actions sur mplayer, et en mettant mpv, seulement 19.
Bon, ok, 8 dépendances d'écart, c'est pas énorme, sauf qu'en fait, rien que le fait d'enlever de mon système les trucs liés à samba, dont je sais pertinemment que je n'en ai pas besoin, ça me mets du baume au cœur. Reste à voir ensuite avec les autres libs que mpv m'amène, à quoi elles servent exactement, peut-être que d'autres outils les utilisant pourraient remplacer d'autres de mes outils actuels.
En vrac, liste non exhaustive de ce qui saute au niveau des dépendances de mplayer ( ça peut donner, ou pas, une idée de ce qui à été enlevé ):
samba ( me suis toujours demandé l'intérêt… ) donc python-talloc, divers trucs kerberos et ldap, ce qui ramène quand même 15 dépendances!!! Pour gérer du samba dans un player vidéo… hum…
gestion du svga ( libsvga1, libx86-1 )
mpeg2
libdca0 ( décodage des flux "DTS Coherent Acoustics" )
libcdparanoia0 ( extraction de pistes de CD audio )
Après, à tester, je ne regarde pas énormément de vidéos, et n'ai pas un super grand besoin de perf pour celles que je regarde, mais bon…
je demande ici si quelqu'un a essayé d'installer une Debian sans interface graphique
C'est ce que je fais toujours.
Par contre, jamais installé ensuite mate, mais aucune raison que ça ne marche pas. Sinon tu dois même avoir un paquet avec un nom du genre: task-mate-desktop. Si c'est le cas, installes-le, ça te ramèneras toutes les dépendances et configureras tout automatiquement.
Personnellement, d'habitude après l'install, je sélectionne les pilotes graphiques et entrée dont je sais avoir besoin, plus le paquet xserver-xorg-core, xinit, i3 et un émulateur de terminal ( lxterminal, mais peu importe ). Après, startx marche nickel, par contre pas de gestionnaire de session ( je trouve de toute façon ces outils inutiles, mais question de point de vue ) donc rien d'automatique au reboot.
Pour ça, il te faut un gestionnaire de session, il en existe plein: gdm, kdm, par exemple. Mais j'imagine que le bureau mate doit t'amener tout ça automatiquement, j'ai juste détaillé un peu pour que tu voies un peu les composants minimaux.
Je regarde un peu, et je vois la mention "parking gratuit" ( pas évident ça au havre, cool de le préciser ) mais ça amène potentiellement la question: et l'entrée? ( bon, j'imagine que ça l'est aussi, mais la précision n'a jamais tué de pigeon… quoique, avec un bon fusil faut voir :p )
Autre point, vous avez déjà toutes les ISOs, ou un cache des paquets pour éviter de pourrir ( bon, certes, malheureusement, je doute qu'il y ait foule, mais… ) les serveurs des distros que vous "attaquez", ou tout simplement pour éviter de pourrir votre connexion?
Sinon, pour une fois qu'il y a un évènement pas trop loin de moi ( même s'il a fallu que je migre en basse normandie pour qu'un truc se monte en haute grrr ) , je vais essayer de venir, jamais vu d'install party, ça tombe bien :)
( et au cas où, j'ai les 8 premières ISO Debian sur un disque dur externe, je sais pas si ça pourrait aider? )
Je pense que l'une des raisons majeures, c'est l'historique.
Plusieurs distros ont fait leur format, parce que celui du voisin ne permettait pas de faire un truc qu'elles voulaient absolument ( non, je n'ai pas d'exemple, dans le monde linux, je suis bien trop jeune. Ceci dit, je suis un programmeur, donc je peux imaginer le truc d'ici. Par exemple, les paquets suggérés pouvaient ne pas exister dans un format, ou la signature numérique du mainteneur, etc ).
Depuis, les formats ont, forcément, vu que c'est libre, récupéré les fonctionnalités des autres qui leurs semblaient intéressantes ( pas nécessairement toutes, par exemple, je suis persuadé qu'un paquet gentoo permets bien plus de souplesse qu'un deb au niveau des dépendances ).
Mais parallèlement, les outils manipulant ces formats ont évolué, eux aussi, les distros se sont bâties sur ces outils complexes ( bah oui, résoudre des dépendances, et trouver des solutions optimales automatiquement, ce n'est pas quelque chose de simple, surtout quand une demande de l'utilisateur casse un autre paquet. Dans ce genre de cas, aptitude par exemple, proposera plusieurs solutions ) et donc migrer vers le format du voisin serait inutilement coûteux et complexe.
Après, même si les paquets binaires sont probablement très semblables en terme de nombre de fonctionnalités, je ne crois pas que ce soit le cas avec les distros source, non plus.
Donc, même si je suis prêt à admettre que c'est un problème, je pense également que le remédier est hyper complexe sinon impossible, l'humain derrière la machine étant un appareil dont il est difficile de prévoir le comportement ou de l'orienter, à plus forte raison quand on prône la liberté.
Et puis, franchement, il faudrait arrêter de dire que c'est compliqué de faire un paquet… dans le cas de Debian ( je ne connais que ça, navré, mais à ce que je peux lire un peu partout ça semble le format le plus pénible? ) par exemple, il suffit de recréer l'arborescence ou l'on souhaite envoyer les fichiers, les y placer, et à la racine de cette arborescence, créer un dossier DEBIAN contenant un fichier control, ou l'on écrit les dépendances, la description, le nom du mainteneur, l'architecture cible, etc.
Une fois tout ça fait, on remonte d'un dossier, et on tape: dpkg-deb -b
C'est pas complet ( pas de hash pour l'intégrité des données, notamment, parce que pour ça, il faut un autre fichier avec les hash de chaque fichier. Je n'ai pas encore regardé comment ça marche, mais ça ne doit pas casser 3 pattes à un canard… ), et ça ne sera jamais intégré tel que dans Debian bien sûr, mais ça marche et c'est bien plus propre que du "./configure && make && sudo make install".
Maintenant, le but du développeur ne devrait pas nécessairement être l'intégration dans une distribution, mais que le logiciel soit utilisable facilement, quitte à lui demander d'ajouter un dépôt s'il veut des MaJ automatiques ( et puisqu'on compare avec la concurrence, je rappelle que la concurrence ne fait que commencer à s'y mettre, aux MaJ auto des softs installés… ) chose qui n'est même pas obligatoire: pas besoin du dépôt complet pour double cliquer sur le .deb ( ou lancer un dpkg -i, mais c'est juste parce que moi, je n'ai pas d'explorateur de fichiers. )
Après, c'est sûr, je ne connais que Debian, et en conséquent, je ne fais les paquets de mes outils que pour Debian. En même temps, les gens qui font des outils pour windows, quand ils acceptent de fournir un installateur, ne le fournissent pas pour Mac OS… et je considère que deux distributions sont des systèmes d'exploitation différents ( même si c'est techniquement inexact ).
Ce qui ne m'empêchera jamais d'accepter un script pour bâtir un rpm, si quelqu'un m'en fournit un.
Dernière phrase qui me permets de rappeler ce principe élémentaire du libre:
Les développeurs sont libres d'améliorer leurs logiciels, mais les utilisateurs sont aussi libres d'y contribuer. Dans les deux cas, les gens ont le choix de faire ou de ne pas faire, mais je trouve malhonnête ce genre de phrases:
En plus, c'est une tache ingrate, je me dis quel si la moitié des créateurs de paquets consacraient ce temps à, par exemple, écrire de la documentation, l'univers du libre ne s'en porterai pas plus mal.
La documentation, c'est plus censé être le boulot des développeurs, d'une part, sauf que ça les ( nous? ) fait chier, profondément. Les intégrateurs, ou packageurs, sont censés utiliser cette doc pour fournir un mécanisme d'installation propre pour un système donné.
Bref.
Et toi, qui affirme relativement fièrement que ça te fait chier de "perdre ton temps" à contribuer, comment peux-tu dire ce que les autres devraient faire, si tu ne mets pas la main à la pâte? Yakafokon? Ou alors peut-être contribues-tu, et dans ce cas, peut-être serait-il plus constructif de nous dire quels problèmes exacts tu as rencontré, parce que je n'ai vu aucun problème concret dans ton journal ( bien que je sais qu'il en existe, ce serait stupide de le nier, mais c'est toujours mieux un argumentaire avec de vrais morceaux d'arguments bien formés dedans )
il faut avoir roulé sa bosse dans plein de distro, avoir compilé/installé plein de soft pour comprendre que le problème n'est pas là.
Hum… je proteste, je n'ai fait qu'utiliser Debian, et je le comprend bien.
Bon, après, je suis un programmeur qui préfère le C++ aux autres, malgré ses défauts en terme de compatibilité: ABI non standardisée, donc une simple différence de version entre 2 compilos peut faire péter un binaire.
Je suis aussi le genre qui vise un système réellement minimum, quitte à faire de faux packages, par exemple pour gstreamer qui est régulièrement en dépendance dure ( "depend" chez Debian ) pour "rien" ( les logiciels fonctionnant parfaitement sans ce truc, j'ai envie de dire qu'il devrait être en "recommended" ) et dconf.
J'imagine que ça m'aide à comprendre qu'effectivement, le problème n'est pas le format de package.
D'ailleurs, si c'était vraiment une importante cause de problème, il existe alien pour installer du rpm sur une Debian, et packagekit qui lui vise, si j'ai bien compris sa description dans aptitude, à fournir justement cette couche d'abstraction qui manque tant selon l'auteur du journal.
Ces solutions n'ont absolument rien changé, j'ai l'impression, installer un rpm sur une Debian est toujours aussi casse-gueule, et même installer un deb d'Ubuntu c'est s'exposer à des emmerdes monstres ( alors qu'en théorie, Ubuntu est basée sur Debian sid ).
ne pas te faire suer à commenter juste pour dire que « ça sert à rien
Ben, c'est au cas ou les lecteurs de l'articles n'aient pas vu le score. Ou au cas ou, seul à moinsser, personne ne pourrait s'apercevoir qu'il à moinssé ;)
Enfin, je suppose.
Ça, oui, ça ne serait pas surprenant: corruption du rendu => fenêtres noires ?
Par contre, je ne suis pas trop sûr de la direction dans laquelle chercher, peut-être un rapport de bug? Je ne suis malheureusement pas un grand expert en matos…
Je suis d'accord sur ce qui est des octets perdus… maintenant, dans la SDL, je doute que tu utilises tous les membres.
Après, pour ce qui est des tailles de sprites, ça se défend dans le sens ou, la SFML n'est pas faite ( comme la SDL 2 j'ai l'impression ) pour gérer des sprite à l'ancienne, mais des textures openGL.
Donc, avoir un personnage qui agrège un sf::sprite n'est pas stupide, idem pour les tailles différentes: ton perso, il mesure 3 unités logiques en hauteur ( pifomètre ) et 1 logique en largeur. Ton sprite, lui, est censé s'adapter à la largeur de ton écran… donc les dimensions seront potentiellement variables, et n'ont ( théoriquement ) aucun impact sur la détection des collisions.
Séparer ça, ça permets de faire un jeu… comment ils disent dans le web déjà? bref, qui s'adapte à la taille des écrans. Ah! Responsive dizaine…
Après, je suis d'accord, on est plus pilotés par cette lib, mais on l'est aussi plus en C++ par le langage qu'en C.
Mais bon, pour finir, quand j'ai essayé d'utiliser SFML ( ancienne stable ), ça sentait trop le prototype pas adaptable sur pleins de choses, donc j'ai pas insisté plus. Par exemple, il était impossible de récupérer les dimensions d'une image que l'on aurait chargée d'un fichier de ressources. Ou alors, j'ai pas trouvé comment faire, ni en lisant la doc, ni en lisant les sources. Mais ça à été corrigé depuis.
[^] # Re: Thin comme serveur RoR et apache2 comme proxy HTTP(S)
Posté par freem . En réponse au message redmine et debian. Évalué à 1.
En fait, je reviens sur ce que j'ai dit: la gestion par défaut n'est pas satisfaisante, parce que mes collègues sont des windowsiens habitués ni à la ligne de commande ni à git, du coup… bah, créer un dépôt git en ligne de commande relève du parcours du combattant pour eux ( pourtant… "$ssh git@distant mkdir dépôt && cd dépôt && git init --bare" me semble pas compliqué… 'fin bref ) donc je vais sûrement partir à la recherche d'une solution leur permettant de clicouiller pour avoir un dépôt intégré direct dans redmine.
Mais bon, ça attendra au moins que j'aie fini avec les vm ( être dans une boîte qui fait du dev depuis près de 10 ans, et n'a ni versionning, ni environnement de tests, c'est un poil la loose quand même, donc je tente de corriger ça )
[^] # Re: Thin comme serveur RoR et apache2 comme proxy HTTP(S)
Posté par freem . En réponse au message redmine et debian. Évalué à 1.
La réponse précédente fonctionne, donc je vais me permettre de ne pas suivre ce tuto ( ou alors plus tard quand j'aurai envie de creuser ).
Par contre je vais regarder pour le plug-in, ça m'intéresse, même si la gestion par défaut de redmine de git semble satisfaisante.
[^] # Re: Assez simple
Posté par freem . En réponse au message redmine et debian. Évalué à 1.
Très bonne piste merci!
Ça marche! Enfin… et dire que c'était si simple -.- m'en vais de ce pas préciser ce détail sur leur wiki officiel, parce que je doute d'être le seul à qui cette info pourrait servir.
Plus qu'a finir de configurer la bête, mais je devrais m'en sortir je pense.
[^] # Re: RTFM
Posté par freem . En réponse au message redmine et debian. Évalué à 1.
Et il y a les backports pour avoir une version à jour.
Quant à lire le FM, j'y ai passé plus que quelques paires d'heures, que ce soit à essayer de suivre les divers tutos sur le net, ou même le site officiel. D'ailleurs, avec le site officiel sur comment installer, ça marche nickel. Sauf qu'ils ne parlent pas de l'intégration avec un serveur http, la proc d'install est donc… hum, disons faiblement utile, ou juste utile pour ceux qui sont habitués à installer des appli ruby sur leurs serveurs http. Ce qui n'est pas mon cas.
[^] # Re: En pratique
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 0.
cmake?
[^] # Re: suppression du code obsolète
Posté par freem . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 2.
Un howto… j'avoue, j'ai improvisé et c'est crade, mais ça marche.
En gros:
tu crées un dossier représentant ton futur paquet ( disons "foo" ).
Dedans tu crées un dossier "DEBIAN" ( caps-locké, important ) lui-même contenant un fichier "control" contenant un truc de ce genre:
A noter que j'ai fait ça à l'arrache, je devrais ajouter pour calmer apt* la ligne "Maintainer: …" mais cet exemple est un réel exemple de ma machine actuelle.
Une fois que tu as tout ça, tu remontes à la racine ( le dossier contenant "foo" ) et tu tapes: "$dpkg-deb -b foo".
Après, si tu voulais faire un vrai package, il suffirait de recréer l'arborescence dans laquelle tu comptes placer les fichiers du package dans "foo", par exemple: "foo/usr/bin/foo", "foo/etc/foo.config".
Pour chiader le truc, tu peux ajouter des hash md5 des fichiers dans le dossier DEBIAN, des signatures je ne sais plus où, etc etc.
Il y à aussi moyen de créer des scripts lancés à différents moment de l'installation/suppression, en ajoutant les fichiers dans DEBIAN ( même si le man de dpkg précise qu'il n'est pas à destination des mainteneurs, c'est assez éclairant sur ces fonctionnalités de base ).
Rien de bien compliqué en somme, sauf que ton paquet ne passera pas le standard de qualité Debian, donc ne finira pas dans le repo officiel. Mais au moins, les gens ( ou toi pour tes scripts et config ) pourront l'installer.
[^] # Re: BÉPO = syndrôme NIH ^ 2
Posté par freem . En réponse au journal Défouloir, pamphlet, troll: Chromium, Bépo et NIH. Évalué à 1.
Marrant, je crois me souvenir que bépo ( ainsi que dvorak ) cherchaient à mettre les touches les plus utilisées sur la ligne maîtresse ( ou je sais plus comment ils appellent ça, bref, celle avec les guides ).
Bah c'est un peu ce que fait vim avec hjkl: les touches les plus utilisées, celles pour se déplacer, sont situées sur cette ligne.
Par contre, c'est vrai, on ne peux pas se déplacer des deux mains du coup. Mais sinon, ça me semble aussi pertinent que de mettre toutes les lettres les plus utilisées sur la même ligne.
[^] # Re: suppression du code obsolète
Posté par freem . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 2.
C'est sûr, c'est aussi ce que l'on me disais il y a 8 ans en cours au sujet de la RAM, d'ailleurs, au pire l'utilisateur rachète de la RAM. Sauf que, maintenant, il y a des systèmes moins performants, mais tenant sur moins de place physique. Moins de dépendances, moins de code chargé potentiellement, permet de faire tenir plus de logiciels sur, par exemple, une carte SD.
Bon, après, c'est aussi ma manie à moi, je l'assume :) on s'amuse comme on peut, pas vrai?
[^] # Re: suppression du code obsolète
Posté par freem . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 1.
Je le sais bien, c'est pour ça que j'ai fait des fake packages pour dconf et gstreamer. Genre opera et claws qui dépendent de gstreamer, donc de dconf, donc de dbus, alors que je sais pertinemment que je ne m'en sers pas et que ça marche sans, ça m'embête.
Pour dconf, je ne sais plus c'est quoi, mais pareil, bizarrement, le système marche tout seul sans.
J'avais aussi fait la même chose pour mars shooter ( très bon jeu d'ailleurs, bien amusant ) et sa dépendance hard sur une pléthore de fontes. Après discussion avec le mainteneur, il s'avère qu'il s'agissait d'un choix pour être sûr que l'utilisateur ait les fontes de sa langue.
[^] # Re: Solution simple et immédiate
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 2.
En même temps, c'est le cas. Avec Debian, les questions que l'install te pose ont des valeurs par défaut tout à fait acceptables, pour un non bidouilleur ( même si c'est un peu contraire à l'esprit de la communauté au final, puisque j'ai l'impression que les gens sur la ml sont quand même du genre à bricoler leur distro ).
La seul réelle question posée, c'est la langue, et ça, ça risque pas de changer, et pour cause: il n'y à aucun moyen de deviner la langue de l'utilisateur sans réseau, et le réseau est configuré après la langue et le clavier. Et même deviner la langue via le réseau, je crois que Debian n'apprécie pas ( me semble avoir vue la question posée à une époque ) pour des problématiques de sécurité ( accès réseau sans demander? ) et de fiabilité ( qui me dit que je ne dois pas passer par un proxy, qui fausserai potentiellement les données? Et si je suis à l'étranger? ).
Pour moi, Debian fait déjà ce que tu demandes. On pourrait juste regretter que le choix par défaut ne soit pas le mode simpliste ( il en existe un, qui ne pose quasi aucune question ) mais comme je l'ai dis, j'ai l'impression que c'est un peu contraire à l'esprit de la communauté Debian, même si elle est toujours prête à aider même les gens avec le moins de connaissance.
[^] # Re: L'histoire
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 1.
Hum… archives auto-extractible, compilation statique. Un peu comme ce que fait NVidia avec ses pilotes, sauf qu'il est possible de faire moins complexe ( pas de besoin de compilation, après tout ).
Et pour certains langages ( ruby notamment ), tu as même des package manager dédié au langage. Comment ça communique avec le système par contre, aucune idée.
Sinon, je pense qu'un dev qui fait les packages uniquement pour sa distro, sans envoyer chier les contributeurs potentiels qui soumettrons des paquets pour leurs distros, se prend pas la tête et à un truc simple à installer pour les utilisateurs. A fortiori s'il utilise l'une des distros qui servent de base à la plupart, c'est à dire debian ou fedora ( je suppose imaginairement que c'est Debian, mais manquant de chiffres… ).
D'ailleurs, quelqu'un qui connaît ( mieux que moi ce serait pas dur, et me suis jamais penché sur cette option ) Debian saurait probablement automatiser le build à partir des sources, il semblerait que c'est ce qu'ils font dans le repo officiel. Donc, il y aurait moyen de faire un paquet source pour toutes les filles de Debian automatiquement ( cross compilation, VMs, etc. )
[^] # Re: Isolant ?
Posté par freem . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 10.
L'isolation, ce n'est pas nécessairement thermique.
# suppression du code obsolète
Posté par freem . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 4.
Je n'ai pas encore testé, mais ça m'a donné envie: je suis toujours partant pour alléger mon système.
Hors, 2 manip dans aptitude ( debian testing avec quelques paquets stables ( des libs de dev principalement ) ) montrent que ton journal n'est pas mensonger sur la suppression de code. Si je supprime mplayer et toutes ses dépendances, puis que je fais semblant de le remettre, j'ajoute 27 dépendances.
En annulant les actions sur mplayer, et en mettant mpv, seulement 19.
Bon, ok, 8 dépendances d'écart, c'est pas énorme, sauf qu'en fait, rien que le fait d'enlever de mon système les trucs liés à samba, dont je sais pertinemment que je n'en ai pas besoin, ça me mets du baume au cœur. Reste à voir ensuite avec les autres libs que mpv m'amène, à quoi elles servent exactement, peut-être que d'autres outils les utilisant pourraient remplacer d'autres de mes outils actuels.
En vrac, liste non exhaustive de ce qui saute au niveau des dépendances de mplayer ( ça peut donner, ou pas, une idée de ce qui à été enlevé ):
Après, à tester, je ne regarde pas énormément de vidéos, et n'ai pas un super grand besoin de perf pour celles que je regarde, mais bon…
[^] # Re: Se documenter
Posté par freem . En réponse au message heartbeat et subnet. Évalué à 1.
Même qu'il paraît que les admin système & réseau, à un moment, ils n'y connaissaient rien.
[^] # Re: J'essaye de me soigner
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 0.
Sauf que soupir n'est pas une onomatopée.
# install minimale puis ajout de composants graphiques
Posté par freem . En réponse au message Question sur MATE. Évalué à 2.
C'est ce que je fais toujours.
Par contre, jamais installé ensuite mate, mais aucune raison que ça ne marche pas. Sinon tu dois même avoir un paquet avec un nom du genre: task-mate-desktop. Si c'est le cas, installes-le, ça te ramèneras toutes les dépendances et configureras tout automatiquement.
Personnellement, d'habitude après l'install, je sélectionne les pilotes graphiques et entrée dont je sais avoir besoin, plus le paquet xserver-xorg-core, xinit, i3 et un émulateur de terminal ( lxterminal, mais peu importe ). Après, startx marche nickel, par contre pas de gestionnaire de session ( je trouve de toute façon ces outils inutiles, mais question de point de vue ) donc rien d'automatique au reboot.
Pour ça, il te faut un gestionnaire de session, il en existe plein: gdm, kdm, par exemple. Mais j'imagine que le bureau mate doit t'amener tout ça automatiquement, j'ai juste détaillé un peu pour que tu voies un peu les composants minimaux.
# prix, matériel et infra
Posté par freem . En réponse à la dépêche Install Party au Havre le 7 juin 2014. Évalué à 1.
Je regarde un peu, et je vois la mention "parking gratuit" ( pas évident ça au havre, cool de le préciser ) mais ça amène potentiellement la question: et l'entrée? ( bon, j'imagine que ça l'est aussi, mais la précision n'a jamais tué de pigeon… quoique, avec un bon fusil faut voir :p )
Autre point, vous avez déjà toutes les ISOs, ou un cache des paquets pour éviter de pourrir ( bon, certes, malheureusement, je doute qu'il y ait foule, mais… ) les serveurs des distros que vous "attaquez", ou tout simplement pour éviter de pourrir votre connexion?
Sinon, pour une fois qu'il y a un évènement pas trop loin de moi ( même s'il a fallu que je migre en basse normandie pour qu'un truc se monte en haute grrr ) , je vais essayer de venir, jamais vu d'install party, ça tombe bien :)
( et au cas où, j'ai les 8 premières ISO Debian sur un disque dur externe, je sais pas si ça pourrait aider? )
[^] # Re: J'essaye de me soigner
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à -2.
Merci pour la leçon de latin, je ne connaissais pas ce mot ( même pas ironique mon remerciement ).
Mais je pense que tu pourrais être tolérant et juste corriger d'un, si je ne me trompe pas: "s/<sic>/sigh/g"
# L'histoire
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 10.
Je pense que l'une des raisons majeures, c'est l'historique.
Plusieurs distros ont fait leur format, parce que celui du voisin ne permettait pas de faire un truc qu'elles voulaient absolument ( non, je n'ai pas d'exemple, dans le monde linux, je suis bien trop jeune. Ceci dit, je suis un programmeur, donc je peux imaginer le truc d'ici. Par exemple, les paquets suggérés pouvaient ne pas exister dans un format, ou la signature numérique du mainteneur, etc ).
Depuis, les formats ont, forcément, vu que c'est libre, récupéré les fonctionnalités des autres qui leurs semblaient intéressantes ( pas nécessairement toutes, par exemple, je suis persuadé qu'un paquet gentoo permets bien plus de souplesse qu'un deb au niveau des dépendances ).
Mais parallèlement, les outils manipulant ces formats ont évolué, eux aussi, les distros se sont bâties sur ces outils complexes ( bah oui, résoudre des dépendances, et trouver des solutions optimales automatiquement, ce n'est pas quelque chose de simple, surtout quand une demande de l'utilisateur casse un autre paquet. Dans ce genre de cas, aptitude par exemple, proposera plusieurs solutions ) et donc migrer vers le format du voisin serait inutilement coûteux et complexe.
Après, même si les paquets binaires sont probablement très semblables en terme de nombre de fonctionnalités, je ne crois pas que ce soit le cas avec les distros source, non plus.
Donc, même si je suis prêt à admettre que c'est un problème, je pense également que le remédier est hyper complexe sinon impossible, l'humain derrière la machine étant un appareil dont il est difficile de prévoir le comportement ou de l'orienter, à plus forte raison quand on prône la liberté.
Et puis, franchement, il faudrait arrêter de dire que c'est compliqué de faire un paquet… dans le cas de Debian ( je ne connais que ça, navré, mais à ce que je peux lire un peu partout ça semble le format le plus pénible? ) par exemple, il suffit de recréer l'arborescence ou l'on souhaite envoyer les fichiers, les y placer, et à la racine de cette arborescence, créer un dossier DEBIAN contenant un fichier control, ou l'on écrit les dépendances, la description, le nom du mainteneur, l'architecture cible, etc.
Une fois tout ça fait, on remonte d'un dossier, et on tape: dpkg-deb -b
C'est pas complet ( pas de hash pour l'intégrité des données, notamment, parce que pour ça, il faut un autre fichier avec les hash de chaque fichier. Je n'ai pas encore regardé comment ça marche, mais ça ne doit pas casser 3 pattes à un canard… ), et ça ne sera jamais intégré tel que dans Debian bien sûr, mais ça marche et c'est bien plus propre que du "./configure && make && sudo make install".
Maintenant, le but du développeur ne devrait pas nécessairement être l'intégration dans une distribution, mais que le logiciel soit utilisable facilement, quitte à lui demander d'ajouter un dépôt s'il veut des MaJ automatiques ( et puisqu'on compare avec la concurrence, je rappelle que la concurrence ne fait que commencer à s'y mettre, aux MaJ auto des softs installés… ) chose qui n'est même pas obligatoire: pas besoin du dépôt complet pour double cliquer sur le .deb ( ou lancer un dpkg -i, mais c'est juste parce que moi, je n'ai pas d'explorateur de fichiers. )
Après, c'est sûr, je ne connais que Debian, et en conséquent, je ne fais les paquets de mes outils que pour Debian. En même temps, les gens qui font des outils pour windows, quand ils acceptent de fournir un installateur, ne le fournissent pas pour Mac OS… et je considère que deux distributions sont des systèmes d'exploitation différents ( même si c'est techniquement inexact ).
Ce qui ne m'empêchera jamais d'accepter un script pour bâtir un rpm, si quelqu'un m'en fournit un.
Dernière phrase qui me permets de rappeler ce principe élémentaire du libre:
Les développeurs sont libres d'améliorer leurs logiciels, mais les utilisateurs sont aussi libres d'y contribuer. Dans les deux cas, les gens ont le choix de faire ou de ne pas faire, mais je trouve malhonnête ce genre de phrases:
La documentation, c'est plus censé être le boulot des développeurs, d'une part, sauf que ça les ( nous? ) fait chier, profondément. Les intégrateurs, ou packageurs, sont censés utiliser cette doc pour fournir un mécanisme d'installation propre pour un système donné.
Bref.
Et toi, qui affirme relativement fièrement que ça te fait chier de "perdre ton temps" à contribuer, comment peux-tu dire ce que les autres devraient faire, si tu ne mets pas la main à la pâte? Yakafokon? Ou alors peut-être contribues-tu, et dans ce cas, peut-être serait-il plus constructif de nous dire quels problèmes exacts tu as rencontré, parce que je n'ai vu aucun problème concret dans ton journal ( bien que je sais qu'il en existe, ce serait stupide de le nier, mais c'est toujours mieux un argumentaire avec de vrais morceaux d'arguments bien formés dedans )
[^] # Re: Le paquet masque le repo
Posté par freem . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 1.
Hum… je proteste, je n'ai fait qu'utiliser Debian, et je le comprend bien.
Bon, après, je suis un programmeur qui préfère le C++ aux autres, malgré ses défauts en terme de compatibilité: ABI non standardisée, donc une simple différence de version entre 2 compilos peut faire péter un binaire.
Je suis aussi le genre qui vise un système réellement minimum, quitte à faire de faux packages, par exemple pour gstreamer qui est régulièrement en dépendance dure ( "depend" chez Debian ) pour "rien" ( les logiciels fonctionnant parfaitement sans ce truc, j'ai envie de dire qu'il devrait être en "recommended" ) et dconf.
J'imagine que ça m'aide à comprendre qu'effectivement, le problème n'est pas le format de package.
D'ailleurs, si c'était vraiment une importante cause de problème, il existe alien pour installer du rpm sur une Debian, et packagekit qui lui vise, si j'ai bien compris sa description dans aptitude, à fournir justement cette couche d'abstraction qui manque tant selon l'auteur du journal.
Ces solutions n'ont absolument rien changé, j'ai l'impression, installer un rpm sur une Debian est toujours aussi casse-gueule, et même installer un deb d'Ubuntu c'est s'exposer à des emmerdes monstres ( alors qu'en théorie, Ubuntu est basée sur Debian sid ).
[^] # Re: rien de spectaculaire
Posté par freem . En réponse au journal Kiabi migre son SI sur Linux pour gagner en performance et indépendance. Évalué à 3.
Ben, c'est au cas ou les lecteurs de l'articles n'aient pas vu le score. Ou au cas ou, seul à moinsser, personne ne pourrait s'apercevoir qu'il à moinssé ;)
Enfin, je suppose.
[^] # Re: "migré" de Sun Solaris vers Linux
Posté par freem . En réponse au journal Kiabi migre son SI sur Linux pour gagner en performance et indépendance. Évalué à 1.
Arf, j'avais dû entendre parler de BSD/OS, et mon cerveau de windowsien ( à cette époque ) à dû croire que c'était pareil pour tous les BSD… :/
[^] # Re: "migré" de Sun Solaris vers Linux
Posté par freem . En réponse au journal Kiabi migre son SI sur Linux pour gagner en performance et indépendance. Évalué à 1.
Je me trompe peut-être, mais il me semble que linux n'est pas certifié posix, alors qu'il me semble que *BSD oui, tout comme Solaris ?
[^] # Re: carte graphique ?
Posté par freem . En réponse au message Debian Sid 64 bits +Kde : fenêtres noires. Évalué à 1. Dernière modification le 04 juin 2014 à 17:44.
Ça, oui, ça ne serait pas surprenant: corruption du rendu => fenêtres noires ?
Par contre, je ne suis pas trop sûr de la direction dans laquelle chercher, peut-être un rapport de bug? Je ne suis malheureusement pas un grand expert en matos…
[^] # Re: Raccourcis claviers
Posté par freem . En réponse à la dépêche Dernières évolutions autour de 0 A.D.. Évalué à 2.
Je suis d'accord sur ce qui est des octets perdus… maintenant, dans la SDL, je doute que tu utilises tous les membres.
Après, pour ce qui est des tailles de sprites, ça se défend dans le sens ou, la SFML n'est pas faite ( comme la SDL 2 j'ai l'impression ) pour gérer des sprite à l'ancienne, mais des textures openGL.
Donc, avoir un personnage qui agrège un sf::sprite n'est pas stupide, idem pour les tailles différentes: ton perso, il mesure 3 unités logiques en hauteur ( pifomètre ) et 1 logique en largeur. Ton sprite, lui, est censé s'adapter à la largeur de ton écran… donc les dimensions seront potentiellement variables, et n'ont ( théoriquement ) aucun impact sur la détection des collisions.
Séparer ça, ça permets de faire un jeu… comment ils disent dans le web déjà? bref, qui s'adapte à la taille des écrans. Ah! Responsive dizaine…
Après, je suis d'accord, on est plus pilotés par cette lib, mais on l'est aussi plus en C++ par le langage qu'en C.
Mais bon, pour finir, quand j'ai essayé d'utiliser SFML ( ancienne stable ), ça sentait trop le prototype pas adaptable sur pleins de choses, donc j'ai pas insisté plus. Par exemple, il était impossible de récupérer les dimensions d'une image que l'on aurait chargée d'un fichier de ressources. Ou alors, j'ai pas trouvé comment faire, ni en lisant la doc, ni en lisant les sources. Mais ça à été corrigé depuis.