freem a écrit 5019 commentaires

Pas besoin d'imaginer, je connaît :D

Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.

Ça n'arrivera pas. Je préfère rester sous un X retardé et non maintenu plutôt que de revenir à un gestionnaire de fenêtre stacking. D'un autre côté, je pense qu'il doit être possible d'implémenter un serveur wayland minimaliste donnant la main à un WM externe, pourquoi pas via un mécanisme de plug-in.

Sincèrement, je vois d'un bon œil l'idée de Wayland ( je suis de ceux qui pensent que se débarrasser d'un truc implémentant des choses qui ne sont plus utilisées est une bonne chose, quitte à casser la compat. Reste à définir "plus utilisées" ), et j'aurai bien aimé jouer avec, mais je n'ai pas trouvé de code pour booter mon cerveau dessus. Weston est trop complet ( en même temps, c'est une démo technique ) alors que ce qu'il me faudrait ce serait un serveur minimal. J'avoue ne pas avoir cherché des masses aussi, mais… si quelqu'un connaît un projet dans ce style en cours de dev, je serai curieux de tenter de voir à quoi ça ressemble, et pourquoi pas de coder pour.

Je pense que tu te prends beaucoup trop la tête sur la « propreté » d'un code :-) Tu n'en mourras pas, de publier des trucs « pas propres ». Au contraire, je pense que ça t'apprendra d'autant plus, car c'est en essayant et en se plantant qu'on apprend à s'améliorer.

Accessoirement, un code qui nous paraît propre à un moment donné nous semble parfois à vomir 6 mois plus tard :)

À l'époque de SVN, les développeurs faisaient ce travail à la main, avec 3 sous dossiers principaux ( dans les projets que j'ai pu voir en fouillant sans contribuer ):

• trunk
• branch
• tag

Chacun de ces dossiers contenait un copier/coller des sources.

