scripts_utiles - Documentation Ubuntu Francophone
Quelques scripts GNU/Linux à garder sous le coude.
HipHop - Un clone de PopCorn Time mais pour la musique « Korben
\o/
(par contre, ça récupère les chansons sur Youtube : ça va donc pas tenir longtemps, vu que Google va réagir… ils feraient mieux de chercher sur les réseaux P2P)
(par contre, ça récupère les chansons sur Youtube : ça va donc pas tenir longtemps, vu que Google va réagir… ils feraient mieux de chercher sur les réseaux P2P)
Impact of ext4′s discard option on my SSD « Patrick's WebLog
Les SSD sont rapides à l’accès et à l’écriture des données… sur un emplacement vide.
Le problème des SSD, c’est que si un emplacement est encore rempli, il doit être vidé avant puis ré-écrit.
Ceci prend du temps : le SSD passe son temps à traquer les emplacements libres et pas encore vidés pour les vider.
Récemment, des chercheurs ont trouvé un moyen d’améliorer tout ça : http://geekattitu.de/2014/05/27/ils-ont-trouve-comment-rendre-votre-ssd-actuel-300-plus-rapide/
En attendant, il y a une option, le TRIM qui permet au système de fichier de remettre à 0 les emplacements d’où on supprimer des fichiers. Sauf que ça prend du temps là aussi, lorsqu’on supprime tout un tas de fichiers (le temps est pris lors de la suppression et non lors de l’écriture).
Le lien ici montre un benchmark : il regarde le temps pris sans l’option Discard dans le fstab (discard active le TRIM). Clairement, il faut donc ne pas l’activer si on veut garder des performances correctes pour certaines opérations.
Certains vont même jusqu’à préférer un cronjob qui va TRIMer tout le disque une fois par jour ou par semaine.
Comme ça les prochaines écritures seront plus rapides.
https://wiki.archlinux.org/index.php/fstab
https://wiki.archlinux.org/index.php/SSD#Pre-Purchase_Considerations
Le problème des SSD, c’est que si un emplacement est encore rempli, il doit être vidé avant puis ré-écrit.
Ceci prend du temps : le SSD passe son temps à traquer les emplacements libres et pas encore vidés pour les vider.
Récemment, des chercheurs ont trouvé un moyen d’améliorer tout ça : http://geekattitu.de/2014/05/27/ils-ont-trouve-comment-rendre-votre-ssd-actuel-300-plus-rapide/
En attendant, il y a une option, le TRIM qui permet au système de fichier de remettre à 0 les emplacements d’où on supprimer des fichiers. Sauf que ça prend du temps là aussi, lorsqu’on supprime tout un tas de fichiers (le temps est pris lors de la suppression et non lors de l’écriture).
Le lien ici montre un benchmark : il regarde le temps pris sans l’option Discard dans le fstab (discard active le TRIM). Clairement, il faut donc ne pas l’activer si on veut garder des performances correctes pour certaines opérations.
Certains vont même jusqu’à préférer un cronjob qui va TRIMer tout le disque une fois par jour ou par semaine.
Comme ça les prochaines écritures seront plus rapides.
https://wiki.archlinux.org/index.php/fstab
https://wiki.archlinux.org/index.php/SSD#Pre-Purchase_Considerations
Teddybears in Dutch Police cars - WTF fun facts
J’ai envie d’ajouter que c’est pareil dans les églises, sauf que c’est pas le même nounours :p
/me sors…
/me sors…
La Question Technique : c'est fabriqué comment, un processeur ? | PCWorld.fr
Les lingots (gros cylindres de silicium) sont des monocristaux, c’est à dire que c’est un seul et même cristal
L’avantage de ça, c’est que si on le coupe en deux, ça le coupe selon un plan de cristallisation et la surface est on ne peut plus lisse : dans le meilleur des cas, la surface de coupe n’a, entre le point le plus haut et le point le plus bas, pas un atome de différence. Et la matière est archi-régulière
La même chose en vidéo, par Intel : https://www.youtube.com/watch?v=d9SWNLZvA8g (plus précise, mais y’a pas d’explications, c’est dommage).
L’avantage de ça, c’est que si on le coupe en deux, ça le coupe selon un plan de cristallisation et la surface est on ne peut plus lisse : dans le meilleur des cas, la surface de coupe n’a, entre le point le plus haut et le point le plus bas, pas un atome de différence. Et la matière est archi-régulière
La même chose en vidéo, par Intel : https://www.youtube.com/watch?v=d9SWNLZvA8g (plus précise, mais y’a pas d’explications, c’est dommage).
Mentos, lait, freezer… Six expériences étonnantes à réaliser avec du Coca-Cola
Si je fais l’expérience du coca en surfusion (liquide en dessous de 0°C et qui gèle quand on le choque) et que je verse un menthos quand le coca est encore liquide…
… ça va faire un geyser solide ?
… ça va faire un geyser solide ?
[ubuntu] [SOLVED] Putting /tmp on its own partition [Archive] - Ubuntu Forums - Le Hollandais Volant - Liens de tcit
Oui j’ai songé aussi à mettre le dossier /tmp directement dans la RAM.
Je n’ai pas non plus de partition Swap, donc je pensais que ça faisais un peu beaucoup pour la RAM de tout y mettre (même si l’absence de Swap n’est pas un problème pour la Ram, avec 6Go).
Je vais tester un peu avec la partition.
Pour var, si je veux pas le laisser sur la SSD, c’est parce que c’est dans /var/log que se trouvent tous les logs systèmes (xorg, apache, syst, faillog, mysql, apt, kern, ufw…), et ils sont mis à jour sans arrêt.
Je n’ai pas non plus de partition Swap, donc je pensais que ça faisais un peu beaucoup pour la RAM de tout y mettre (même si l’absence de Swap n’est pas un problème pour la Ram, avec 6Go).
Je vais tester un peu avec la partition.
Pour var, si je veux pas le laisser sur la SSD, c’est parce que c’est dans /var/log que se trouvent tous les logs systèmes (xorg, apache, syst, faillog, mysql, apt, kern, ufw…), et ils sont mis à jour sans arrêt.