freem a écrit 4951 commentaires

Seulement, il existe très peu de paramètres réglables en interface graphique et à peine plus via les fichiers de configuration.

Ça semble être intentionnel, selon leur page. Même pas une indication de où ils ont collée la base de données, c'est un poil abusé quand même…

J'aurais aimé savoir si l'indexation était déconseillée sur un SSD

Ce qui est… ou peut-être était (je ne sais pas si c'est encore d'actualité)… néfaste pour un SSD ce sont les écritures.
Donc, si tu ne passes pas ton temps à déplacer tes fichiers logiquement il ne devrait pas y avoir trop d'écritures, et donc pas de problème de ce côté.

et s'il était possible de modifier l'emplacement de sauvegarde de la base de données. Merci.

Flemme d'aller lire le source, d'autant qu'après un rapide regard sur le git je ne comprend pas l'arborescence, donc je ne peux pas te dire si c'est possible de manière standard (et franchement, pas envie d'aller jusqu'a cloner pour juste faire un grep sur les options de config, d'autant que je n'utilise pas KDE).

Maintenant, si tu arrives à localiser la base de données, tu peux toujours:

1. couper le daemon baloo
2. déplacer la base de données ou tu veux
3. faire un lien entre le nouvel emplacement de la BDD et l'ancien (où baloo s'attendrai à la trouver, donc)
4. relancer le daemon

C'est du bricolage, c'est sûr, mais ça devrais fonctionner le temps de trouver plus propre.
Bon courage.

une calculatrice qui calcule les arrangements et combinaisons et s’utilise au clavier, c’est pas mal.

Elle s'utilise et au clavier, et à la souris. C'est généralement cette combinaison qui me fait considérer une application comme efficace.

Pour quitter bc, Ctrl-D suffit.

Ctrl-D… sérieux… D comme destruction? Parce que je n'aurais jamais eu à l'esprit d'utiliser ça…
Enfin, merci du tuyau aussi, je m'en souviendrai, pour le jour ou je n'aurai pas d'accès à un environnement graphique (j'aime savoir utiliser la ligne de commande. Rapide, efficace, et surtout: fiable. X11, c'est cool et joli, mais pas toujours fiable, et rarement efficace amha. Enfin, sauf pour afficher quelques urxvc, bien sûr).

Est-ce le système entier qui freeze, ou juste Xorg?

Vu que les installations se font en général jusqu'a la fin, de ce que j'ai compris, je pencherais plus pour Xorg (et donc la carte graphique, potentiellement) que pour le système complet.

Pour vérifier, je vois 3 solutions, de la plus pratique à la plus douteuse:

• utiliser une connexion ssh provenant d'une machine externe. Habituellement, ssh-server est installé sur les Debian (en fonction des options que tu as sélectionnées lors de l'installation) et j'imagine donc que c'est la même chose pour ses filles (*buntu, mint, etc).
• ne pas lancer Xorg. Voire ne pas l'installer. Pour utiliser le système, utiliser bash + nano/vim(vimtutor t'apprendras les bases si nécessaire)/emacs(si tu as assez de doigts) + links + mpc/mpd/ncmpcpp (pour la musique ;)). Au navigateur près, c'est ce que j'utilise y compris avec Xorg perso ;)
• essayer de passer sur une TTY lors d'un freeze, via CTRL+ALT+Fx, x étant compris entre 1 et 12, sachant que sur une Debian jessie le comportement à ce sujet est complètement ~pété~ modifié, et sur mon système ça semble être entre 2 et 6, Xorg remplaçant le TTY depuis lequel je le lance (ce qui est très, très pénible, mais bon, c'est la mode… à ma charge de ramener le système à un comportement moins imprévisible un de ces jours sigh).

Apprendre à se démerder via les TTYs pourra aussi te servir, un jour… j'ai déjà réanimé quelques systèmes après des mises à jour du pilote graphique, de cette manière.
Ho, et pour un système de gestion des paquets avec interface ncurses (donc qui ne nécessite pas de connaître la liste des paquets ou des commandes par cœur) tu peux utiliser aptitude. Sans arguments après la commande, il se lance en mode semi-graphique, qui est vraiment extrêmement pratique: j'aime les lignes de commandes pour gérer mes fichiers, mais pas au point de vouloir gérer tout mon système à coups de apt…

Je pense qu'il parle d'utiliser l'interface graphique, pas d'aller bidouiller dans la conf' à coup de vim (ou emacs, s'il a assez de mains).

Par stable, je n'entendais pas sans MAJ, mais sans bug.

Le truc de Debian en fait, c'est que la version stable à des mises à jour, mais uniquement de sécurité, pas de nouvelles fonctionnalités ajoutées.
Pas de nouvelles fonctionnalités, ça implique aussi pas de nouveaux bugs… donc les MaJ de Debian stable sont très agréables pour qui ne veux pas se prendre la tête.

D'ailleurs, le passage que tu cites l'indiques bien:

Debian sera pas buggé au niveau des logiciels, en tout cas je ne suis pas plus embeté que sous opensuse et mageia, par contre finition, c'est du boulot en plus

Ce qu'il reproche, c'est que Debian ne soigne pas le côté graphique. Par contre il dis bien, en terme de logiciels, par de souci, ça roule, c'est stable et fiable.

