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).
Ce n'est pas parce que ta box à une IP donnée qui semble fixe, qu'elle (l'IP) l'est.
Je me souviens de quand je-ne-sais-plus-quel-site-de-streaming-n'était-pas-interdit-par-le-FBI, le site en question limitait la quantité de donnée téléchargées par IP, et il suffisait de redémarrer la box de chez mes parents… (oui, ça date…)
Hors, ça, tu ne peux le savoir que via ton contrat avec ton FAI. Si tu as une IP dynamique, alors il te faudra passer par un service type DynDNS (bon celui-la c'est une marque, et il n'est plus gratuit, mais il doit en exister d'autres, tout dépend de ton besoin.)
En même temps c'est pas nouveau, et c'est une volonté affichée depuis… plusieurs années.
Oui, Debian essaie de faire des sorties régulières, pour réguler un de ses inconvénients (logiciels dans la version stable anciens, ce qui n'est pas toujours un inconvénient réel d'ailleurs, m'enfin…).
D'ailleurs, je constate que selon l'article que j'ai cité, je suis passé à Debian (et Linux de manière générale) au quotidien depuis à peu près 5 ans…. que le temps passe vite! Et combien j'ai appris en si peu de temps! Je comprend mieux du coup mes envies d'aller changer de kernel :) (toujours plus geek, toujours moins mainstream, je finirai par passer à l'un des *BSD, j'en suis sûr!)
Désolé, suis pas fan des téléphones… le mien sert de téléphone, d'agenda (plus ou moins) et de télégraphe (je pense que les SMS sont assez proches de ce truc au final non?) et basta. Il faut vraiment que je sois désespéré pour me servir de sa … hum… calculette intégrée…
Du coup je préfère installer un soft de calcul potable sur mon PC, plus simple, je connais le clavier par coeur et il à plus de touches que n'importe quelle calto. Bref, c'est mieux pour mon besoin.
Avant, j'utilisais galculator, mais depuis qu'ils sont passé à gtk3, j'ai constaté une importante augmentation des dépendances débiles (sisi, débiles, je ne vois pas pourquoi je devrais installer un thème graphique imposé à cause d'une dépendance en dur dans Debian) sans parler du fait qu'il dépend de plus en plus des machins gnome (n'utilisant pas de DE monolithique, je refuse d'installer les applications liées à ces trucs trop statiquement, ma machine n'est pas puissante, tout en l'étant largement assez pour ce que j'en fait. Je vais pas acheter une machine pour avoir des coins arrondis et de la transparence sur une appli alors que j'utilise un twm!) et du coup j'ai cherché une alternative. Le meilleur soft que j'ai trouvé est crunchbang (dépend de Qt, 4 de mémoire), qui à bien y réfléchir est bien plus puissant et mieux fichu que galculator.
Côté usage, je m'en sert pour les calculs, principalement liés à la programmation, bien que pour les conversions de base (de la base 2 à la base 36, même si j'ai jamais utilisé autre chose que 2, 8, 10 et 16 ;)), j'aie fini par coder mon propre utilitaire en ligne de commande en C++ ( dont je n'ai pas diffusé le code, je doute qu'il apporte quoique ce soit de réel à ce qui existe déjà… m'enfin, le jour ou j'aurai un vrai projet à diffuser je ferai sûrement une section pour les gadgets que j'ai codé vite fait… ), gadget qui à l'avantage à mes yeux d'être facile à hacker et à utiliser (compte tenu du fait que mon explorateur de fichiers, c'est un terminal).
Je suspecte ton code d'être faux, la commande wc ne passe pas 6 mois chez le psychanalyste avant de savoir comment ouvrir le fichier que tu lui donnes.
Je ne sais pas, j'ai pas embauché de détective privé pour la filer. Blague à part, je n'ai pas été lire son code, je devrais peut-être, mais je trouve le code gnu en général pas trop lisible (mention spéciale pour la libstdc++ d'ailleurs, ou les tabs et espaces sont mélangés dans un joyeux foutoir).
Ensuite puisque tu programmes en C++, pourquoi est-ce que tu n'utilises les possibilités du C++ au lieu de traîner des FILE* et des buffers de taille fixe… c'est du masochisme.
Je suis peut-être masochiste, mais je trouve aussi le code à base de FILE* plus lisible que les fstream. Ceci étant dit, tu as raison, j'aurai du tester avec ifstream, cela fonctionne sans buffer fixe.
Je n’avais pas tilté que le fichier était virtuel…
Sinon j'aurai utilisé le classique combo fseek/ftell/fseek :)
La fonction read renvoie le nombre d’octets réellement lus. En définissant un grand buffer ça devrait marcher. En plus, comme Linux n’alloue les pages que quand elles sont utilisées, on peut allouer 1M sans avoir peur.
Ça, ça dépend de la configuration du kernel si je ne dis pas de conneries (/proc/sys/overcommit_memory).
Personnellement, je trouve que c'est plus une gêne qu'une fonctionnalité: l'overcommit fait qu'on ne peut pas faire confiance au système quant au fait que les ressources qu'il nous à confiées sont réellement utilisables.
Je ne vais pas m'étendre la-dessus, mais je préfère éviter de me fier à ce type de mécanisme, et ce, particulièrement pour les applications que je fais pour ma pomme (si le chef me demande de faire le goret après tout, ainsi soit-il, hein, mais j'essaierai quand même d'éviter).
Enfin, certes, 1M, ce n'est pas grand chose, et c'est vrai que ta méthode marche, surtout qu'il suffit de faire d'abord une allocation de bourrin pour récupérer la véritable taille puis ajuster. Je n'y avais pas pensé je le reconnais.
M'enfin, dommage tout de même de ne pas avoir un mécanisme plus efficace (alloc, read, free, alloc, free, 5 appels système, pour quelque chose qui devrait pouvoir se faire plus facilement je pense, et si on doit faire ça de façon répétitive pour les 35K fichiers la fragmentation mémoire risque d'être conséquente à force).
Je ne sais pas pour les mac, mais les IBM/PC (oui, parce que les macs aussi, ce sont des personal computers quoiqu'en disent leurs utilisateurs…) ont depuis toujours des astuces pour réinitialiser les BIOS.
Depuis quelques années (+10 ans quand même) sur mes tours, il y à un cavalier (ou jumper, une petite pièce mobile qui sert d'interrupteur) qui permets de réinitialiser le BIOS. Il est généralement situé près de la pile, mais son emplacement dépend de la carte mère.
J'ai aussi entendu des tonnes d'histoires (légendes, racontars? Aucune idée, je n'ai jamais vérifié sérieusement… mais bon je serai très surpris que ça marche aussi facilement) décrivant des manipulations du style, débrancher toute l'alim du PC, retirer la pile, etc etc.
Ça n'aide pas beaucoup j'imagine… un forum spécialisé mac te serait probablement plus utile sur ce coup je pense.
[edit]
À noter que les vidéos que tu indiques sont très récentes, peu surprenant du coup que ça ne fonctionne pas sur une machine qui doit dater à peu près de 2003-2005 vue la quantité de RAM disponible
Il semble que ma question ne soit pas assez claire (ce qu'en fait je comprend, c'est juste un bloc de texte… mea culpa!), donc voici quelques précisions/reformulations.
Je cherche à savoir s'il est possible de connaître la taille des éléments de /proc par programmation C (C++ en fait, mais l'accès à ces ressources se fait de la même façon de toute manière).
À l'heure actuelle, mon code (qui fonctionne) procède en allouant à la compilation un buffer de taille fixe (je vous ai menti en plus, vue la constante je n'ai même pas utilisé la taille exacte de /proc/meminfo…) déterminé de façon empirique pour pouvoir tout contenir.
L'inconvénient de cette façon de faire est que si un jour je veux accéder à d'autres informations de /proc (ou soyons fous, de /sys?) il me faudra alors effectuer la mesure manuellement afin de déterminer la taille à allouer au buffer sur lequel je vais travailler.
Pire, si je serre de trop près la taille réelle du fichier, un jour ça pètera et on ne pourra savoir pourquoi qu'en regardant dans le code (même si pour le moment il n'y a que 200LoC, rien ne prouve que ça restera trivial dans le temps). Et si on voulait changer de système cible (genre, pour aller sur du BSD), idem, gros risque que ça casse (ok, les noms des variables diffèrent certainement de toute façon, mais devoir ajuster des textes à la main me suffit, pourquoi y ajouter des tailles de buffer?)
La solution évidente est de lire progressivement le fichier. J'ai testé, ça ne marche pas (franchement, ça m'a valu pas mal d'incompréhension, je n'ai pas toujours l'esprit très rapide et je ne me suis résolu qu'a contre-cœur d'utiliser la même méthode que le source de xosview), la raison semblant être que dans le cas de ces pseudos-fichiers, aucune information de position du curseur n'est stockée (ou mise à jour, pour ce que ça change).
1) Pour connaître la taille d’un fichier utile fstat ou stat si le fichier n’est pas ouvert. Le champ st_size devrait faire ton bonheur.
En temps normal, j'aurai utilisé ls -l, mais en l'occurrence, il ne s'agit pas d'un vrai fichier, les méthodes traditionnelles ne fonctionnent donc pas.
Je ne connaissais cependant pas ces commandes. fstat n'est pas installé sur mon système, et statrenvoie 0 pour /proc/meminfo.
2) Si ton but est de charger le fichier en mémoire pour l’étudier : man mmap pourra te simplifier la vie.
Je viens de lire très brièvement le man de mmap. Je ne suis pas sûr d'en voir l'intérêt, sauf pour écrire un chargeur de binaire d'un format différent de ELF, ou écrire un programme métamorphe.
3) Si ton but est de chercher certains champs, autant ouvrir le fichier et le lire ligne par ligne : man getline
J'ai essayé de lire ligne par ligne, mais la encore, la nature virtuelle du fichier fait que ce n'est pas possible, il faut le lire d'un bloc sinon les instructions ne retournent tout le temps que le début du fichier (qui, en fait, n'est pas un fichier, et du coup FILE* ne contiens pas d'information de positionnement, à ce que j'ai compris).
Parce que ce n'est pas un vrai fichier. En fait, ce que tu décris est la première approche que j'ai utilisée: une bonne vieille while( !feof( f ) ). Sauf que ça marche pas, /proc étant en fait, je l'ai découvert à mes dépends (l'expérience aura été utile au moins), un peu comme un accès à une partie de la mémoire du kernel accessible en read-only (et peut-être rw pour certaines parties, je ne connais pas assez).
Du coup, FILE* ne mets pas à jour l'information de position. Conséquence, on lis en permanence la même ligne.
C'est vrai que je pourrai prendre la taille maximum actuelle du fichier.
Le problème étant, dans ce cas, que j'ai toujours un truc hardcodé, dédié à une une partie particulière d'un système particulier.
Si un jour je veux évoluer le programme pour accéder à d'autres informations, je devrais refaire la même recherche de la taille maximale d'un autre fichier… bof bof.
Non pas que je m'attende à ce que tous les systèmes nomment leurs "fichiers"/variables de la même façon bien sûr, voire même je doute qu'il soit possible d'accéder à ces informations via un simple fopen (en fait je sais que c'est impossible, l'OS de microsoft n'exposant pas son interface de cette façon, mais m'en cogne de celui-la)… mais je trouve du coup que c'est quand même dommage de devoir utiliser une valeur au pifomètre pour tenter de récupérer toutes les informations.
Même si mon patch à i3status ne fait que +/- 80 LoC, je trouve ça dommage de mettre des choses en dur dedans (autrement dit, définies à la main, peu importe si c'est au travers d'une constante ou de valeurs numériques, le résultat est le même au final).
Il me reste toujours la piste de mmap() suggérée plus haut. J'y répondrai quand j'aurai fini de lire le man et quand j'aurai vérifié que c'est utilisable (ou pas, je le préciserai dans ce cas).
Tu m'as mal compris: j'utilise wc pour déterminer la taille de ce fichier, afin d'allouer, dans un programme (C++ en l'occurrence) la taille du buffer que je dois utiliser pour lire ce fichier (et ensuite traiter les informations qui m'intéressent).
Même mon client MPC semble avoir une influence sur le volume général, quand j'incrémente/décrémente le volume de mon MPD, ça incrémente/décrémente le volume général o_Ô
Ce n'est pas le client qui pose problème, mais la configuration du daemon, en tout cas sous Debian.
Je ne pourrais pas te dire la config par défaut, mais voici la section de la mienne qui t'intéressera:
audio_output {
type "alsa"
name "My ALSA Device" # oui bon jusque là c'est les valeurs par défaut hein
mixer_type "software" # ici, me semble que par défaut, c'était hardware... donc contrôler direct le chipset sonore, forcément ça contrôle tout le reste ;)
} # et la, il y a aussi des options qui ont sauté, du genre 3-4 lignes à l'utilité douteuse même selon Debian: "# optional"
Bref, il suffit de lire le fichier de conf et ce problème se règle tout seul. Ou aller lire le manuel, je pense que ce genre de choses doivent y être expliquées, mais moi je lis toujours les conf avant les manuels :p
Après, pour PA, j'en sais rien, perso quand je vois un truc qui en dépend, je l'installe pas. Et le seul problème de son que j'ai c'est avec mumble (le micro refuse d'y fonctionner sur une machine, alors qu'il marche très bien quand j'active l'écho sous alsamixer et que sur une autre machine mumble marche, sans PA dans les 2 cas… j'y pige que dalle perso)
[^] # 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).
[^] # Re: Configuration routeur
Posté par freem . En réponse au message Connexion SSH J'ai du rater une étape ???. Évalué à 4.
Hum, petit détail.
Ce n'est pas parce que ta box à une IP donnée qui semble fixe, qu'elle (l'IP) l'est.
Je me souviens de quand je-ne-sais-plus-quel-site-de-streaming-n'était-pas-interdit-par-le-FBI, le site en question limitait la quantité de donnée téléchargées par IP, et il suffisait de redémarrer la box de chez mes parents… (oui, ça date…)
Hors, ça, tu ne peux le savoir que via ton contrat avec ton FAI. Si tu as une IP dynamique, alors il te faudra passer par un service type DynDNS (bon celui-la c'est une marque, et il n'est plus gratuit, mais il doit en exister d'autres, tout dépend de ton besoin.)
[^] # Re: "Normal" :)
Posté par freem . En réponse au journal freeze Debian 9 pour fin 2016. Évalué à 2.
En même temps c'est pas nouveau, et c'est une volonté affichée depuis… plusieurs années.
Oui, Debian essaie de faire des sorties régulières, pour réguler un de ses inconvénients (logiciels dans la version stable anciens, ce qui n'est pas toujours un inconvénient réel d'ailleurs, m'enfin…).
D'ailleurs, je constate que selon l'article que j'ai cité, je suis passé à Debian (et Linux de manière générale) au quotidien depuis à peu près 5 ans…. que le temps passe vite! Et combien j'ai appris en si peu de temps! Je comprend mieux du coup mes envies d'aller changer de kernel :) (toujours plus geek, toujours moins mainstream, je finirai par passer à l'un des *BSD, j'en suis sûr!)
# crunchbang
Posté par freem . En réponse au journal Calculatrice : matériel et logiciel ouverts ?. Évalué à 3.
Désolé, suis pas fan des téléphones… le mien sert de téléphone, d'agenda (plus ou moins) et de télégraphe (je pense que les SMS sont assez proches de ce truc au final non?) et basta. Il faut vraiment que je sois désespéré pour me servir de sa … hum… calculette intégrée…
Du coup je préfère installer un soft de calcul potable sur mon PC, plus simple, je connais le clavier par coeur et il à plus de touches que n'importe quelle calto. Bref, c'est mieux pour mon besoin.
Avant, j'utilisais galculator, mais depuis qu'ils sont passé à gtk3, j'ai constaté une importante augmentation des dépendances débiles (sisi, débiles, je ne vois pas pourquoi je devrais installer un thème graphique imposé à cause d'une dépendance en dur dans Debian) sans parler du fait qu'il dépend de plus en plus des machins gnome (n'utilisant pas de DE monolithique, je refuse d'installer les applications liées à ces trucs trop statiquement, ma machine n'est pas puissante, tout en l'étant largement assez pour ce que j'en fait. Je vais pas acheter une machine pour avoir des coins arrondis et de la transparence sur une appli alors que j'utilise un twm!) et du coup j'ai cherché une alternative. Le meilleur soft que j'ai trouvé est crunchbang (dépend de Qt, 4 de mémoire), qui à bien y réfléchir est bien plus puissant et mieux fichu que galculator.
Côté usage, je m'en sert pour les calculs, principalement liés à la programmation, bien que pour les conversions de base (de la base 2 à la base 36, même si j'ai jamais utilisé autre chose que 2, 8, 10 et 16 ;)), j'aie fini par coder mon propre utilitaire en ligne de commande en C++ ( dont je n'ai pas diffusé le code, je doute qu'il apporte quoique ce soit de réel à ce qui existe déjà… m'enfin, le jour ou j'aurai un vrai projet à diffuser je ferai sûrement une section pour les gadgets que j'ai codé vite fait… ), gadget qui à l'avantage à mes yeux d'être facile à hacker et à utiliser (compte tenu du fait que mon explorateur de fichiers, c'est un terminal).
[^] # Re: rassures moi vite
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2.
Je ne sais pas, j'ai pas embauché de détective privé pour la filer. Blague à part, je n'ai pas été lire son code, je devrais peut-être, mais je trouve le code gnu en général pas trop lisible (mention spéciale pour la libstdc++ d'ailleurs, ou les tabs et espaces sont mélangés dans un joyeux foutoir).
Je suis peut-être masochiste, mais je trouve aussi le code à base de FILE* plus lisible que les fstream. Ceci étant dit, tu as raison, j'aurai du tester avec ifstream, cela fonctionne sans buffer fixe.
[^] # Re: man fstat
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 3.
Sinon j'aurai utilisé le classique combo fseek/ftell/fseek :)
Ça, ça dépend de la configuration du kernel si je ne dis pas de conneries (/proc/sys/overcommit_memory).
Personnellement, je trouve que c'est plus une gêne qu'une fonctionnalité: l'overcommit fait qu'on ne peut pas faire confiance au système quant au fait que les ressources qu'il nous à confiées sont réellement utilisables.
Je ne vais pas m'étendre la-dessus, mais je préfère éviter de me fier à ce type de mécanisme, et ce, particulièrement pour les applications que je fais pour ma pomme (si le chef me demande de faire le goret après tout, ainsi soit-il, hein, mais j'essaierai quand même d'éviter).
Enfin, certes, 1M, ce n'est pas grand chose, et c'est vrai que ta méthode marche, surtout qu'il suffit de faire d'abord une allocation de bourrin pour récupérer la véritable taille puis ajuster. Je n'y avais pas pensé je le reconnais.
M'enfin, dommage tout de même de ne pas avoir un mécanisme plus efficace (alloc, read, free, alloc, free, 5 appels système, pour quelque chose qui devrait pouvoir se faire plus facilement je pense, et si on doit faire ça de façon répétitive pour les 35K fichiers la fragmentation mémoire risque d'être conséquente à force).
[^] # Re: merci pour ta reponse
Posté par freem . En réponse au message un peu perdu sur la banquise du pingouin. Évalué à 1. Dernière modification le 17 août 2015 à 18:24.
Je ne sais pas pour les mac, mais les IBM/PC (oui, parce que les macs aussi, ce sont des personal computers quoiqu'en disent leurs utilisateurs…) ont depuis toujours des astuces pour réinitialiser les BIOS.
Depuis quelques années (+10 ans quand même) sur mes tours, il y à un cavalier (ou jumper, une petite pièce mobile qui sert d'interrupteur) qui permets de réinitialiser le BIOS. Il est généralement situé près de la pile, mais son emplacement dépend de la carte mère.
J'ai aussi entendu des tonnes d'histoires (légendes, racontars? Aucune idée, je n'ai jamais vérifié sérieusement… mais bon je serai très surpris que ça marche aussi facilement) décrivant des manipulations du style, débrancher toute l'alim du PC, retirer la pile, etc etc.
Ça n'aide pas beaucoup j'imagine… un forum spécialisé mac te serait probablement plus utile sur ce coup je pense.
[edit]
À noter que les vidéos que tu indiques sont très récentes, peu surprenant du coup que ça ne fonctionne pas sur une machine qui doit dater à peu près de 2003-2005 vue la quantité de RAM disponible
# Petites précisions.
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 3.
Il semble que ma question ne soit pas assez claire (ce qu'en fait je comprend, c'est juste un bloc de texte… mea culpa!), donc voici quelques précisions/reformulations.
Je cherche à savoir s'il est possible de connaître la taille des éléments de /proc par programmation C (C++ en fait, mais l'accès à ces ressources se fait de la même façon de toute manière).
À l'heure actuelle, mon code (qui fonctionne) procède en allouant à la compilation un buffer de taille fixe (je vous ai menti en plus, vue la constante je n'ai même pas utilisé la taille exacte de /proc/meminfo…) déterminé de façon empirique pour pouvoir tout contenir.
L'inconvénient de cette façon de faire est que si un jour je veux accéder à d'autres informations de /proc (ou soyons fous, de /sys?) il me faudra alors effectuer la mesure manuellement afin de déterminer la taille à allouer au buffer sur lequel je vais travailler.
Pire, si je serre de trop près la taille réelle du fichier, un jour ça pètera et on ne pourra savoir pourquoi qu'en regardant dans le code (même si pour le moment il n'y a que 200LoC, rien ne prouve que ça restera trivial dans le temps). Et si on voulait changer de système cible (genre, pour aller sur du BSD), idem, gros risque que ça casse (ok, les noms des variables diffèrent certainement de toute façon, mais devoir ajuster des textes à la main me suffit, pourquoi y ajouter des tailles de buffer?)
La solution évidente est de lire progressivement le fichier. J'ai testé, ça ne marche pas (franchement, ça m'a valu pas mal d'incompréhension, je n'ai pas toujours l'esprit très rapide et je ne me suis résolu qu'a contre-cœur d'utiliser la même méthode que le source de xosview), la raison semblant être que dans le cas de ces pseudos-fichiers, aucune information de position du curseur n'est stockée (ou mise à jour, pour ce que ça change).
En espérant que ce soit plus clair…
[^] # Re: man fstat
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2. Dernière modification le 17 août 2015 à 17:56.
Arg… double post, oups!
[^] # Re: man fstat
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2.
En temps normal, j'aurai utilisé ls -l, mais en l'occurrence, il ne s'agit pas d'un vrai fichier, les méthodes traditionnelles ne fonctionnent donc pas.
Je ne connaissais cependant pas ces commandes.
fstatn'est pas installé sur mon système, etstatrenvoie 0 pour /proc/meminfo.Je viens de lire très brièvement le man de mmap. Je ne suis pas sûr d'en voir l'intérêt, sauf pour écrire un chargeur de binaire d'un format différent de ELF, ou écrire un programme métamorphe.
J'ai essayé de lire ligne par ligne, mais la encore, la nature virtuelle du fichier fait que ce n'est pas possible, il faut le lire d'un bloc sinon les instructions ne retournent tout le temps que le début du fichier (qui, en fait, n'est pas un fichier, et du coup FILE* ne contiens pas d'information de positionnement, à ce que j'ai compris).
[^] # Re: rassures moi vite
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2.
Parce que ce n'est pas un vrai fichier. En fait, ce que tu décris est la première approche que j'ai utilisée: une bonne vieille while( !feof( f ) ). Sauf que ça marche pas, /proc étant en fait, je l'ai découvert à mes dépends (l'expérience aura été utile au moins), un peu comme un accès à une partie de la mémoire du kernel accessible en read-only (et peut-être rw pour certaines parties, je ne connais pas assez).
Du coup, FILE* ne mets pas à jour l'information de position. Conséquence, on lis en permanence la même ligne.
[^] # Re: Doc
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2.
C'est vrai que je pourrai prendre la taille maximum actuelle du fichier.
Le problème étant, dans ce cas, que j'ai toujours un truc hardcodé, dédié à une une partie particulière d'un système particulier.
Si un jour je veux évoluer le programme pour accéder à d'autres informations, je devrais refaire la même recherche de la taille maximale d'un autre fichier… bof bof.
Non pas que je m'attende à ce que tous les systèmes nomment leurs "fichiers"/variables de la même façon bien sûr, voire même je doute qu'il soit possible d'accéder à ces informations via un simple fopen (en fait je sais que c'est impossible, l'OS de microsoft n'exposant pas son interface de cette façon, mais m'en cogne de celui-la)… mais je trouve du coup que c'est quand même dommage de devoir utiliser une valeur au pifomètre pour tenter de récupérer toutes les informations.
Même si mon patch à i3status ne fait que +/- 80 LoC, je trouve ça dommage de mettre des choses en dur dedans (autrement dit, définies à la main, peu importe si c'est au travers d'une constante ou de valeurs numériques, le résultat est le même au final).
Il me reste toujours la piste de mmap() suggérée plus haut. J'y répondrai quand j'aurai fini de lire le man et quand j'aurai vérifié que c'est utilisable (ou pas, je le préciserai dans ce cas).
[^] # Re: rassures moi vite
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 2.
Tu m'as mal compris: j'utilise wc pour déterminer la taille de ce fichier, afin d'allouer, dans un programme (C++ en l'occurrence) la taille du buffer que je dois utiliser pour lire ce fichier (et ensuite traiter les informations qui m'intéressent).
[^] # Re: Linux < Debian < KDE < Logiciel
Posté par freem . En réponse au journal Comment mon expérience Linux est en train de tourner au fiasco. Évalué à 2.
Ce n'est pas le client qui pose problème, mais la configuration du daemon, en tout cas sous Debian.
Je ne pourrais pas te dire la config par défaut, mais voici la section de la mienne qui t'intéressera:
Bref, il suffit de lire le fichier de conf et ce problème se règle tout seul. Ou aller lire le manuel, je pense que ce genre de choses doivent y être expliquées, mais moi je lis toujours les conf avant les manuels :p
Après, pour PA, j'en sais rien, perso quand je vois un truc qui en dépend, je l'installe pas. Et le seul problème de son que j'ai c'est avec mumble (le micro refuse d'y fonctionner sur une machine, alors qu'il marche très bien quand j'active l'écho sous alsamixer et que sur une autre machine mumble marche, sans PA dans les 2 cas… j'y pige que dalle perso)