ninis666 a écrit 95 commentaires

/o\ Autant pour moi, Mint / Debian / Unbutu utilisent tous APT !
En cherchant rapidement, j'ai trouvé ça :
https://www.cilicia.us/wp/?p=1281

En fait ces instructions là sont pour Debian, et non pour Mint. Ça a dû marcher sur Ubuntu parce que celui-ci utilise le même framework de gestion de paquet que Debian :)

Mais tellement formateur ! Si c'est pas trop gros, repart des sources de ton appli qui tu auras trouvé, lit le README ou INSTALL dedans, généralement il y a tout ce qu'il te faut pour t'aider à compiler / installer ton appli.

Ou sinon, demandes à installer une VM sur ton Linux …

C'est toujours une bonne habitude d'ajouter les flags de warning à ton compilo : (-Wall ou -Wextra si tu veux être vraiment rigoureux).

En les activant, tu aurais eu un warning disant que srand() n'est pas déclaré et qu'il faut inclure .

Et que du coup, en l'incluant, tu aurais vue que random() est déjà une fonction définie par la libc !

Bref, active toujours les flags de warning, à minima -Wall, -Wextra et -Werror étant l'idéal.

Ah aussi, reconfigure ta locale pour avoir des messages en français, si tu n'es pas à l'aise avec l'anglais …

<troll

Ou sinon:

ln -sf /bin/bash /sbin/init

et hop, ton système est up & running en moins de quelques secondes !

/troll>

En fait je ne comprends pas trop ce genre de démarche en fait : Si tu veux pouvoir ré-démarrer très rapidement, je trouve que le "suspend to disk" ou "suspend to ram" marche assez bien en pratique sur les machines de bureau … Pour les systèmes "embarqués", à la limite, le truc avec /bin/bash aurait vraiment du sens :)

Et puis même si je trouve le boot par systemd trop invasif pour que ce qu'il devrait faire, son vrai intérêt à mes yeux, c'est la gestion des dépendances des services plutôt élégante.

Ouf le problème ne venait pas de mon niveau Linux

Ben si:

si l'installation était forcée sur cette version (ce que j'ai fait)

Forcer les choses, c'est réservé à ceux qui savent ce qu'ils font ou à ceux qui vont aller regarder pourquoi il faut forcer.

Oumpf ! C'est un peu rude comme remarque qui s'adresse à un novice qui prend le temps d'investiguer et de comprendre son problème et surtout de partager sa démarche ici …

Non, il faut oser bidouiller pour comprendre comment marche les choses ! Ce n'est jamais une perte de temps que de casser un truc, le hack (la bidouille en FR) c'est toujours formateur.

Bref, c'est un peu à cause de ce genre de commentaires que j'avais arrêté de suivre linuxfr pendant quelques temps …

stat permet de savoir la taille d'un bloc de ton fichier (dans la section IO Block).

Avec un fichier de 1k:
bash$ dd if=/dev/zero of=prout bs=$((1024 * 1)) count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000188972 s, 5.4 MB/s
bash$ stat -c "%o" prout
4096

Avec un fichier de 4k:
dd if=/dev/zero of=prout bs=$((1024 * 4)) count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000185359 s, 22.1 MB/s
bash$ stat -c "%o" prout
4096

Avec un fichier de 8k:
bash$ dd if=/dev/zero of=prout bs=$((1024 * 8)) count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB, 8.0 KiB) copied, 0.000213151 s, 38.4 MB/s
bash$ stat -c "%o" prout
4096

Du coup, tu n'as plus qu'à le faire sur un fichier de ton FS source et un autre sur ton FS destination et spécifier à dd les tailles des blocs en lecture et écriture (avec ibs / obs).

Moi j'aime bien le cli, mais pour les cherry-pick tout ça, je préfère gitg :
Une sorte de combo entre 'gitk' et 'git gui'. Et en plus ça tourne sous Windows aussi.

En faisant des dd comme ça, tu ne mesures pas la vitesse des I/O de ton média, mais de toute ta chaine vers ton FS: la maj des caches + inodes + FS + … + IO vers ton SSD.

Je pense qu'il faudrait les refaire sur le disque directement (dd if=/dev/zero of=/dev/sda). Mais bon, là tu fout en vrac tes partitions et tes donnés !

À mon humble avis, dans n'importe quel budget, un compact sera toujours mieux qu'un smartphone : Comme dit plus haut, à gamme de prix équivalents, le capteur d'un compact sera toujours mieux que celui d'un smartphone (la taille de capteur influe sur le fait qu'il y aura plus ou moins de bruit sur ton image).

Mais même sans parler de capteurs, il y a aussi l'optique (le "zoom") qui sera toujours meilleur :
- sur les smartphone, il n'y en a pas, du coup, ton appareil (ou toi !) ne peux contrôler son ouverture.
- sur un compact, l'optique est généralement stabilisée, du coup, en gros moins de photos floues quand il y a peu de lumière.

Dans les 2 cas, ça sera du JPEG que ça va produire, donc il aussi comparer les traitements de l'image finale (je parle pas des "filtres" que tu peux faire après coup sur ton smartphone hein :) ) : je trouve que les algos de développement en JPEG des constructeurs d'appareil photos sont quand même mieux que ceux des firmware de téléphone. Après c'est une question de goût, je trouve les trouve trop "flatteurs" … En regardant sur un vrai écran (bien calibré, mais ça c'est encore un autre débat ! :) ), je trouve que ça fait un peu trop "chimique" …

