Merci pour le petit résumé, il est intéressant de lire quelqu'un qui est des 2 côtés de la "barrière".
Ceci étant dit, j'ai, comme j'imagine une frange non négligeable de la population qui visite linuxfr, déjà contribué à certains projets, ou au moins essayé.
Du peu de contributions que j'ai tentées, j'ai discerné, peut-être à tord, plusieurs axes qui vont influencer le comportement en réponse de la contribution:
si le projet est un outil, ou un "produit" final.
le nombre de personnes occupées (temps plein ou partiel, professionnellement ou par loisir, je parle ici des contributeurs qui ont intégré, d'une façon ou d'une autre le cœur du projet) par la maintenance du projet, ou la taille de la communauté.
l'âge du projet.
la vitalité du projet.
Je n'ai qu'une ou deux anecdotes sur des projets de type outils, uniquement des bibliothèques C ou C++ (la réaction des développeur change-t-elle en fonction du langage? Je n'en sais rien.). En général, j'ai eu l'impression, si le développement était encore actif, d'une certaine bienveillance.
J'ai corrigé 2-3 bugs (one-liners, souvent) et erreurs ou imprécisions de doc ici et là.
Dans le cas (oui, LE) ou j'ai corrigé une imprécision de la doc, j'en ai profité pour soumettre une demande de fonctionnalité (sur GLFW3, une histoire de presse-papier, j'avais surtout testé pour le fun, mais la doc était imprécise et le comportement faisait que si l'utilisateur (un dev, donc) considérait une erreur comme une raison de crash (comme moi, encore, même si parfois le contexte fait qu'il faut tenter de récupérer un état stable). Du coup, j'ai suggéré plusieurs choses: donner un moyen de vérifier que le presse-papier contiens effectivement des données avant de les récupérer, ou… je ne me souviens plus.
Les devs ont opté (ce que j'aurai aussi fait, et donc ai mis en valeur dans ma suggestion) pour améliorer la précision de la doc et introduire une fonction pour vérifier que le presse papier contiens quelque chose dans une version future. On verra dans le futur si la fonctionnalité est implémentée… Ça ne me tenais pas vraiment à cœur, sinon j'aurai sûrement soumis un patch, je voulais juste jouer un peu avec le code quand je suis tombé sur le comportement surprenant en question.
Sur des "produits finaux", en revanche, j'ai un peu plus à dire. j'ai tenté bien plus souvent d'aider, et les retours sont assez divers.
Parfois, on à l'impression d'être ignoré, purement et simplement.
J'ai en mémoire un vent sur Debian, ou j'ai signalé un bug de udev qui partait en boucle infinie, qui menait à une augmentation des processus udev, et donc une saturation de la RAM, ce qui mène à un état ou Linux ne répond juste plus. Au temps pour le fameux "dans l'open source on corrige en 2s les bugs signalés". Au final, il n'était pas tombé dans l'oubli, j'ai eu un retour sur mon mail plus d'un an après avoir soumis le bug.
J'avoue, mon comportement n'a pas été modèle sur ce coup: au bout d'un an, j'ai encore une image disque avec les données qui reproduisent le bug, mais je n'ai même pas daigné répondre. J'ai mal pris le fait de ne même pas avoir le moindre retour en 12 mois. J'ose espérer que c'est humain. D'autant que, pendant ces 12 mois, Jessie est parue ( est-ce la raison pour laquelle je n'ai pas eu de retours avant? ) et les changements de Debian autant que mon évolution personnelle font qu'il ne me manque pas grand chose pour changer de distrib. Cette histoire à aussi dû contribuer à cette volonté, malgré que j'éprouve réellement un grand respect pour Debian.
Dans d'autres cas le mainteneur est en désaccord avec le ticket, mais répond rapidement et poliment. Là, c'est agréable. Ça m'est arrivé, encore une fois sur Debian, par rapport à un jeu (mars shooter, plutôt fun, je vous le conseille) qui à une dépendance dure sur … des polices de caractères. Son argument était valide par rapport au projet, au final, donc je n'ai pas insisté (mais c'est probablement une des raisons qui font que je cesserai d'utiliser Debian quand j'aurai le courage d'aller sur une distro plus pointue).
Il y à aussi le cas ou l'on cherche à s'impliquer, et ou l'on s'aperçois sur une session IRC laissée en suspend qu'en fait les gens préfèrent vous ignorer plutôt que de répondre. Même pas ils diraient qu'on va trop loin, non non, il préfère laisser les contributeurs potentiels rédiger des messages propres et essayer de patcher le code, sans leur dire qu'en fait, ils en ont rien à carrer. Je ne citerai pas le projet en question, mais vous comprendrez que j'ai juste arrêté de donner des nouvelles, du jour au lendemain. Aujourd'hui, il est encore vivant, tant mieux, il à évolué, tant mieux encore, mais j'ai constaté pas mal de régressions dans les fonctionnalités, et ça me fait autant sourire que mal (parce que si je voulais m'y impliquer c'est que je l'aime).
Il y à aussi les projets, genre valyria tear (un jrpg, des plus prometteurs à mon avis), ou il y a peu de gens, qui sont heureux de recevoir les contributions, et vont jusqu'a recontacter les gens (un nettoyage des allocations mémoire C dans un code C++, je soupçonnais un memory leak de là mais ça n'a rien résolu… le problème viendrai peut-être de la lib pour lua du coup… Tant pis, le code semble avoir quand même été intégré vu que j'ai refondu pour respecter mieux le style de code qui semblait être le final, il faudrait que j'aille remercier).
Enfin, il y à toutes sortes de projets, et ce ne sont pas mes expériences négatives avec certains qui m'empêcheront de tenter de contribuer à de nouveaux projets, que ce soit par le code ou par les tickets. Je reste par contre un véritable contributeur de passage, les rares fois ou j'ai tenté de m'impliquer à fond dans un projet m'ont tellement refroidi que je n'ai plus l'intention de m'intégrer dans une équipe (sauf boulot, mais c'est différent). Tant qu'a faire, je préfère encore forker ou réécrire, si j'ai trop de trucs à changer. Et le signaler au projet original, qui est du coup libre d'intégrer ou non les patchs.
Oui, ça augmente potentiellement la fragmentation, mais entre nous: je m'en fiche. Je mets toujours un lien vers le projet originel, je l'averti aussi toujours en face, et s'il intègre assez de modifs, je vire mon fork.
Au final, moi, je suis plus serein parce que je n'ai pas à me prendre la tête à convaincre par des mots qui ne serons même pas lus (et personne pour répondre franchement: "TL;DR" ou "rien à foutre de ton idée") et j'ai un soft qui marche comme je le veux. Et le projet originel est libre d'intégrer mes idées si ça lui chante et si ça fonctionne. Gagnant-gagnant pour moi.
J'avais besoin de tutoriels qui permettent d'avoir rapidement quelque chose à l'écran, pas nécessairement complexe, et des bouts de code qui compilent sur ma plateforme, qui est une Debian, et sans avoir besoin de galérer avec un IDE (je me contente de git, vim, cmake et cgdb personnellement).
Je programme habituellement en C++, mais je lis le C sans grand problèmes (ils ne sont pas "frères" pour rien).
Autrement dis, je ne cherchais pas des tutoriels pour apprendre à programmer, juste pour gérer les bases de l'OpenGL et les shaders, de façon portable (histoire d'avoir un minimum de rendu pour mon projet, en somme).
Si tu as le même type de besoins, j'ai trouvé ces liens la, par ordre de préférence (et de complétion de lecture, je n'ai pas tout lu)
Le 1er utilise GLFW pour gérer la fenêtre (OpenGL ne fait que dessiner un "tas de pixels", ça ne gère ni les fenêtres ni les entrées), le source est en C et relativement clair, même si parfois les étapes entre 2 tutoriels sont un peu larges.
Le fait d'être basé sur GLFW contribue certainement à rendre le code moins pénible à modifier, à mon avis, mais d'un autre côté tu trouveras moins de bouts de code pour GLFW, surtout que la version 3 est sortie relativement récemment.
Comme j'ai personnellement une préférence pour les bibliothèques qui ne font qu'une seule chose et la font bien, le fait d'être basé sur GLFW3 est un gros avantage. Cette bibliothèque à une documentation extrêmement claire, et ne fait vraiment QUE contrôler une fenêtre. Pas de gestion du son, du réseau ni du dessin proprement dit.
L'API publique de GLFW3 est en C, donc c'est utilisable en C, même si j'ai personnellement écrit quelques wrappers histoire d'en faire moins (l'avantage de la RAII en somme).
Le 2nd utilise se base sur GLUT au lieu de GLFW, qui est une bibliothèque qui se base sur un système de callbacks.
Au niveau du code OpenGL proprement dit, je le trouve plus clair, et avec des étapes plus courtes, que le 1er. Il n'arrive en 2nde position pour 2 raisons: je ne l'ai trouvé que récemment, et n'ai donc pas lu autant que pour les autres, et il se base sur GLUT.
GLUT est une bibliothèque très prisée dans le monde de l'OpenGL, mais je t'avoues avoir un peu de mal avec les systèmes à base de callbacks. Ça ne fait pas un très bon mélange avec les objets du C++… et niveau lisibilité je trouve ça assez moche.
Le 3ème, c'est du C++ pur et dur, avec Visual Studio. Il se base sur l'API de windows.
J'ai trouvé le code et les explications globalement plus clairs que pour le 1er, parfois je lisais les 2 côte à côte.
Il est 3ème, parce qu'utilisant l'API windows et Visual Studio, il ne se conforme pas du tout à mon objectif de portabilité.
Enfin, le dernier, sur wikibooks souffre d'un problème récurrent chez les documents de wikibooks (que j'ai lus, du moins): il dégage une forte impression de "Work In Progress", qui ne donne pas confiance.
Je m'en sers quand même quand j'ai besoin d'un bout de code ou d'une explication rapide pour un problème simple.
_"La mise à niveau a échoué.La mise à niveau a besoin de 2568 Mo d'espace disponible sur le disque "/". Veuillez libérer un espace supplémentaire de 961 Mo sur le disque "/".
Vider la corbeille et supprimer les paquets logiciels temporaires à l'aide de l'application système > administration > nettoyage système, ou en tapant la commande suivante Sudo apt-get clean."
Côté graphique pour vérifier ou est l'espace trop occupé, il existe baobab (du moins, existait, je ne sais pas si ça existe encore) sous gnome.
Si le système est dans un état ou l'on ne peux plus démarrer graphiquement (ça m'est déjà arrivé quand la racine était vraiment blindée de chez blindée), df -h --max-depth=1 / te permettra de vérifier qui prend toute la place sur la racine ( le fameux "disque /" ) en ligne de commande. À noter qu'il y à aussi du -h mais celui-ci ne fait qu'indiquer pour les partitions montées l'espace disque utilisé (mais il est nettement plus rapide, pas besoin de calculer).
J'ai tenté des manipulations dans le terminal qui ont abouti à une régression de la version, (alors là, j'avoue que c'est fort ! ) c'est à dire que le système est maintenant passé à la version 12.04.5 LTS ?!!!
Mon opinion: éviter de suivre sans les comprendre des recommandations de lignes de commandes trouvées sur le net.
Plusieurs raisons:
le net contiens des informations ancienne, parfois TRÈS anciennes. Par exemple, comment revenir à… un Ubuntu de 2012 (si le message date de 2013, ce n'est pas surprenant, pas vrai?).
la commande en question n'est pas nécessairement adaptée au problème du lecteur
la commande en question peut présenter des risques de sécurité (par sécurité, je n'entend pas que le piratage, mais aussi tout ce qui concerne la stabilité du système) sans que l'auteur ne le sache.
Maintenant, si tu nous disais quelles manipulations tu as effectuées, il est sûrement possible de remettre le système à jour sans réinstaller, mais ça sera sûrement plus long qu'une réinstallation sur disque vide. Rien que le fait que les explications devrons se faire attendre sur un forum rendra ça plus long, mais au moins ça pourrais te permettre de comprendre pourquoi tu en es arrivé là.
Si tu trouves que c'est difficile, figures-toi que ça m'est arrivé à plusieurs reprises sur ma Debian. Au final, c'est plutôt très simple, en fait.
Pour le fait de le faire sans en faire exprès, c'est assez facile aussi, surtout dans le cas de l'OP: si la mise à jour à raté, rien de surprenant à ce que le système revienne dans un état stable, autrement dit, la version d'avant la mise à jour.
Perso j'utilise la méthode avec la commande console dd
Qui n'est pas disponible sur tous les systèmes. Typiquement, Windows n'a pas cette commande, il me semble.
Une solution qui me parait plus simple pour quelqu'un qui débute peut-être (ne pas penser à utiliser une clé usb peut indiquer ce cas de figure) est d'utiliser un logiciel graphique tel que liliusb.
Et ça évite de lire le FM, ce qui n'est pas toujours une mauvaise chose.
Le « pas vraiment » me gêne : pourquoi ? Ce n'est pas parce qu'on n'a pas poussé cette solution pour l'audio sous linux que « ce n'est pas comme ça qu'on doit faire sous linux ».
Je ne faisais que parler de l'état des choses, pas de l'idéal. Je ne suis ni dev kernel, ni dev temps-réel (l'audio c'est du temps réel pour moi), donc je ne sais pas pourquoi c'est ainsi.
Il semblerait que OSS mettait un fichier /dev/dsp, que l'on pourrait accéder via les appels système open/close/read/write (qui sont les appels systèmes pour ouvrir/fermer/lire/écrire des fichiers, sur un système POSIX).
Du coup, la question est plutôt, pourquoi avoir arrêté d'utiliser un fichier accessible simplement pour gérer le son?
Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur (et en terme de programmation, je n'ai utilisé ni l'un ni l'autre. Et le jour ou je devrais, je passerai par une bibliothèque, comme tout le monde).
Sinon, tu peux jouer du son en ligne de commande, il te suffit de passer tes données directement à aplay. Mais si les applications faisaient ça, je pense que nos CPUs n'aimeraient pas trop… pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte… pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants.
Note: vu qu'on peut accéder à OSS par un fichier dans /dev, je me demande si y'a moyen de jouer avec les socket BSD par la aussi…
Je parlais de les oublier le temps qu'il est hors du taf… j'ai parlé de dev, j'aurai pu parler de n'importe quel professionnel de l'informatique en fait. De même, "oublier la moitié[…]" est une façon de parler, s'il les oubliais vraiment il ne pourrais pas les retrouver en franchissant le seuil de sa boîte.
Posté par freem .
En réponse à la dépêche Caranille 1.0 RC 1.
Évalué à 4.
Dernière modification le 22 octobre 2015 à 23:17.
TL;DR:
fais moi donc un programme qui envoie "hello world" à un autre programme, en C ou en C++, qui compile sur n'importe quel système supporté par PHP, et sans utiliser de bibliothèque externe.
Version complète:
mais le fait que le php oblige de faire des requêtes http
Si je ne m'abuse, le PHP était à l'origine une simple bibliothèque de fonctions pour le langage C, c'est d'ailleurs la raison qui fait qu'une bonne partie de la libC est accessible. Je me souviens avoir corrigé un problème de "magic values" (cf plus bas, en l'occurrence il s'agissait des param de connexion à des SGBDR) au taf en collant ces données dans un fichier externe, lu avec un bon vieux fscanf des familles (et sans me gêner quant à utiliser la capacité de scanf à utiliser les regex… c'était toujours plus maintenable que l'existant de toute façon).
Donc je serais assez surpris que PHP ne permette pas d'établir de connexion réseau… Quoiqu'en fait non, parce si on se contente du langage et de sa bibliothèque standard, ni le C, ni le C++ ne peuvent actuellement le faire. Ils ne sont même pas capables, en standard, de faire une requête HTTP…
Autrement dit, malgré que je trouve le PHP absolument crade (mais je n'ai peut-être jamais vu de bon code PHP, ceci expliquerais cela) il est manifeste que le PHP est plus puissant en terme réseau que le C ou le C++, si on se base sur le standard brut.
Qu'entends tu par "magic values"?
Valeurs codées en dur dans le code. Genre, coller la taille d'une zone mémoire à 0x1FFFF, en ne permettant pas de le changer à partir d'une option de compilation et/ou de configuration.
et le code C/C++ bien écrit permet d'avoir des performances similaire à l'assembleur.
Je le sais, mais c'est loin d'être trivial. Je suis dev C++ aussi, mais j'ai vu tellement de logiciels codés en C ou C++ comme des gorets que je me suis fait une raison: ce n'est pas le langage qui importe.
Coté achat de matos: Loi de Wirth, je préfère gagner 100x en logiciel en optimisant pendant 1h que gagner 2x en payant 1500€. Faut aussi savoir analyser le besoin hardware.
Moi aussi. Mais celui qui nous paye, c'est rarement l'utilisateur, et loi de wirth ou pas, il faut bien manger :)
Accessoirement, actuellement il me semble que la majorité des décisionnaires soient peu enclins à miser sur l'avenir, préférant les profits immédiats. J'aimerai avoir la preuve par le vécu que je me trompe.
Parfois ils vont préférer cracher quelques centaines d'€ de moins pendant le dev, pour payer plusieurs milliers d'€ de plus pendant des années, parce que de toute façon, eux auront migré ailleurs. Je ne parle même pas des problèmes de maintenance qu'une base de code dégueulasse va poser à l'avenir lorsqu'un pauvre hère devra corriger un bug ou ajouter une fonctionnalité sans avoir eu la moindre explication parce que de toute façon les dev histo sont plus la.
Ce qui deviens, encore une fois, des € dépensés en plus, mais on s'en fout, parce que le décisionnaire d'origine n'est plus là.
Sous GNU/Linux et UNIX en général tout est fichier non ?
Pas vraiment, non. Si tu veux un système qui aie vraiment poussé cette idée, il faut plutôt aller voir du côté de plan9, c'est du moins ce que l'on m'a dis.
De toute façon, GNU/Linux n'est pas UNIX qui est un OS à part, ni même POSIX, qui est une norme inspirée d'UNIX. Cf ce lien que m'a fourni wikipedia et que, je l'admets, je n'ai pas envie d'aller lire :) (du coup on peut me répondre que vu l'âge du document, il est caduc).
Je crois avoir le souvenir de quelqu'un ici répondre à ce type d'argument en disant, par exemple, que les cgroups ne sont pas des fichiers.
Et les variables d'environnement sont là pour passer contrôler l'environnement d'exécution du programme. Une sortie audio devrait être un paramètre simple à modifier, aussi simple que d'indiquer une variable d'environnement. Donc question, pourquoi ceci n'est pas faisable :
Je ne sais pas si c'est possible ou pas, je ne m'y connais pas assez. D'ailleurs, est-ce impossible avec ALSA, et si ça l'est, l'était-ce aussi avec OSS, ou l'est-ce devenu par l'évolution du système, le son étant utilisé par de nombreuses applications à la fois, contrairement à l'écran (qui n'est utilisé que par X11 il me semble)?
Il est probable que ça le serait, avec un serveur de son (comme Xorg qui est un serveur graphique). N'est-ce pas ce que PA essaie d'être, d'ailleurs?
Non, parce que c'est tout de même étonnant qu'il n'y ai absolument rien à redire chez certains, tandis que chez d'autres, ça semble être l'enfer au quotidien.
C'est en fait assez habituel en informatique.
Les raisons sont au final assez simples:
configurations matérielles extrêmement diversifiées (il me semble qu'Apple à une époque ne vendait des systèmes que pour des config matos définies, ça me semble malin pour éviter ce type d'emmerdes et ainsi choper aisément une réputation de truc qui juste marche.)
usages tout aussi variés: on peut avoir affaire à un développeur qui code juste pour le taf et après oublie la moitié de ses compétences, à un geek passionné qui à une connaissance pointue de son système du côté matériel ou du côté logiciel, voire même des deux, ou encore à Mme michu dont le chat grimpe souvent sur le clavier, etc etc
des applications utilisées par la personne plus ou moins bien branlées
Donc, trouver des points communs, ce serait probablement facile, mais on pourrait aussi trouver une tonne de points communs entre ceux chez qui ça juste marche et les autres.
Perso, je préfère avoir un système simple (pas à utiliser, simple au niveau archi logicielle), et éviter les surcouches multiples permets ça. Parfois ça cause des emmerdes à devoir chercher pourquoi un truc déconne et comment le corriger, mais sur Debian il faut admettre que c'est rare, très rare. Mais on me diras que Debian, c'est déjà pas mal de surcouches par rapport à LFS par exemple :)
Après… dans quelle circonstances peut-on dire que la faute est à telle ou telle partie d'un sous-système et non aux logiciels qui l'utilisent… pas simple. J'ai longtemps été très agressif envers windows, jusqu'a que ce que je passe à Debian, ou je me suis aperçu qu'en fait, le problème c'était pas forcément l'OS, mais l'usage par l'application (et l'utilisation du logiciel par l'utilisateur, bien sûr).
Bah non, puisque l'application n'a pas forcément elle-même de quoi régler le volume. Et je me vois pas fouiller dans chaque application pour régler le volume. C'est bien plus rapide et pratique de passer par un endroit central.
Rien à signaler de la sorte chez pas mal de mondes depuis des années.
Idem. Aucune application à signaler qui utilise le son et ne me permette pas de le régler de façon simple.
Pour l'AV, c'est pas faux. Pour le reste, la plupart des gens que je côtoie n'en ont pas… ils utilisent des applications web (en fait , même pas sûr qu'ils aient des AV…) ce qui est la même chose que de désactiver les notifications au final, non?
Il y as que moi que ca choque les mots php et MMO dans la même phrase?
Ça aurait naturellement tendance à me gêner aussi, mais bon, je te parie qu'un code dans un langage réputé rapide (disons, le C, ou le C++, voire pourquoi pas l'ASM) peut être sacrément plus coûteux en ressources qu'un truc codé en PHP. Tout dépend du niveau du dev avec le langage en question en fait… Et, bien sûr, de l'astuce de celui qui a construit les structures sur lesquelles se base le moteur.
Beaucoup considére que une MMO c'est 100000 joueurs par node mini.
D'un autre côté, pour qu'une structure logicielle supporte un certain nombre de joueurs/instances/whatever, l'important n'est pas le langage, mais d'éviter les "magic values" dans le code. Tant qu'on évite les valeurs magiques, la contrainte viendra plus du matériel que du logiciel. Même si, bien sûr, utiliser des technologies économes (économes en quoi, d'ailleurs? temps CPU? volume mémoire? bande passante des I/Os? Et dans quelle mesure chaque, parce qu'on ne peux pas tout avoir…) permets d'économiser les ressources matérielles, je me souviens que des gens m'ont déjà dit que le client n'a qu'a racheter du matos… (ça m'avais choqué à l'époque, et l'idée me gonfle toujours autant, mais dans une certaine mesure ce n'est pas totalement faux…)
Le jeu serai pas plutot un jeu multi joueur?
Plus que le nombre de joueurs, je définirai un jeu massivement multi-joueurs par l'absence de fonctionnalités comparé à un jeu multi-joueur, parce qu'un jeu massivement multi-joueur n'a pour moi pas besoin d'IA: le côté massivement, quasi uniquement, multi-joueur implique que la plupart du temps de jeu sera dédié à des interactions inter-humains, alors qu'un jeu multi-joueurs se devra d'être capable de donner un vrai défi aux joueurs, et ne passera pas uniquement sur les compétences de l'équipe d'en face (si équipes il y à).
Et puis de toute façon, de ce que j'ai compris de la dépêche, il ne s'agit pas d'un jeu, mais d'un générateur de jeux, c'est à dire d'un moteur de jeu… le genre de trucs qui n'ont, à mon avis, qu'un intérêt académique.
Un jeu, c'est d'une part un moteur (M, MMO ou mono, RPG ou autre, peu importe) physique, couplé d'un moteur de rendu (pour le(s) joueur(s)), le tout lié par une technique quelconque (réseau, IPC, couplage hyper élevé…) combiné à un gameplay (difficile à définir, mais, en gros, l'âme du jeu, générée par les règles et les données, qu'elles soient graphiques, musicales ou même textuelles).
C'est énormément plus de travail. Un moteur de jeu, ce n'est qu'un bloc de code pur. Un générateur de jeu, c'est un moteur de jeu avec une dénomination moins repoussante pour celui qui voudra éventuellement faire un "mod".
Dans Windows 2000/XP, il n'y a qu'un seul volume global.
Si tu fais un simple clic sur l'icône, je suis d'accord, tu ne te retrouves qu'avec le master. Si tu fais un clic droit en revanche… tu te retrouves avec le truc complet.
Quand j'utilise alsamixer, oui, je reviens sous Windows 98 : une vue "hardware" du son archaïque et pas user-friendly, où seule le volume global est utile, mais sur lequel on n'a pas de contrôle plus fin du volume (cf. pas de contrôle par application).
C'est peut-être archaïque, mais le fait que ce ne soit pas user-friendly et pas assez fin, ce ne sont que tes opinions.
Peut-être partagées par pleins de gens, mais pas nécessairement par ne serait-ce que la moyenne. Tout comme la mienne, d'ailleurs.
Je pense personnellement que le contrôle réellement utilisé par 90% des gens, est le Master. Hors, le master est la première jauge dans alsamixer. Pour un truc plus simpliste qui cacherait les autres, les DEs ont en général ce qu'il faut de toute façon. alsamixer me sert principalement pour régler les choses quand je fais une installation, ou quand je veux jouer un peu avec mes raccourcis clavier (c'est un moyen simple d'avoir le nom des contrôles et de tester le fonctionnement).
Ceci dit, je te rejoins qu'un certain nombre de contrôles ont des noms obscurs.
mais sur lequel on n'a pas de contrôle plus fin du volume (cf. pas de contrôle par application).
Effectivement, ça, il n'y a pas.
En même temps, c'est peut-être ce dont tu as besoin 9 fois sur 10, mais moi je ne vois pas à quoi ça me servirait. Sur ma machine, je n'ai pas besoin de 150 applications qui me cassent les oreilles en même temps.
Il y à mpd pour la musique, mumble pour discuter, mplayer quand je regarde un film, et pour finir le browser pour le streaming. Ah, et quelques jeux aussi.
La plupart du temps, je n'ai que ma musique.
Quand je regarde un film ou un flux streaming, je ne fais que ça (cerveau mono-tâche), donc je coupe la musique et les éventuels jeux.
Quand je joue, je suis concentré sur les images du jeu, aucun film ne joue derrière, et c'est ma musique que je mets.
Et quand je veux couper le son du PC pour cause de téléphone, ben c'est le master que je veux couper…
Pour cet usage, qui me semble de mon point de vue personnel assez commun, aller dans un menu système pour contrôler le son des applications (en espérant que l'application soit supportée par PA) me paraît moins intuitif que d'aller dans les options du jeu couper la musique (chose que je ne fais que rarement, vu que je réactive rarement le son).
Je n'ai jamais eu de soucis avec une install de Debian, par contre, je t'avoue que j'ai toujours installé via le mode semi-graphique (ou mode "texte").
Par contre, je ne comprend pas… comment peux-tu lancer gparted à partir de l'installateur Debian? Le problème se produit bien entre le moment ou tu commences l'installation de Debian, c'est à dire après le menu de boot proposé par l'ISO, et le moment ou l'installation est finie, avant le reboot? (histoire d'être sûr que j'aie bien compris tes propos)
Je ne connais pas ce type de problème, mais serait-il possible qu'une de tes cartes son n'ait pas de firmware assez développé?
Après tout, tu as bien parlé d'une machine récente. Hors, il me semble que les fabricants de cartes ne font pas toujours des pilotes pour Linux… et rarement en open source, donc peut-être un pilote de non-free à rajouter?
(dont l'interface alsamixer ne me permet pas de voir seulement les périphériques de capture puis que F4 ferme l'application…)
Changes d'émulateur de terminal ou de gestionnaire de fenêtres alors (ou au moins leur configuration), parce que chez moi F4 ne ferme absolument pas l'application. Sur aucune machine sous Debian que j'ai utilisée, F4 n'a jamais fermé alsamixer (ni aucune fenêtre en fait).
Une possibilité, pourtant simple, que je souhaiterai avoir c'est rediriger l'audio d'une application (ou d'un ensemble d'applications) en un seul flux.
On a pas la même définition de simple, je le crains.
Ils ne sont pas évidents à utiliser pour des novices non-informaticiens.
Euh, alsamixer, le seul truc "difficile" c'est qu'il faut le lancer dans un terminal… et si c'est difficile, alors pourquoi ne pas utiliser alsamixergui? Pas besoin de terminal avec… et niveau difficulté, c'est plutôt intuitif: une jauge par I/O sonore en gros. La même que le mixer windows en fait. À moins que ce dernier n'ait changé depuis windows XP, bien entendu, mais je n'ai jamais entendu personne me dire qu'il ne savait pas l'utiliser.
Si je pouvais me passer de pulseaudio, je le ferais !
Quel logiciel exactement te contrains à l'utiliser? Je sais que je ne suis utilisateur ni de gnome, ni de KDE, mais à l'heure actuelle je n'ai jamais été contraint d'utiliser PA, et avec alsa, ça juste marche. Bon, je suppose qu'il me manque des tas de fonctionnalités, mais honnêtement, j'ignore lesquelles: je peux modifier le son de mon PC, le couper, activer/désactiver le micro… à peu près tout ce que je veux en fait.
À peu près, parce que, pour une raison qui m'est inconnue, mumble refuse d'utiliser le micro de ma tour, alors que sur une autre machine (sans PA également, bien entendu) il ne pose aucun problème. Je ne me suis jamais vraiment penché sur la question je l'admets (alors que l'écho du micro fonctionne, c'est vraiment les logiciels type mumble qui refusent d'utiliser le micro, donc pas un problème hardware ni, je suppose, de pilotes… 'fin bon…).
Et franchement je pense que la majorité des utilisateurs linux ne se rendent pas donc de cet ENORME qualité de l'interface Windows.
Je ne suis probablement pas la moyenne, et la config de mon système est clairement pas faite pour des gens qui veulent un truc intuitif sans avoir à configurer quoique ce soit, mais je n'utilise plus la souris que pour les jeux et naviguer sur internet.
Le reste du temps, tout se fait au clavier chez moi.
En fait, mon explorateur de fichiers, c'est un émulateur de terminal qui lance bash. Les émulateurs de terminaux sont des outils très puissants et souples… sauf celui de windows. Quant à bash, imaginer le comparer à cmd.exe est ridicule, ce n'est pas du tout la même catégorie. Powershell à la rigueur…
Par exemple, la taille des fenêtres n'est pas fixe (pas besoin de passer par les options pour la régler), le système d'auto-complétion qui rends la saisie de commandes complexes très rapides et sans nécessiter un apprentissage complet, ou encore, tout bêtement, la couleur. Bien sûr, de nombreux utilisateurs de ces outils apprécient leur capacité d'ouvrir des onglets, mais moi ça me sers pas, c'est pas le boulot des logiciels de gérer des fenêtres après tout.
Sans parler du fait que l'émulateur que j'utilise, urxvt, peut être utilisé en client/serveur, histoire d'économiser des ressources (ça peut être intéressant sur des machines peu puissantes quand on à lancé 20-30 terminaux…).
Pour la gestion des fenêtres, j'utilise un gestionnaire de fenêtres pavant, j'ai nommé i3.
Du coup je peux me balader d'un écran à l'autre en 2 touches, déplacer/redimensionner mes fenêtres à l'envi ou mieux: demander à mon système de lancer des commandes précises selon les combinaisons de touches que je fais. Bien sûr, vu que l'on parle de commandes, cela implique de pouvoir lancer des scripts bash.
Excessivement utile pour contrôler le volume (via amixer), la musique (j'utilise mpd, qui peut être piloté par mpc, ncmpcpp, ario et bien d'autres), voire même piloter des machines distantes sans bouger mes fesses de ma chaise ni mes mains de mon clavier.
Du coup, permets moi de douter que les utilisateurs de linux aient besoin de plus de clics pour ouvrir un fichier :)
Petits exemples de commandes que je peux lancer en 2 touches (voire moins si je veux):
# controle du volume
bindsym $mod+F12 exec "amixer set Master 5%+"
bindsym XF86AudioRaiseVolume exec "amixer set Master 5%+"
bindsym $mod+F10 exec "amixer set Master 5%-"
bindsym XF86AudioLowerVolume exec "amixer set Master 5%-"
bindsym XF86AudioMute exec "amixer set Master toggle"
bindsym $mod+F11 exec "amixer set Master toggle"
# ça, c'est le micro d'une machine secondaire (qui s'appelle pong, c'est plus fun quand je la ping), sur laquelle j'ai un client mumble qui tourne
# forcément, il faut au préalable avoir configuré son ssh proprement...
bindsym $mod+F9 exec ssh pong "amixer set Capture toggle"
# controle du player musical
bindsym $mod+comma exec "mpc prev"
bindsym $mod+exclam exec "mpc next"
bindsym $mod+space exec "mpc toggle"
# ça, c'est la touche Enter du pavé numérique... on peut récupérer ce style de codes en fouinant un peu
bindsym $mod+0xff8d exec "mpc toggle"
# j'ai plusieurs écrans, et accessoirement sur un PC portable mis à plat ça peut servir de pivoter l'affichage.
bindsym Mod1+$mod+Right exec "xrandr --output $sec_screen --rotate right"
bindsym Mod1+$mod+Left exec "xrandr --output $sec_screen --rotate left"
bindsym Mod1+$mod+Up exec "xrandr --output $sec_screen --rotate normal"
bindsym Mod1+$mod+Down exec "xrandr --output VGA1 --rotate inverted"
Bon, comme je l'ai dit, on est clairement pas sur une machine grand public, c'est mon outil de travail donc il me faut un truc qui soit adapté à moi. Chose impossible à faire sur un Windows, et pourtant j'ai essayé. L'émulateur de terminal, j'ai réussi à en trouver des corrects, mais je n'ai jamais réussi à trouver un gestionnaire de fenêtre potable qui me permette de gérer un nombre d'écrans variable aussi facilement, ni même simplement de pouvoir piloter mes fenêtres au clavier. Parce que les ALT+TAB et autres ALT+ESPACE,N pour passer d'une fenêtre à l'autre ou réduire les fenêtres, ça va bien un temps mais on perds quand même un temps fou.
Je n'ai pas abordé ce type d'outils avant, parce que je pense que c'est un usage avancé. Pas ce que je recommanderais à quelqu'un qui veut un truc joli ou qui fasse le café sans avoir à configurer quoique ce soit.
Mais tu as commencé en disant que sous Windows, on accède plus vite à ses applications, du coup, je t'indique une alternative :)
Le problème de linux, c'est qu'il y à trop de choix, et pour vraiment l'exploiter à fond, il faut apprendre, chose que l'on n'est plus trop habitués à faire.
Tiens, d'ailleurs, pour le presse papier, on peut aussi les piloter au clavier, puisqu'il existe la commande xclip qui permets d'y accéder. Je n'ai pas encore vraiment trouvé d'utilité à ça, sauf peut-être si un jour je voulais m'amuser à mettre un coup de sed sur un copier/coller…
Il y a toujours une version GTK 2 : d’après le site de Galculator : « galculator is a GTK 2 / GTK 3 based calculator ».
Les développeurs la maintiennent au moins pour MATE.
Pas dans le dépôt officiel de Debian. Du coup me suis rabattu sur speedcrunch, qui me conviens mieux au final, modulo le fait qu'il s'agissait (lors de mon changement) de la seule application à utiliser Qt de mon système.
D'ailleurs c'est drôle, libqt5gui5 dépend de libgtk2.0-0… la classe.
Ah, les dépendances Debian…
Exactement. Quand je quitterais Debian, ça sera la raison. Certains logiciels avec leurs dépendances en dur non justifiées techniquement, font qu'un système Debian sur lequel on joue à, disons, 10 jeux, peut se retrouver avec des fontes pour tous les pays du monde, par dizaines. Je me souviens avoir fait un rapport de bug la dessus, la réponse du mainteneur en question à été très claire: c'est au cas ou l'utilisateur n'aurait pas encore la bonne fonte installée sur son système (mais s'il est asiatique, typiquement, je suis à peu près sûr qu'il aura déjà les fontes correctes… bref).
Sans parler des gstreamer*, pour lesquels j'ai fini par faire des faux paquets (parce que sans gstreamer j'ai rien qui nécessite dbus, et que ça m'emmerde d'avoir un daemon qui tourne sans être utilisé…).
CrunchBang ? C’est une distribution, pas une calculatrice.
Oups, speedcrunch. Désolé.
Pour moi aussi, du coup, j’utilise surtout bc -l comme calculatrice (mais ça ne fait pas les conversions de bases).
Mes calculs sont très triviaux en général… et du coup devoir passer en mode interactif pour si peu m'agace. Au final, taper SUPER+G qui m'invoque speedcrunch est une solution potable que je préfère à bc, sans raison particulière.
Au moins je peux fermer la calculatrice avec une combinaison de 3 touches, au lieu de 5 (en série), et la combinaison en question est celle que j'utilise avec tous mes logiciels.
Autre raison, très peu valable également, c'est la flemme d'apprendre. speedcrunch étant graphique (mais exploitable entièrement au clavier, très important pour moi ça) l'apprentissage est plus simple.
Commences par l'astuce suprême: sélectionner un texte le mets dans un "presse-papier" spécifique, sans action (pas de ctrl+c nécessaire, et pas de collision avec celui copié préalablement).
Pour le ressortir, il suffit de faire un clic milieu.
Ce truc, c'est l'une des deux fonctionnalités qui font que, au quotidien, je ne pourrais plus utiliser un bureau windows, en admettant que je puisse me passer des gestionnaires de fenêtres pavant (perso, j'utilise i3).
La 2ème astuce, c'est que pour contrôler une fenêtre (avec un gestionnaire de fenêtres "classique"), on est pas obligé d'aller chercher les bordures. Typiquement, il suffit de maintenir la touche ALT (configurable, bien sûr) pendant un clic droit pour redimensionner, ou avec un clic gauche pour déplacer, même au milieu de la fenêtre.
# Différences entre les outils et les applications finales
Posté par freem . En réponse au journal Cinq ans de projets libres: bilan et retour d'expérience sur la contribution. Évalué à 10.
Merci pour le petit résumé, il est intéressant de lire quelqu'un qui est des 2 côtés de la "barrière".
Ceci étant dit, j'ai, comme j'imagine une frange non négligeable de la population qui visite linuxfr, déjà contribué à certains projets, ou au moins essayé.
Du peu de contributions que j'ai tentées, j'ai discerné, peut-être à tord, plusieurs axes qui vont influencer le comportement en réponse de la contribution:
Je n'ai qu'une ou deux anecdotes sur des projets de type outils, uniquement des bibliothèques C ou C++ (la réaction des développeur change-t-elle en fonction du langage? Je n'en sais rien.). En général, j'ai eu l'impression, si le développement était encore actif, d'une certaine bienveillance.
J'ai corrigé 2-3 bugs (one-liners, souvent) et erreurs ou imprécisions de doc ici et là.
Dans le cas (oui, LE) ou j'ai corrigé une imprécision de la doc, j'en ai profité pour soumettre une demande de fonctionnalité (sur GLFW3, une histoire de presse-papier, j'avais surtout testé pour le fun, mais la doc était imprécise et le comportement faisait que si l'utilisateur (un dev, donc) considérait une erreur comme une raison de crash (comme moi, encore, même si parfois le contexte fait qu'il faut tenter de récupérer un état stable). Du coup, j'ai suggéré plusieurs choses: donner un moyen de vérifier que le presse-papier contiens effectivement des données avant de les récupérer, ou… je ne me souviens plus.
Les devs ont opté (ce que j'aurai aussi fait, et donc ai mis en valeur dans ma suggestion) pour améliorer la précision de la doc et introduire une fonction pour vérifier que le presse papier contiens quelque chose dans une version future. On verra dans le futur si la fonctionnalité est implémentée… Ça ne me tenais pas vraiment à cœur, sinon j'aurai sûrement soumis un patch, je voulais juste jouer un peu avec le code quand je suis tombé sur le comportement surprenant en question.
Sur des "produits finaux", en revanche, j'ai un peu plus à dire. j'ai tenté bien plus souvent d'aider, et les retours sont assez divers.
Parfois, on à l'impression d'être ignoré, purement et simplement.
J'ai en mémoire un vent sur Debian, ou j'ai signalé un bug de udev qui partait en boucle infinie, qui menait à une augmentation des processus udev, et donc une saturation de la RAM, ce qui mène à un état ou Linux ne répond juste plus. Au temps pour le fameux "dans l'open source on corrige en 2s les bugs signalés". Au final, il n'était pas tombé dans l'oubli, j'ai eu un retour sur mon mail plus d'un an après avoir soumis le bug.
J'avoue, mon comportement n'a pas été modèle sur ce coup: au bout d'un an, j'ai encore une image disque avec les données qui reproduisent le bug, mais je n'ai même pas daigné répondre. J'ai mal pris le fait de ne même pas avoir le moindre retour en 12 mois. J'ose espérer que c'est humain. D'autant que, pendant ces 12 mois, Jessie est parue ( est-ce la raison pour laquelle je n'ai pas eu de retours avant? ) et les changements de Debian autant que mon évolution personnelle font qu'il ne me manque pas grand chose pour changer de distrib. Cette histoire à aussi dû contribuer à cette volonté, malgré que j'éprouve réellement un grand respect pour Debian.
Dans d'autres cas le mainteneur est en désaccord avec le ticket, mais répond rapidement et poliment. Là, c'est agréable. Ça m'est arrivé, encore une fois sur Debian, par rapport à un jeu (mars shooter, plutôt fun, je vous le conseille) qui à une dépendance dure sur … des polices de caractères. Son argument était valide par rapport au projet, au final, donc je n'ai pas insisté (mais c'est probablement une des raisons qui font que je cesserai d'utiliser Debian quand j'aurai le courage d'aller sur une distro plus pointue).
Il y à aussi le cas ou l'on cherche à s'impliquer, et ou l'on s'aperçois sur une session IRC laissée en suspend qu'en fait les gens préfèrent vous ignorer plutôt que de répondre. Même pas ils diraient qu'on va trop loin, non non, il préfère laisser les contributeurs potentiels rédiger des messages propres et essayer de patcher le code, sans leur dire qu'en fait, ils en ont rien à carrer. Je ne citerai pas le projet en question, mais vous comprendrez que j'ai juste arrêté de donner des nouvelles, du jour au lendemain. Aujourd'hui, il est encore vivant, tant mieux, il à évolué, tant mieux encore, mais j'ai constaté pas mal de régressions dans les fonctionnalités, et ça me fait autant sourire que mal (parce que si je voulais m'y impliquer c'est que je l'aime).
Il y à aussi les projets, genre valyria tear (un jrpg, des plus prometteurs à mon avis), ou il y a peu de gens, qui sont heureux de recevoir les contributions, et vont jusqu'a recontacter les gens (un nettoyage des allocations mémoire C dans un code C++, je soupçonnais un memory leak de là mais ça n'a rien résolu… le problème viendrai peut-être de la lib pour lua du coup… Tant pis, le code semble avoir quand même été intégré vu que j'ai refondu pour respecter mieux le style de code qui semblait être le final, il faudrait que j'aille remercier).
Enfin, il y à toutes sortes de projets, et ce ne sont pas mes expériences négatives avec certains qui m'empêcheront de tenter de contribuer à de nouveaux projets, que ce soit par le code ou par les tickets. Je reste par contre un véritable contributeur de passage, les rares fois ou j'ai tenté de m'impliquer à fond dans un projet m'ont tellement refroidi que je n'ai plus l'intention de m'intégrer dans une équipe (sauf boulot, mais c'est différent). Tant qu'a faire, je préfère encore forker ou réécrire, si j'ai trop de trucs à changer. Et le signaler au projet original, qui est du coup libre d'intégrer ou non les patchs.
Oui, ça augmente potentiellement la fragmentation, mais entre nous: je m'en fiche. Je mets toujours un lien vers le projet originel, je l'averti aussi toujours en face, et s'il intègre assez de modifs, je vire mon fork.
Au final, moi, je suis plus serein parce que je n'ai pas à me prendre la tête à convaincre par des mots qui ne serons même pas lus (et personne pour répondre franchement: "TL;DR" ou "rien à foutre de ton idée") et j'ai un soft qui marche comme je le veux. Et le projet originel est libre d'intégrer mes idées si ça lui chante et si ça fonctionne. Gagnant-gagnant pour moi.
# Quelques liens
Posté par freem . En réponse au message Apprentissage d'OpenGL . Évalué à 8.
J'ai récemment aussi fait ce type de recherches.
J'avais besoin de tutoriels qui permettent d'avoir rapidement quelque chose à l'écran, pas nécessairement complexe, et des bouts de code qui compilent sur ma plateforme, qui est une Debian, et sans avoir besoin de galérer avec un IDE (je me contente de git, vim, cmake et cgdb personnellement).
Je programme habituellement en C++, mais je lis le C sans grand problèmes (ils ne sont pas "frères" pour rien).
Autrement dis, je ne cherchais pas des tutoriels pour apprendre à programmer, juste pour gérer les bases de l'OpenGL et les shaders, de façon portable (histoire d'avoir un minimum de rendu pour mon projet, en somme).
Si tu as le même type de besoins, j'ai trouvé ces liens la, par ordre de préférence (et de complétion de lecture, je n'ai pas tout lu)
Le 1er utilise GLFW pour gérer la fenêtre (OpenGL ne fait que dessiner un "tas de pixels", ça ne gère ni les fenêtres ni les entrées), le source est en C et relativement clair, même si parfois les étapes entre 2 tutoriels sont un peu larges.
Le fait d'être basé sur GLFW contribue certainement à rendre le code moins pénible à modifier, à mon avis, mais d'un autre côté tu trouveras moins de bouts de code pour GLFW, surtout que la version 3 est sortie relativement récemment.
Comme j'ai personnellement une préférence pour les bibliothèques qui ne font qu'une seule chose et la font bien, le fait d'être basé sur GLFW3 est un gros avantage. Cette bibliothèque à une documentation extrêmement claire, et ne fait vraiment QUE contrôler une fenêtre. Pas de gestion du son, du réseau ni du dessin proprement dit.
L'API publique de GLFW3 est en C, donc c'est utilisable en C, même si j'ai personnellement écrit quelques wrappers histoire d'en faire moins (l'avantage de la RAII en somme).
Le 2nd utilise se base sur GLUT au lieu de GLFW, qui est une bibliothèque qui se base sur un système de callbacks.
Au niveau du code OpenGL proprement dit, je le trouve plus clair, et avec des étapes plus courtes, que le 1er. Il n'arrive en 2nde position pour 2 raisons: je ne l'ai trouvé que récemment, et n'ai donc pas lu autant que pour les autres, et il se base sur GLUT.
GLUT est une bibliothèque très prisée dans le monde de l'OpenGL, mais je t'avoues avoir un peu de mal avec les systèmes à base de callbacks. Ça ne fait pas un très bon mélange avec les objets du C++… et niveau lisibilité je trouve ça assez moche.
Le 3ème, c'est du C++ pur et dur, avec Visual Studio. Il se base sur l'API de windows.
J'ai trouvé le code et les explications globalement plus clairs que pour le 1er, parfois je lisais les 2 côte à côte.
Il est 3ème, parce qu'utilisant l'API windows et Visual Studio, il ne se conforme pas du tout à mon objectif de portabilité.
Enfin, le dernier, sur wikibooks souffre d'un problème récurrent chez les documents de wikibooks (que j'ai lus, du moins): il dégage une forte impression de "Work In Progress", qui ne donne pas confiance.
Je m'en sers quand même quand j'ai besoin d'un bout de code ou d'une explication rapide pour un problème simple.
# cache apt
Posté par freem . En réponse au message Echec de la mise à niveau 14.04.3 LTS . Évalué à 5.
Côté graphique pour vérifier ou est l'espace trop occupé, il existe baobab (du moins, existait, je ne sais pas si ça existe encore) sous gnome.
Si le système est dans un état ou l'on ne peux plus démarrer graphiquement (ça m'est déjà arrivé quand la racine était vraiment blindée de chez blindée),
df -h --max-depth=1 /te permettra de vérifier qui prend toute la place sur la racine ( le fameux "disque /" ) en ligne de commande. À noter qu'il y à aussidu -hmais celui-ci ne fait qu'indiquer pour les partitions montées l'espace disque utilisé (mais il est nettement plus rapide, pas besoin de calculer).Mon opinion: éviter de suivre sans les comprendre des recommandations de lignes de commandes trouvées sur le net.
Plusieurs raisons:
Maintenant, si tu nous disais quelles manipulations tu as effectuées, il est sûrement possible de remettre le système à jour sans réinstaller, mais ça sera sûrement plus long qu'une réinstallation sur disque vide. Rien que le fait que les explications devrons se faire attendre sur un forum rendra ça plus long, mais au moins ça pourrais te permettre de comprendre pourquoi tu en es arrivé là.
[^] # Re: bravo
Posté par freem . En réponse au message Echec de la mise à niveau 14.04.3 LTS . Évalué à 2.
Si tu trouves que c'est difficile, figures-toi que ça m'est arrivé à plusieurs reprises sur ma Debian. Au final, c'est plutôt très simple, en fait.
Pour le fait de le faire sans en faire exprès, c'est assez facile aussi, surtout dans le cas de l'OP: si la mise à jour à raté, rien de surprenant à ce que le système revienne dans un état stable, autrement dit, la version d'avant la mise à jour.
[^] # Re: USB bootable?
Posté par freem . En réponse au message cd d ubuntu envoie au maroc ?. Évalué à 3.
Qui n'est pas disponible sur tous les systèmes. Typiquement, Windows n'a pas cette commande, il me semble.
Une solution qui me parait plus simple pour quelqu'un qui débute peut-être (ne pas penser à utiliser une clé usb peut indiquer ce cas de figure) est d'utiliser un logiciel graphique tel que liliusb.
Et ça évite de lire le FM, ce qui n'est pas toujours une mauvaise chose.
[^] # Re: alternative : sndio, projet OpenBSD pour l'audio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Je ne faisais que parler de l'état des choses, pas de l'idéal. Je ne suis ni dev kernel, ni dev temps-réel (l'audio c'est du temps réel pour moi), donc je ne sais pas pourquoi c'est ainsi.
Il semblerait que OSS mettait un fichier /dev/dsp, que l'on pourrait accéder via les appels système open/close/read/write (qui sont les appels systèmes pour ouvrir/fermer/lire/écrire des fichiers, sur un système POSIX).
Du coup, la question est plutôt, pourquoi avoir arrêté d'utiliser un fichier accessible simplement pour gérer le son?
Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur (et en terme de programmation, je n'ai utilisé ni l'un ni l'autre. Et le jour ou je devrais, je passerai par une bibliothèque, comme tout le monde).
Sinon, tu peux jouer du son en ligne de commande, il te suffit de passer tes données directement à aplay. Mais si les applications faisaient ça, je pense que nos CPUs n'aimeraient pas trop… pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte… pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants.
Note: vu qu'on peut accéder à OSS par un fichier dans /dev, je me demande si y'a moyen de jouer avec les socket BSD par la aussi…
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 3.
Je parlais de les oublier le temps qu'il est hors du taf… j'ai parlé de dev, j'aurai pu parler de n'importe quel professionnel de l'informatique en fait. De même, "oublier la moitié[…]" est une façon de parler, s'il les oubliais vraiment il ne pourrais pas les retrouver en franchissant le seuil de sa boîte.
[^] # Re: php et MMORPG?
Posté par freem . En réponse à la dépêche Caranille 1.0 RC 1. Évalué à 4. Dernière modification le 22 octobre 2015 à 23:17.
TL;DR:
fais moi donc un programme qui envoie "hello world" à un autre programme, en C ou en C++, qui compile sur n'importe quel système supporté par PHP, et sans utiliser de bibliothèque externe.
Version complète:
Si je ne m'abuse, le PHP était à l'origine une simple bibliothèque de fonctions pour le langage C, c'est d'ailleurs la raison qui fait qu'une bonne partie de la libC est accessible. Je me souviens avoir corrigé un problème de "magic values" (cf plus bas, en l'occurrence il s'agissait des param de connexion à des SGBDR) au taf en collant ces données dans un fichier externe, lu avec un bon vieux fscanf des familles (et sans me gêner quant à utiliser la capacité de scanf à utiliser les regex… c'était toujours plus maintenable que l'existant de toute façon).
Donc je serais assez surpris que PHP ne permette pas d'établir de connexion réseau… Quoiqu'en fait non, parce si on se contente du langage et de sa bibliothèque standard, ni le C, ni le C++ ne peuvent actuellement le faire. Ils ne sont même pas capables, en standard, de faire une requête HTTP…
Autrement dit, malgré que je trouve le PHP absolument crade (mais je n'ai peut-être jamais vu de bon code PHP, ceci expliquerais cela) il est manifeste que le PHP est plus puissant en terme réseau que le C ou le C++, si on se base sur le standard brut.
Valeurs codées en dur dans le code. Genre, coller la taille d'une zone mémoire à 0x1FFFF, en ne permettant pas de le changer à partir d'une option de compilation et/ou de configuration.
Je le sais, mais c'est loin d'être trivial. Je suis dev C++ aussi, mais j'ai vu tellement de logiciels codés en C ou C++ comme des gorets que je me suis fait une raison: ce n'est pas le langage qui importe.
Moi aussi. Mais celui qui nous paye, c'est rarement l'utilisateur, et loi de wirth ou pas, il faut bien manger :)
Accessoirement, actuellement il me semble que la majorité des décisionnaires soient peu enclins à miser sur l'avenir, préférant les profits immédiats. J'aimerai avoir la preuve par le vécu que je me trompe.
Parfois ils vont préférer cracher quelques centaines d'€ de moins pendant le dev, pour payer plusieurs milliers d'€ de plus pendant des années, parce que de toute façon, eux auront migré ailleurs. Je ne parle même pas des problèmes de maintenance qu'une base de code dégueulasse va poser à l'avenir lorsqu'un pauvre hère devra corriger un bug ou ajouter une fonctionnalité sans avoir eu la moindre explication parce que de toute façon les dev histo sont plus la.
Ce qui deviens, encore une fois, des € dépensés en plus, mais on s'en fout, parce que le décisionnaire d'origine n'est plus là.
[^] # Re: alternative : sndio, projet OpenBSD pour l'audio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 3.
Pas vraiment, non. Si tu veux un système qui aie vraiment poussé cette idée, il faut plutôt aller voir du côté de plan9, c'est du moins ce que l'on m'a dis.
De toute façon, GNU/Linux n'est pas UNIX qui est un OS à part, ni même POSIX, qui est une norme inspirée d'UNIX. Cf ce lien que m'a fourni wikipedia et que, je l'admets, je n'ai pas envie d'aller lire :) (du coup on peut me répondre que vu l'âge du document, il est caduc).
Je crois avoir le souvenir de quelqu'un ici répondre à ce type d'argument en disant, par exemple, que les cgroups ne sont pas des fichiers.
Je ne sais pas si c'est possible ou pas, je ne m'y connais pas assez. D'ailleurs, est-ce impossible avec ALSA, et si ça l'est, l'était-ce aussi avec OSS, ou l'est-ce devenu par l'évolution du système, le son étant utilisé par de nombreuses applications à la fois, contrairement à l'écran (qui n'est utilisé que par X11 il me semble)?
Il est probable que ça le serait, avec un serveur de son (comme Xorg qui est un serveur graphique). N'est-ce pas ce que PA essaie d'être, d'ailleurs?
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 5.
C'est en fait assez habituel en informatique.
Les raisons sont au final assez simples:
Donc, trouver des points communs, ce serait probablement facile, mais on pourrait aussi trouver une tonne de points communs entre ceux chez qui ça juste marche et les autres.
Perso, je préfère avoir un système simple (pas à utiliser, simple au niveau archi logicielle), et éviter les surcouches multiples permets ça. Parfois ça cause des emmerdes à devoir chercher pourquoi un truc déconne et comment le corriger, mais sur Debian il faut admettre que c'est rare, très rare. Mais on me diras que Debian, c'est déjà pas mal de surcouches par rapport à LFS par exemple :)
Après… dans quelle circonstances peut-on dire que la faute est à telle ou telle partie d'un sous-système et non aux logiciels qui l'utilisent… pas simple. J'ai longtemps été très agressif envers windows, jusqu'a que ce que je passe à Debian, ou je me suis aperçu qu'en fait, le problème c'était pas forcément l'OS, mais l'usage par l'application (et l'utilisation du logiciel par l'utilisateur, bien sûr).
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 3.
Idem. Aucune application à signaler qui utilise le son et ne me permette pas de le régler de façon simple.
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Pour l'AV, c'est pas faux. Pour le reste, la plupart des gens que je côtoie n'en ont pas… ils utilisent des applications web (en fait , même pas sûr qu'ils aient des AV…) ce qui est la même chose que de désactiver les notifications au final, non?
[^] # Re: php et MMORPG?
Posté par freem . En réponse à la dépêche Caranille 1.0 RC 1. Évalué à 0.
Ça aurait naturellement tendance à me gêner aussi, mais bon, je te parie qu'un code dans un langage réputé rapide (disons, le C, ou le C++, voire pourquoi pas l'ASM) peut être sacrément plus coûteux en ressources qu'un truc codé en PHP. Tout dépend du niveau du dev avec le langage en question en fait… Et, bien sûr, de l'astuce de celui qui a construit les structures sur lesquelles se base le moteur.
D'un autre côté, pour qu'une structure logicielle supporte un certain nombre de joueurs/instances/whatever, l'important n'est pas le langage, mais d'éviter les "magic values" dans le code. Tant qu'on évite les valeurs magiques, la contrainte viendra plus du matériel que du logiciel. Même si, bien sûr, utiliser des technologies économes (économes en quoi, d'ailleurs? temps CPU? volume mémoire? bande passante des I/Os? Et dans quelle mesure chaque, parce qu'on ne peux pas tout avoir…) permets d'économiser les ressources matérielles, je me souviens que des gens m'ont déjà dit que le client n'a qu'a racheter du matos… (ça m'avais choqué à l'époque, et l'idée me gonfle toujours autant, mais dans une certaine mesure ce n'est pas totalement faux…)
Plus que le nombre de joueurs, je définirai un jeu massivement multi-joueurs par l'absence de fonctionnalités comparé à un jeu multi-joueur, parce qu'un jeu massivement multi-joueur n'a pour moi pas besoin d'IA: le côté massivement, quasi uniquement, multi-joueur implique que la plupart du temps de jeu sera dédié à des interactions inter-humains, alors qu'un jeu multi-joueurs se devra d'être capable de donner un vrai défi aux joueurs, et ne passera pas uniquement sur les compétences de l'équipe d'en face (si équipes il y à).
Et puis de toute façon, de ce que j'ai compris de la dépêche, il ne s'agit pas d'un jeu, mais d'un générateur de jeux, c'est à dire d'un moteur de jeu… le genre de trucs qui n'ont, à mon avis, qu'un intérêt académique.
Un jeu, c'est d'une part un moteur (M, MMO ou mono, RPG ou autre, peu importe) physique, couplé d'un moteur de rendu (pour le(s) joueur(s)), le tout lié par une technique quelconque (réseau, IPC, couplage hyper élevé…) combiné à un gameplay (difficile à définir, mais, en gros, l'âme du jeu, générée par les règles et les données, qu'elles soient graphiques, musicales ou même textuelles).
C'est énormément plus de travail. Un moteur de jeu, ce n'est qu'un bloc de code pur. Un générateur de jeu, c'est un moteur de jeu avec une dénomination moins repoussante pour celui qui voudra éventuellement faire un "mod".
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 3.
Si tu fais un simple clic sur l'icône, je suis d'accord, tu ne te retrouves qu'avec le master. Si tu fais un clic droit en revanche… tu te retrouves avec le truc complet.
C'est peut-être archaïque, mais le fait que ce ne soit pas user-friendly et pas assez fin, ce ne sont que tes opinions.
Peut-être partagées par pleins de gens, mais pas nécessairement par ne serait-ce que la moyenne. Tout comme la mienne, d'ailleurs.
Je pense personnellement que le contrôle réellement utilisé par 90% des gens, est le Master. Hors, le master est la première jauge dans alsamixer. Pour un truc plus simpliste qui cacherait les autres, les DEs ont en général ce qu'il faut de toute façon. alsamixer me sert principalement pour régler les choses quand je fais une installation, ou quand je veux jouer un peu avec mes raccourcis clavier (c'est un moyen simple d'avoir le nom des contrôles et de tester le fonctionnement).
Ceci dit, je te rejoins qu'un certain nombre de contrôles ont des noms obscurs.
Effectivement, ça, il n'y a pas.
En même temps, c'est peut-être ce dont tu as besoin 9 fois sur 10, mais moi je ne vois pas à quoi ça me servirait. Sur ma machine, je n'ai pas besoin de 150 applications qui me cassent les oreilles en même temps.
Il y à mpd pour la musique, mumble pour discuter, mplayer quand je regarde un film, et pour finir le browser pour le streaming. Ah, et quelques jeux aussi.
La plupart du temps, je n'ai que ma musique.
Quand je regarde un film ou un flux streaming, je ne fais que ça (cerveau mono-tâche), donc je coupe la musique et les éventuels jeux.
Quand je joue, je suis concentré sur les images du jeu, aucun film ne joue derrière, et c'est ma musique que je mets.
Et quand je veux couper le son du PC pour cause de téléphone, ben c'est le master que je veux couper…
Pour cet usage, qui me semble de mon point de vue personnel assez commun, aller dans un menu système pour contrôler le son des applications (en espérant que l'application soit supportée par PA) me paraît moins intuitif que d'aller dans les options du jeu couper la musique (chose que je ne fais que rarement, vu que je réactive rarement le son).
# Utiliser le mode semi-graphique
Posté par freem . En réponse au message [Résolu] écran s'éteint au lancement de l'installation. Évalué à 2.
Je n'ai jamais eu de soucis avec une install de Debian, par contre, je t'avoue que j'ai toujours installé via le mode semi-graphique (ou mode "texte").
Par contre, je ne comprend pas… comment peux-tu lancer gparted à partir de l'installateur Debian? Le problème se produit bien entre le moment ou tu commences l'installation de Debian, c'est à dire après le menu de boot proposé par l'ISO, et le moment ou l'installation est finie, avant le reboot? (histoire d'être sûr que j'aie bien compris tes propos)
[^] # Re: Mécontent de PA
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Je ne connais pas ce type de problème, mais serait-il possible qu'une de tes cartes son n'ait pas de firmware assez développé?
Après tout, tu as bien parlé d'une machine récente. Hors, il me semble que les fabricants de cartes ne font pas toujours des pilotes pour Linux… et rarement en open source, donc peut-être un pilote de non-free à rajouter?
[^] # Re: Transparence réseau
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Il dit que la ou le passage de X11 à wayland nous fait perdre le fait de pouvoir déporter l'information sur le réseau, PA ajoutes cette possibilité.
[^] # Re: alternative : sndio, projet OpenBSD pour l'audio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Changes d'émulateur de terminal ou de gestionnaire de fenêtres alors (ou au moins leur configuration), parce que chez moi F4 ne ferme absolument pas l'application. Sur aucune machine sous Debian que j'ai utilisée, F4 n'a jamais fermé alsamixer (ni aucune fenêtre en fait).
On a pas la même définition de simple, je le crains.
[^] # Re: Contrôle du volume en réseau
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
S'il existe un outil en ligne de commande pour piloter PA (style le amixer de alsa) alors tu peux simplement passer par ssh.
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 3.
Euh, alsamixer, le seul truc "difficile" c'est qu'il faut le lancer dans un terminal… et si c'est difficile, alors pourquoi ne pas utiliser alsamixergui? Pas besoin de terminal avec… et niveau difficulté, c'est plutôt intuitif: une jauge par I/O sonore en gros. La même que le mixer windows en fait. À moins que ce dernier n'ait changé depuis windows XP, bien entendu, mais je n'ai jamais entendu personne me dire qu'il ne savait pas l'utiliser.
[^] # Re: Aide sur Pulseaudio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 6.
Quel logiciel exactement te contrains à l'utiliser? Je sais que je ne suis utilisateur ni de gnome, ni de KDE, mais à l'heure actuelle je n'ai jamais été contraint d'utiliser PA, et avec alsa, ça juste marche. Bon, je suppose qu'il me manque des tas de fonctionnalités, mais honnêtement, j'ignore lesquelles: je peux modifier le son de mon PC, le couper, activer/désactiver le micro… à peu près tout ce que je veux en fait.
À peu près, parce que, pour une raison qui m'est inconnue, mumble refuse d'utiliser le micro de ma tour, alors que sur une autre machine (sans PA également, bien entendu) il ne pose aucun problème. Je ne me suis jamais vraiment penché sur la question je l'admets (alors que l'écho du micro fonctionne, c'est vraiment les logiciels type mumble qui refusent d'utiliser le micro, donc pas un problème hardware ni, je suppose, de pilotes… 'fin bon…).
[^] # Re: ca ne sert a rien
Posté par freem . En réponse au message Fonctionnalité -> Fichiers récents. Évalué à 3.
Je ne suis probablement pas la moyenne, et la config de mon système est clairement pas faite pour des gens qui veulent un truc intuitif sans avoir à configurer quoique ce soit, mais je n'utilise plus la souris que pour les jeux et naviguer sur internet.
Le reste du temps, tout se fait au clavier chez moi.
En fait, mon explorateur de fichiers, c'est un émulateur de terminal qui lance bash. Les émulateurs de terminaux sont des outils très puissants et souples… sauf celui de windows. Quant à bash, imaginer le comparer à cmd.exe est ridicule, ce n'est pas du tout la même catégorie. Powershell à la rigueur…
Par exemple, la taille des fenêtres n'est pas fixe (pas besoin de passer par les options pour la régler), le système d'auto-complétion qui rends la saisie de commandes complexes très rapides et sans nécessiter un apprentissage complet, ou encore, tout bêtement, la couleur. Bien sûr, de nombreux utilisateurs de ces outils apprécient leur capacité d'ouvrir des onglets, mais moi ça me sers pas, c'est pas le boulot des logiciels de gérer des fenêtres après tout.
Sans parler du fait que l'émulateur que j'utilise, urxvt, peut être utilisé en client/serveur, histoire d'économiser des ressources (ça peut être intéressant sur des machines peu puissantes quand on à lancé 20-30 terminaux…).
Pour la gestion des fenêtres, j'utilise un gestionnaire de fenêtres pavant, j'ai nommé i3.
Du coup je peux me balader d'un écran à l'autre en 2 touches, déplacer/redimensionner mes fenêtres à l'envi ou mieux: demander à mon système de lancer des commandes précises selon les combinaisons de touches que je fais. Bien sûr, vu que l'on parle de commandes, cela implique de pouvoir lancer des scripts bash.
Excessivement utile pour contrôler le volume (via amixer), la musique (j'utilise mpd, qui peut être piloté par mpc, ncmpcpp, ario et bien d'autres), voire même piloter des machines distantes sans bouger mes fesses de ma chaise ni mes mains de mon clavier.
Du coup, permets moi de douter que les utilisateurs de linux aient besoin de plus de clics pour ouvrir un fichier :)
Petits exemples de commandes que je peux lancer en 2 touches (voire moins si je veux):
Bon, comme je l'ai dit, on est clairement pas sur une machine grand public, c'est mon outil de travail donc il me faut un truc qui soit adapté à moi. Chose impossible à faire sur un Windows, et pourtant j'ai essayé. L'émulateur de terminal, j'ai réussi à en trouver des corrects, mais je n'ai jamais réussi à trouver un gestionnaire de fenêtre potable qui me permette de gérer un nombre d'écrans variable aussi facilement, ni même simplement de pouvoir piloter mes fenêtres au clavier. Parce que les ALT+TAB et autres ALT+ESPACE,N pour passer d'une fenêtre à l'autre ou réduire les fenêtres, ça va bien un temps mais on perds quand même un temps fou.
Je n'ai pas abordé ce type d'outils avant, parce que je pense que c'est un usage avancé. Pas ce que je recommanderais à quelqu'un qui veut un truc joli ou qui fasse le café sans avoir à configurer quoique ce soit.
Mais tu as commencé en disant que sous Windows, on accède plus vite à ses applications, du coup, je t'indique une alternative :)
Le problème de linux, c'est qu'il y à trop de choix, et pour vraiment l'exploiter à fond, il faut apprendre, chose que l'on n'est plus trop habitués à faire.
Tiens, d'ailleurs, pour le presse papier, on peut aussi les piloter au clavier, puisqu'il existe la commande xclip qui permets d'y accéder. Je n'ai pas encore vraiment trouvé d'utilité à ça, sauf peut-être si un jour je voulais m'amuser à mettre un coup de sed sur un copier/coller…
[^] # Re: Précisions sur la questions
Posté par freem . En réponse au message Programmation d'un site musical à base de donnée libre. Évalué à 3.
Je vois que personne n'a encore parlé de dogmazic. Tu peux toujours aller y faire un tour.
[^] # Re: crunchbang
Posté par freem . En réponse au journal Calculatrice : matériel et logiciel ouverts ?. Évalué à 3.
Pas dans le dépôt officiel de Debian. Du coup me suis rabattu sur speedcrunch, qui me conviens mieux au final, modulo le fait qu'il s'agissait (lors de mon changement) de la seule application à utiliser Qt de mon système.
D'ailleurs c'est drôle, libqt5gui5 dépend de libgtk2.0-0… la classe.
Exactement. Quand je quitterais Debian, ça sera la raison. Certains logiciels avec leurs dépendances en dur non justifiées techniquement, font qu'un système Debian sur lequel on joue à, disons, 10 jeux, peut se retrouver avec des fontes pour tous les pays du monde, par dizaines. Je me souviens avoir fait un rapport de bug la dessus, la réponse du mainteneur en question à été très claire: c'est au cas ou l'utilisateur n'aurait pas encore la bonne fonte installée sur son système (mais s'il est asiatique, typiquement, je suis à peu près sûr qu'il aura déjà les fontes correctes… bref).
Sans parler des gstreamer*, pour lesquels j'ai fini par faire des faux paquets (parce que sans gstreamer j'ai rien qui nécessite dbus, et que ça m'emmerde d'avoir un daemon qui tourne sans être utilisé…).
Oups, speedcrunch. Désolé.
Mes calculs sont très triviaux en général… et du coup devoir passer en mode interactif pour si peu m'agace. Au final, taper SUPER+G qui m'invoque speedcrunch est une solution potable que je préfère à bc, sans raison particulière.
Au moins je peux fermer la calculatrice avec une combinaison de 3 touches, au lieu de 5 (en série), et la combinaison en question est celle que j'utilise avec tous mes logiciels.
Autre raison, très peu valable également, c'est la flemme d'apprendre. speedcrunch étant graphique (mais exploitable entièrement au clavier, très important pour moi ça) l'apprentissage est plus simple.
[^] # Re: ca ne sert a rien
Posté par freem . En réponse au message Fonctionnalité -> Fichiers récents. Évalué à 4.
Commences par l'astuce suprême: sélectionner un texte le mets dans un "presse-papier" spécifique, sans action (pas de ctrl+c nécessaire, et pas de collision avec celui copié préalablement).
Pour le ressortir, il suffit de faire un clic milieu.
Ce truc, c'est l'une des deux fonctionnalités qui font que, au quotidien, je ne pourrais plus utiliser un bureau windows, en admettant que je puisse me passer des gestionnaires de fenêtres pavant (perso, j'utilise i3).
La 2ème astuce, c'est que pour contrôler une fenêtre (avec un gestionnaire de fenêtres "classique"), on est pas obligé d'aller chercher les bordures. Typiquement, il suffit de maintenir la touche ALT (configurable, bien sûr) pendant un clic droit pour redimensionner, ou avec un clic gauche pour déplacer, même au milieu de la fenêtre.