À noter tout de même. Debian stable intègre des backports, autrement dit des logiciels plus récents (que leurs versions de la stable) qui sont installables malgré tout. Il existe aussi un dépôt pour les logiciels type firefox qui ont la bougeotte, il me semble.
Et enfin, pas mal d'utilisateurs ont tendance à utiliser Debian testing, ou unstable, et pour les plus fous d'entre nous (j'en fais partie :)) un mélange d'un peu tout ça en fonction de l'humeur.
Je ne te conseillerais pas Debian unstable si tu trouves Ubuntu trop buggué, par contre, si stable+backports est encore trop vieux pour toi, testing pourrais te convenir (je ne le recommanderai pas pour un serveur, par contre, on est d'accord que l'on parle bien d'une machine non critique! Sur un serveur, je partirai soit sur une stable pure, soit sur une unstable, en fonction de son rôle et de la personne qui administre…)

Je ne sais pas ce qu'est le 4k, mais, sur un écran d'il y à 15 ans (ça va, ça remonte assez?) on avais régulièrement des résolutions de type 1024*768, en 32 bits (soit 4 octets par pixel).
Dans les 32 bits, 8 (1 octet) sont utilisés pour la transparence, aucun intérêt dans le cas d'un affichage déporté. Donc, on peut se baser sur 3 octets par pixel.
Partons de 30 FPS, soit 30 images par seconde.
30* 3* (768*1024) = 70778880 octets par seconde. Pour avoir un truc plus lisible, on divise par 1024 deux fois (pour avoir d'abord en Kio, puis en Mio, qui sont plus parlants):

70778880 / 1024 / 1024 = 69120 / 1024 = 67,5 Mio. Pour une seule instance à une résolution qui était régulièrement employée il y à 15 ans (mais pas la meilleure de l'époque, loin de là) à une vitesse médiocre (particulièrement pour un FPS) il te faudrait donc un réseau capable de supporter 67.5Mo/s par client (instance de jeu).

Je te laisse refaire le calcul avec un framerate décent (45 FPS minimum) et une résolution potable (disons 1440*900, c'est pas nickel, mais décent…), tu verras que ce n'est pas gérable, particulièrement si tu passes par du WI-FI (ou il faut prendre en compte les nombreuses pertes réseau) sans même parler du fait que le serveur devra être très costaud.
Multiplies ensuite par le nombre de joueurs dans ton LAN…

Connexion a distance par VNC, oui mais il y a pas d'autre moyens? Comme par http ?(je m'y connais pas du tout la dedans)

Les logiciels comme VNC utilisent des protocoles (un "langage privé" qui permets la communication entre plusieurs logiciels) spécialisés dans le déport d'affichage.
La plupart des formats et protocoles qui traitent avec l'audio-visuel tendent à perdre des données, afin de faciliter les calculs. Les autres, ceux qui ne perdent pas de données, sont nettement plus gourmands en terme de CPU et de RAM, au minimum (je ne sais pas à 100% si ceux-ci sont d'efficacité identique à ceux impliquant une perte de données, en terme de bande-passante (aka: taille des données) mais à CPU/RAM identique, j'en serai extrêmement surpris).

HTTP est un protocole spécialisé, à l'origine, dans la transmission de fichiers en conservant (et en transmettant) des méta-données à leur sujet (par exemple, si c'est une image, une musique, un texte, un programme…).
Étant spécialisé dans le transfert de fichiers, il y à plusieurs limites. L'une d'entre elle est l'absence d'authentification et de chiffrement. Pour l'authentification, les sites web utilisent un contournement: les cookies. C'est du bricolage, et il y à régulièrement des problèmes de sécurité avec ça.
Pour le chiffrement, ça à été résolu avec le HTTPS. Je ne connais pas assez le fonctionnement des techniques de chiffrement pour essayer d'expliquer ça à un néophyte, mais le chiffrement implique également du temps de calcul pour que les données ne soient pas transmises en clair.

De plus, la compression est généralement plus performante quand les données se répètent suivant le même modèle régulièrement. Ce n'est plus trop le cas dans les jeux modernes, toujours plus réalistes, sans parler des effets de lumière et d'ombres.

Il n'y aurait pas moyen de "compressé les données" de manière a réduire le débit …?

La plupart des algorithmes de compression audio-visuels "perdent" des données. Les autres sont gourmands en terme de calcul.

À noter que quand je parle de temps de calcul, c'est du temps qui est dépensé des deux côté du réseau.

Au final, ce serait faisable, mais pas avec des jeux rapides. Un jeu en tour par tour? Oui, sans problème. Un jeu de stratégie, pourquoi pas, avec des graphismes au minimum probablement, par contre un FPS c'est mort.

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

• http://www.opengl-tutorial.org/
• http://ogldev.atspace.co.uk/
• http://mbsoftworks.sk/index.php?page=tutorials&series=1
• https://en.wikibooks.org/wiki/OpenGL_Programming

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.

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 :

AUDIO_OUT_DEV=/dev/XXX AUDIO_IN_DEV=/dev/YYY application

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

en doublon de la jauge de l'application elle-même

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?

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

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

S'il existe un outil en ligne de commande pour piloter PA (style le amixer de alsa) alors tu peux simplement passer par ssh.