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.
Je suis intrigué.
Tout le monde ici semble considérer l'isoloir comme étant respectueux de la vie privée… mais avec les techniques modernes de miniaturisation et de capture d'ondes, notamment, serait-il impensable d'imaginer qu'une camera puisse être installée dans un isoloir?
Ou qu'un dispositif capable de suivre le mouvement via je ne sais quel type de rayons qui puissent passer au travers du rideau? Je veux bien admettre qu'il soit difficile de modifier le vote, mais de le surveiller? Je n'en suis pas si sûr, même si évidemment cela implique de compromettre le lieu de vote (ceci dit, vue la mairie dans laquelle j'ai jusqu'ici toujours voté, ça ne serait pas particulièrement complexe, par exemple l'isoloir n'est pas hermétique à la vision normale par le haut).
PS: tu vas te faire qualifier de sexiste, à dire (tu ne l'as pas dis, mais tu l'as implicitement volontairement sous-entendu) que les femmes sont des victimes faciles pour les violence conjugales! :)
Hé bien c'est pareil. Si tu es dans un isoloir avec une caméra, dissimulée ou non, à ton insu ou non, tu fais ce que tu veux, mais on peut vérifier.
Un ordinateur, c'est la même chose. Si le système n'est pas dépourvu de dispositif d'espionnage, tu fais ce que tu veux (quoique, c'est vrai, on peut modifier au vol…) mais on peut vérifier.
En fait, que ce soit l'isoloir ou l'ordinateur, le seul problème de ce côté, c'est d'être en mesure de vérifier l'absence de dispositif (surtout compte tenu de la technologie actuelle, ou les cameras peuvent être logées à peu près n'importe ou, et les OCR sont capable de déchiffrer des écrits de plus en plus brouillés) pouvant fausser le secret du vote, et donc bien entendu, de dispositif pouvant modifier le vote.
Très honnêtement, les systèmes d'exploitation modernes qui équipent nos machines généralistes sont tellement complexes que c'est impossible, pour moi. Un dispositif électronique constitué uniquement d'un écran LCD et quelques boutons (de quoi saisir la preuve d'identité et le choix) avec un code source strictement minimal serait au moins vérifiable par un humain seul (disposant de connaissances techniques adéquates, bien sûr) contrairement à un OS complet dont rien que la lecture du code source du noyau nécessiterais plusieurs jours.
Bien sûr, il faut ensuite envoyer les données au dispositif suivant… qui sera sûrement connecté à internet.
Pour moi, le véritable problème du vote, électronique ou pas, c'est qu'il faut être en mesure de s'assurer de l'intégrité de l'ensemble du système. Ce qui inclue bien sûr le dispositif ou l'on renseigne notre choix, mais aussi celui qui achemine ce choix et, naturellement, celui qui compte ce choix.
Hors, le vote électronique se compose d'une part de la machine ou l'on renseigne le choix, mais aussi de l'ensemble des dispositifs qui l'acheminent, serveurs DNS, routeurs, etc… sans oublier bien sûr le système qui décompte.
Mais c'est pareil pour un vote papier: quand on fait une procuration, il faut avoir confiance dans le dispositif qui va voter et acheminer le choix. Que celui-ci soit humain ou électronique ne change rien. Quoique, l'électronique, au moins, on peut en vérifier l'intégrité, en théorie. Pour un humain, pas vraiment, ou alors j'ai manqué des études sur la lecture mentale.
Moralité de l'histoire, faut que j'oubli mes réflexes WIndows mais c'est très très très très difficile.
Me concernant, il a fallu que ma machine performante me lâche à une époque ou je n'étais pas fortuné, pour que je passe à debian au quotidien.
Depuis, je me suis repayé du matos, mais je suis incapable de repasser à windows… son environnement graphique est vraiment trop peu souple pour moi.
Bon, je ne répond pas que pour dire ça, je voulais aussi et surtout dire, le problème de "linux", ou plutôt des systèmes libres, c'est qu'il y a "trop" de choix.
Choisir intelligemment (en fonction de nos besoins réels, et pas des besoins supposés), on y est clairement pas habitué, et c'est pourquoi on galère quand on passe à un système non basé sur kernel.dll ou je-ne-sais-le-kernel-de-mac-os.
Il n'y a aucun outil sur ces systèmes pour apprendre à choisir, contrairement à certaines distributions linux qui intègrent des outils permettant de choisir les logiciels en fonction du ou des rôles des-dits logiciels.
Pour ma part, sous windows je suis toujours resté avec le simple et efficace "thème" de windows 9x, sous linux ça s'est traduit par une première adoption de XFCE4.8 (qui est d'ailleurs bien supérieur en terme d'ergonomie au thème w9x). Et comme je suis un bricoleur, j'en suis rapidement (moins de 2 ans) arrivé à bâtir mon propre écosystème logiciel, grâce au gestionnaire de paquets aptitude, en mode pseudo-graphique (ou ncurses), qui, selon moi, est supérieur aux outils en ligne de commande car il permet l'exploration interactive, tout en étant supérieur aux outils purement graphiques grâce au fait d'être aussi exhaustif qu'un outil en ligne de commande pur.
Ma moralité de l'histoire, c'est qu'il ne faut pas oublier ses réflexes, mais les améliorer, PROGRESSIVEMENT. Peu importent les zélotes qui diront de faire le grand saut…
Repartir de 0 est souvent un échec assuré :) (je suis passé du windows 9x avec uniquement des outils windows à un windows XP avec un fort taux d'outils portables puis aux DEs monolithiques de linux, puis à la création d'un système sur-mesure, mais toutes les étapes m'ont été nécessaires, surtout que je ne connaissais personne physiquement capable de m'épauler).
[^] # 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.
[^] # Re: N'oublions pas la contrainte
Posté par freem . En réponse au journal Helios, un logiciel libre de vote électronique. Évalué à 2.
Peut-être pas monnaie courante, mais ça à existé et ça existe probablement encore. Je t'encourage à te renseigner sur le terme parti unique.
[^] # Re: Standards
Posté par freem . En réponse à la dépêche FLIF, un format d’image sans perte, intelligent et « performant », sous licence GPL. Évalué à 6.
D'un autre côté, pour les gens connaissant xkcd, voir un lien vers xkcd sur un tel sujet ne laisse aucun doute quant à l'image liée.
Mais l'argument est valide quand même.
[^] # Re: N'oublions pas la contrainte
Posté par freem . En réponse au journal Helios, un logiciel libre de vote électronique. Évalué à 4.
Je suis intrigué.
Tout le monde ici semble considérer l'isoloir comme étant respectueux de la vie privée… mais avec les techniques modernes de miniaturisation et de capture d'ondes, notamment, serait-il impensable d'imaginer qu'une camera puisse être installée dans un isoloir?
Ou qu'un dispositif capable de suivre le mouvement via je ne sais quel type de rayons qui puissent passer au travers du rideau? Je veux bien admettre qu'il soit difficile de modifier le vote, mais de le surveiller? Je n'en suis pas si sûr, même si évidemment cela implique de compromettre le lieu de vote (ceci dit, vue la mairie dans laquelle j'ai jusqu'ici toujours voté, ça ne serait pas particulièrement complexe, par exemple l'isoloir n'est pas hermétique à la vision normale par le haut).
PS: tu vas te faire qualifier de sexiste, à dire (tu ne l'as pas dis, mais tu l'as implicitement volontairement sous-entendu) que les femmes sont des victimes faciles pour les violence conjugales! :)
[^] # Re: petit mélange?
Posté par freem . En réponse au journal Helios, un logiciel libre de vote électronique. Évalué à -1.
Hé bien c'est pareil. Si tu es dans un isoloir avec une caméra, dissimulée ou non, à ton insu ou non, tu fais ce que tu veux, mais on peut vérifier.
Un ordinateur, c'est la même chose. Si le système n'est pas dépourvu de dispositif d'espionnage, tu fais ce que tu veux (quoique, c'est vrai, on peut modifier au vol…) mais on peut vérifier.
En fait, que ce soit l'isoloir ou l'ordinateur, le seul problème de ce côté, c'est d'être en mesure de vérifier l'absence de dispositif (surtout compte tenu de la technologie actuelle, ou les cameras peuvent être logées à peu près n'importe ou, et les OCR sont capable de déchiffrer des écrits de plus en plus brouillés) pouvant fausser le secret du vote, et donc bien entendu, de dispositif pouvant modifier le vote.
Très honnêtement, les systèmes d'exploitation modernes qui équipent nos machines généralistes sont tellement complexes que c'est impossible, pour moi. Un dispositif électronique constitué uniquement d'un écran LCD et quelques boutons (de quoi saisir la preuve d'identité et le choix) avec un code source strictement minimal serait au moins vérifiable par un humain seul (disposant de connaissances techniques adéquates, bien sûr) contrairement à un OS complet dont rien que la lecture du code source du noyau nécessiterais plusieurs jours.
Bien sûr, il faut ensuite envoyer les données au dispositif suivant… qui sera sûrement connecté à internet.
Pour moi, le véritable problème du vote, électronique ou pas, c'est qu'il faut être en mesure de s'assurer de l'intégrité de l'ensemble du système. Ce qui inclue bien sûr le dispositif ou l'on renseigne notre choix, mais aussi celui qui achemine ce choix et, naturellement, celui qui compte ce choix.
Hors, le vote électronique se compose d'une part de la machine ou l'on renseigne le choix, mais aussi de l'ensemble des dispositifs qui l'acheminent, serveurs DNS, routeurs, etc… sans oublier bien sûr le système qui décompte.
Mais c'est pareil pour un vote papier: quand on fait une procuration, il faut avoir confiance dans le dispositif qui va voter et acheminer le choix. Que celui-ci soit humain ou électronique ne change rien. Quoique, l'électronique, au moins, on peut en vérifier l'intégrité, en théorie. Pour un humain, pas vraiment, ou alors j'ai manqué des études sur la lecture mentale.
[^] # Re: ca ne sert a rien
Posté par freem . En réponse au message Fonctionnalité -> Fichiers récents. Évalué à 3.
Me concernant, il a fallu que ma machine performante me lâche à une époque ou je n'étais pas fortuné, pour que je passe à debian au quotidien.
Depuis, je me suis repayé du matos, mais je suis incapable de repasser à windows… son environnement graphique est vraiment trop peu souple pour moi.
Bon, je ne répond pas que pour dire ça, je voulais aussi et surtout dire, le problème de "linux", ou plutôt des systèmes libres, c'est qu'il y a "trop" de choix.
Choisir intelligemment (en fonction de nos besoins réels, et pas des besoins supposés), on y est clairement pas habitué, et c'est pourquoi on galère quand on passe à un système non basé sur kernel.dll ou je-ne-sais-le-kernel-de-mac-os.
Il n'y a aucun outil sur ces systèmes pour apprendre à choisir, contrairement à certaines distributions linux qui intègrent des outils permettant de choisir les logiciels en fonction du ou des rôles des-dits logiciels.
Pour ma part, sous windows je suis toujours resté avec le simple et efficace "thème" de windows 9x, sous linux ça s'est traduit par une première adoption de XFCE4.8 (qui est d'ailleurs bien supérieur en terme d'ergonomie au thème w9x). Et comme je suis un bricoleur, j'en suis rapidement (moins de 2 ans) arrivé à bâtir mon propre écosystème logiciel, grâce au gestionnaire de paquets aptitude, en mode pseudo-graphique (ou ncurses), qui, selon moi, est supérieur aux outils en ligne de commande car il permet l'exploration interactive, tout en étant supérieur aux outils purement graphiques grâce au fait d'être aussi exhaustif qu'un outil en ligne de commande pur.
Ma moralité de l'histoire, c'est qu'il ne faut pas oublier ses réflexes, mais les améliorer, PROGRESSIVEMENT. Peu importent les zélotes qui diront de faire le grand saut…
Repartir de 0 est souvent un échec assuré :) (je suis passé du windows 9x avec uniquement des outils windows à un windows XP avec un fort taux d'outils portables puis aux DEs monolithiques de linux, puis à la création d'un système sur-mesure, mais toutes les étapes m'ont été nécessaires, surtout que je ne connaissais personne physiquement capable de m'épauler).