Cette façon de travailler à été automatisée—et nettoyée—par git ( et par mercurial j'imagine? ): maintenant, trunk est une branche comme les autres, et l'on tague les commit.

La problématique que tu décris permets d'utiliser ça assez facilement, et d'ailleurs pas mal de projets libres utilisent cette méthodo:

• master, ou stable, pour les bug fixes ( une fois la première stable atteinte, naturellement )
• experimental, ou devel, peu importe le nom, pour la future version stable
• une branche par fonctionnalité ou tâche à effectuer, que l'on merge dans experimental quand ça semble marcher.

Puis les tags sont apposés sur des commits précis d'une branche pour définir l'état de la branche au moment de ce commit: numéro de version, release candidate, etc.

Et deux choses sont fondamentalement différentes entre X et Wayland.

Tu as oublié la transparence réseau, qui, si j'ai bien compris, permets de faire tourner une application d'une machine en déportant ses entrées/sorties sur une autre.
C'était plus intéressant à l'époque ou les machines coûtaient la peau du cul j'imagine, mais ça reste à mon avis une raison de ne jamais qualifier X de pourri, ou merdique. Obsolète, éventuellement, mais ce n'est pas pareil: je connais une société qui fait des logiciels pourris et merdiques modernes et les vends à énormément de gens, qui régulièrement leur préfèrent les versions obsolète de la même société ^{^}

X, qu'on le veuille ou non, c'est du rendu d'application déporté. Les clients envoient leurs requêtes de dessin […] ont arrêté de faire ça car c'était trop lent,

Du coup, petite question: pourquoi est-ce trop lent? Que l'image soit créée par une application qui fait le travail "directement" (en envoyant à OpenGL en fait?) ou que les requêtes soient envoyées à une application spécialisée qui fasse le rendu ne devrait pas avoir une énorme surcharge, dans l'absolu?

Est-ce à cause du fait que la plupart des ressources graphiques soient matricielles? Si on utilisait majoritairement du vectoriel, ce problème se résorberait-il? Parce qu'au final, le fonctionnement que tu décris me semble particulièrement adapté à du rendu vectoriel, même si l'on garde une légère surcharge ( le serveur faisant le rendu, probablement via OpenGL, on garde un intermédiaire ) je doute que la différence de vitesse soit flagrante, surtout de nos jours. Par contre, oui, sur du matriciel, envoyer 4*1024*768 ( soit 3 Mio, tout rond en plus! ) pour dessiner un écran entier de faible résolution, ça doit bouffer, surtout s'il n'est pas possible d'utiliser une compression sans perte efficace ( genre des photos ).

C'est un fait, je n'ai pas cherché particulièrement loin ( bookmark, quoi ). J'ai vu une MaJ de mes RSS, suivi 2 liens exactement, et je me suis dit que, peut-être, linuxfr serait intéressé. Mea culpa si je me suis trompé?

Ben non, il se rappelle qu'on le lui a demandé, donc il a dû choisir ça.

3- par expérience, sauf besoin spécifiques, il faut se passer un maximum des types uintXX_t.

Je serais intéressé de savoir quels problèmes tu as eu avec ces types? Mis à part qu'ils peuvent ne pas être définis sur une archi ( contrairement aux types least et fast ), je ne vois pas de problème particulier?

En fait, j'ai l'impression que c'est même le contraire, dans un code:

• écrit par des gens ne connaissant pas stdint et donc les macros maxi/mini pour les int/char/short/long : on ne m'a jamais parlé de stdint.h à l'école, c'était pourtant en 2006, ça existait… à la place de ça, les profs nous disaient qu'un int c'est toujours 32 bits, la même taille qu'un long ( Chance pour moi: j'avais appris en autodidacte sur du C 16bits, avec un compilo différent, et un peu pratiqué du 32bits avec ce même compilo, du coups j'ai tilté qu'il est plus sûr d'utiliser short et long plutôt qu'int, moins de variations sur les plate-formes que je connaissait à l'époque ). Et là, je parle d'un étudiant. Un vieux roublard des intel x86 aura lui, potentiellement acquis des habitudes pas clean, et aurait pu utiliser les mêmes trucs crades de comparer à des constantes numériques faites main. Par exemple, je ne serais pas surpris de voir ce type de choses dans le moteur de certains vieux quake ou de duke nukem.
• écrit avant 1999: stdint.h, c'est le standard C99
• écrit pour être compatible avec du C++ pré 2011: stdint.h n'est standard que depuis C++11

voir des constantes numériques faites main pour tester la valeur maxi lors d'une itération n'est pas rare. Et bien sûr, la portabilité prend un sacré coup dans la gueule ( voire même la stabilité s'il s'est planté, mais bon… ). Alors que des types XintYY_t, quitte à ce qu'ils soient redéfinis ( comme le fait la SDL 1.2, par exemple ) peuvent être comparés au premier coup d'œil à la valeur testée: 0xFFFF et 0x7FFF pour les signés, -1 pour les non signés ( ça au moins ça marche toujours… je crois? ).

Ce que je veux dire, c'est qu'au moins, avec un uint16_t les valeurs mini/maxi/maxi non signé numériques sont fiables ( même si je suis d'accord qu'il faut éviter, mais les codes sources n'ont pas tous la possibilité d'être compilé avec des compilos respectant C99 ( 15 ans c'est jeune comparé au langage C ).

Une dernière petite question: est-ce-que travailler avec des uint*_t en mémoire plutôt que les classiques int, long est moins performant ?

Oui et non. Déjà, parce que performance, ça veut rien dire: performance en calcul, ou en place?
Aussi parce que sur les plates-formes ou uint32_t ( par exemple ) est un define du int, non, par exemple, mais ça peut varier.

Si la performance à ce niveau t'intéresse tant, je te conseille une petite lecture du fichier stdint.h. Plus précisément:

/* Small types.  */

/* Signed.  */
typedef signed char   int_least8_t;
typedef short int   int_least16_t;
typedef int     int_least32_t;
#if __WORDSIZE == 64
typedef long int    int_least64_t;
#else
__extension__
typedef long long int   int_least64_t;
#endif

/* Unsigned.  */
typedef unsigned char   uint_least8_t;
typedef unsigned short int  uint_least16_t;
typedef unsigned int    uint_least32_t;
#if __WORDSIZE == 64
typedef unsigned long int uint_least64_t;
#else
__extension__
typedef unsigned long long int  uint_least64_t;
#endif

/* Fast types.  */

/* Signed.  */
typedef signed char   int_fast8_t;
#if __WORDSIZE == 64
typedef long int    int_fast16_t;
typedef long int    int_fast32_t;
typedef long int    int_fast64_t;
#else
typedef int     int_fast16_t;
typedef int     int_fast32_t;
__extension__
typedef long long int   int_fast64_t;
#endif

/* Unsigned.  */
typedef unsigned char   uint_fast8_t;
#if __WORDSIZE == 64
typedef unsigned long int uint_fast16_t;
typedef unsigned long int uint_fast32_t;
typedef unsigned long int uint_fast64_t;
#else
typedef unsigned int    uint_fast16_t;
typedef unsigned int    uint_fast32_t;
__extension__
typedef unsigned long long int  uint_fast64_t;
#endif

Donc, voila: en fonction de tes besoins, tu as des types différents.

Sinon, j'ai noté l'utilisation d'un char, au milieu de types stdint, pourquoi ne pas avoir utilisé uint8_t? Ça me semblerait plus cohérent.

Enfin, si tu ne veux pas utiliser packed mais que tu veux contrôler l'alignement, il existe de mémoire une syntaxe pour les bitfields en C. Je ne m'en souviens plus, c'est pas le genre de trucs que j'utilise souvent, mais c'est simple à retrouver.

Bon, je mentionne surtout ça parce que tu risques d'y être confronté, et que c'est parfois intéressant si tu sais que tel variable est plus petite qu'un octet et que tu cherches une performance de taille maximale sans avoir à compresser par algo. Dans ton usage précis par contre, je ne pense pas que ce soit une solution acceptable.

Je dirais que c'est toujours mieux d'avoir de l'intégration continue, même si tous les tests ne passent pas immédiatement. Ça donne une piste pour les corriger, au moins.

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.

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.

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.

cmake?

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?

Faire attention aux dépendances

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. )

pour faire isolation thermique ?

L'isolation, ce n'est pas nécessairement thermique.

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…

Tu sais l'administration système réseau c'est un métier.

Même qu'il paraît que les admin système & réseau, à un moment, ils n'y connaissaient rien.

Sauf que soupir n'est pas une onomatopée.