Bref, tout ce long laïus pour dire qu'un compact c'est mieux qu'un smartphone pour le chaland voulant voyager !

Vu comme ça, ça sent le deadlock !

Et puis je pense que ça ne soit pas très safe comme méthode : appeler les ioctls / read / write sans passer par l'API, c'est un peu casse gueule … D'instinct, je vérifierais si ton callback unlocked_ioctl soit bien appelé avec les bons locks verrouillés (ou déverrouillés) !

Ton kernel a-t-il eu le temps de sortir son kernel panic ?

Bref, comme dit plus haut, moi je ferrais en les traitements des données en user-space et tes drivers ne faisant qu'exposer les donnés des I/O ….

Ce n'est pas d'appeler les callback read / write / ioctl du driver hidraw mais d'appeler les fonctions qui sont appelées dedans:

En reprenant ce que fait la callback de read de hidraw par exemple:

static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) 
{
  ....
  len = la_fonction_qui_m_interesse(&data);
  copy_to_user(buffer, data, len);
  ...
}

Et donc d'appeler directement la_fonction_qui_m_interesse … Mais en fait je vois que ça ne peut pas marcher, vue qu'en vrai les callback de hidraw mettent à jour des structures internes qui ne sont pas exposées …. Donc non, ça va pas marcher !

Si les fonctions de lecture / écriture / ioctl du driver gérant hidraw sont exposées publiquement, tu peux le appeler directement depuis ton driver à toi.

Comme dit précédemment, powertop est vraiment cool pour faire que ta machine consomme moins (en faisant un "TAB" pour aller voir ce qu'il y a dans l'onglet "Tunables").

Les process entre [] sont des kernel threads, comme son nom l'indique, des trucs qui sont gérés par le kernel. Je doute que ce soit là ton plus gros consommateur … Mais si tu dois faire le ménage dedans :
- il faut soit recompiler un kernel sans tous les trucs que tu n'a pas besoin
- soit virer les modules qui n'ont pas besoin d'être là.

Pour éviter qu'un process prenne trop de CPU, je pense qu'il serait sage de le lancer avec un "nice" devant (cf. man 1 nice) : nice -n 20 /usr/bin/firefox

Tu peux aussi regarder du côté des "governor" : c'est les différentes méthodes d'allocation CPU que ton kernel peut choisir d'utiliser. C'est assez bien expliqué ici : https://wiki.archlinux.org/index.php/CPU_frequency_scaling

C'est le compilo qui va gérer ma récursion terminale, pas le langage ….

Un tail ne te suffit pas ?
genre :

bash$ tail -1 /mon/fichier/de/log | ma_command_traitant_une_ligne

C'est selon ta capillarité faciale :
- si tu es barbu (un vrai barbu, pas celui qui entretien sa barbe genre "j'ai une barbe de 3 jours"), tu préférera la ligne de commande.
- si tu n'es pas barbu (ou que tout ce que tu cherches c'est un look hipster), tu préférera utiliser les frontend graphiques à ces même lignes de commande.

Ça a l'air d'être un jeu qui ne tourne que sous Windows, il te faut donc utiliser wine : ce n'est pas un emulateur de Windows, mais plutôt une sorte de wrapper qui permettent de charger les dlls et tout ce qui va bien pour lancer des binaires sous windows.

Mais je t'avoue que pour pouvoir l'utiliser, il te faut installer plein de dll manquants dans les packages d'installation. Je ne saurais que trop te recommander d'utiliser "playonlinux" : c'est un utilitaire qui va te configurer tout un environnement dans lequel tu va pouvoir installer / mettre à jour les paquetages manquant graphiquement (tel mfc42proutprout etc.).

Pour installer playonlinux, cherche le dans ton manager de package (graphique) sous ubuntu, ou en ligne de commande en lançant un terminal et en tapant quelque chose tel que :

sudo apt-get install playonlinux

Moi j'ai un wiko et j'ai les mêmes symptômes : le système ne voit pas les partitions sur le /dev/sdX, bien que le kernel détecte bien le "mass storage" comme un disque.

Suis pas du tout fan des trucs qui me font des trucs par derrière sans que je le sache (sans mauvais jeux de mots :) ), udev me saoul, udisk j'en parle pas … Pour m'en sortir à la main, je suis obligé de faire un fdisk dessus pour que le kernel relise la table des partitions :

root# fdisk /dev/sdX
...
quit
root#


freakazohid, une fois que tes partitions sont là (en regardant les logs du kernel ou /proc/partitions), il faut que tu montes la partition et non le disque !

root# mount /dev/sdbX /mon/point/de/montage


Oui, et bien sûr, ne pas oublier de mettre de la colle liquide dans tous les ports, puis d'enfermer la machine dans une pièce fermée à clef et de la détruire…

Ça pique les yeux quand même ton site, j'ai encore des réminiscence oculaire :p

depuis le temps que ça parle de transmission par le son, personne n'a fait le lien avec le v23 ?

En Inde, le suicide est vraiment puni par la loi. Et c'est aussi le seul pêché que dieu ne pardonne pas dans les 3 religions monothéistes répandus par ici …

un clone libre de transport tycoon, un de mes jeux préférés ;)

ok --> []

Et avec un vieux hack tel que
mkdir -p /usr/X11 && ln -sf /usr /usr/X11/X11R6

Tu ne t'en sors pas ?