Il est généralement possible de programmer le redémarrage automatique d'un ordinateur via la RTC.
Cela se passe dans le fichier /sys/class/rtc/rtc0/wakealarm (voir le fichier rtc.txt de la documentation du noyau, suivant le matériel il est possible qu'il y en ai plusieurs).
On peut soit lire ce fichier pour voir si le réveil est programmé et pour quand, ou écrire dans ce fichier pour programmer le réveil.
On peut écrire dans deux formats différents, soit un temps absolu en secondes depuis l'epoch (timestamp unix), soit un nombre de secondes précédé d'un + pour indiquer das combien de secondes dans le futur il faut se réveiller.
Donc dans ton cas, il suffirait d'ajouter un script à l'extinction qui fait un
/bin/echo +120 > /sys/class/rtc/rtc0/wakealarm
pour que la machine se réveille deux minutes après (il faut laisser assez de temps pour qu'il soit effectivement éteint).
Attention que, de mon expérience (c'est peut-être dépendant du matériel), s'il y a déjà une date de réveil programmée il faut le mettre à 0 (echo 0) avant de pouvoir en affecter une nouvelle.
Oui, forcément puisque ces caractère sont ajoutés à la sortie que le deuxième grep reçoit en entrée.
Dans ton exemple il faut inverser les deux grep, comme le grep -v ne sort que les lignes qui ne correspondent pas il n'y mettra aucune couleur, l'autre peut alors travailler sans problème sur le flux resultant.
Une autre solution est de faire tout en un seul grep, mais ça peut rapidement faire des expressions rationnelles très compliquées. Dans ton cas il faudrait activer les expressions rationnelles de type perl (-P avec GNU grep) pour pouvoir faire un «zero-width negative look-ahead» (man perlre), ce qui te donnerait l'expression suivante
bidule(?!-truc)
qui peut se traduire en français pas «sélectionner bidule s'il n'est pas suivi par -truc».
Par exemple, le fait que que tu puisses allègrement mixer des dépôts i586 et x86_64 sans qu'il ne trouve rien à redire et surtout qu'il t'installes les paquets de la mauvaise arch ?
J'ai les deux d'activés et il s'en sort très bien.
L'absence d'outils comme apt-cacher-ng pour te faire un proxy local, la gestion du multiarch, etc, etc.
loin devant les serveurs vnc (où tout, même le mot de pase, passe en clair)
Il suffit de faire un tunnel ssh et tout passera en crypté, du coup tu peux faire écouter le serveur vnc uniquement sur la boucle locale, et si tu a confiance dans tous les utilisateurs de la machine tu peux même te passer de mot de passe au niveau de vnc.
Et puis il y a ceux qui font semblant mais en fait ne comprennent rien, j'ai eu le cas où, pour me donner accès à un serveur on m'a envoyé par mail la clé privée ssh dont la version publique avait été placée pour le compte root :-O
Plus précisément, il utilise son éditeur interne qui est peut-être basé sur nano. Mais sinon, il utilise la variable EDITOR et ça marche très bien.
Non, mc a son propre éditeur interne (qui n'a rien à voir avec nano et qui supporte les expressions rationnelles), mais il a aussi un paramètre (positionné par défaut sur certaines distributions) pour utiliser l'éditeur par défaut du système plutôt que le sien.
Et mcedit est également utilisable indépendamment de mc.
Si, grub1 reconnait le raid logiciel de Linux mais uniquement l'ancien format de méta-données (0.90), donc on peut créer explicitement avec mdadm -e 0.90 un périphérique raid pour /boot qu isera reconnu par grub1.
Il est également possible que les versions actuellement inclues dans les distributions soient patchées pur supporter le nouveau format de méta-données.
Heu, OK, mais je répondais au fait de faire un chmod 0777 sur une partition ext2, qui elle retiendra les permissions des nouveaux fichiers qu'on y met.
Sauf qu'il faut refaire ton chmod à chaque ajout de fichier puisque ceux-ci seront créés avec des droits plus restrictifs.
Les ACL peuvent éviter ce problème, mais alors il ne faut utiliser le FS que sur des système qui les supportent.
Non, FUSE-exFAT est sous GPLv3, ce qui est incompatible avec Linux qui est GPLv2-only. On ne peut donc pas reprendre son code pour en faire un module noyau (en tout cas, on ne peut pas distribuer un tel module)
Sauf que, comme il n'y a pas de licence indiquée dans le code on retombe sur le droit d'auteur par défaut, soit que personne n'a le droit ni de distribuer ni d'utiliser ton code.
Si tu veux donner le droit de ré-utiliser ton code et de le redistribuer, il faut le faire explicitement, par exemple avec la licence BSD.
Ben justement, le point 9 de cette page indique que la version majeure n'est incrémentée que si des changements incompatibles ont été introduits. Et il ne me semble pas que ce soit le cas ici, donc n'incrémenter que la version mineure est logique.
Je ne vais pas mettre la fameuse image de XKCD sur les standards, mais je n'en pense pas moins.
Et tu fais bien de ne pas la mettre car ça n'aurait pas été pertinent.
En effet, ils n'ont pas fait un nouveau standard mais bien une nouvelle implémentation d'un standard existant. Et c'est exactement à ça que sert un standard: permettre à chacun de choisir le programme qu'il préfère, et de faire le sien si aucun ne lui convient.
Non effectivement, mais tu trouve que lire une vidéo est un cas si anecdotique que ça?
Et avec seulement 300Mo utilisables en cache disque il ne faut pas de très gros fichiers pour rapidement déborder.
La cache disque n'est jamais mise en swap (ce serait idiot). S'il n'utilise que la moitié de sa RAM pour les applications la swap est effectivement inutile, mais ça ne veut pas dire qu'augmenter la RAM n'aura aucun effet bénéfique, au contraire il y aura beaucoup plus de chances que le chargement d'un gros fichier ne fasse pas sortir de la cache d'autres fichiers qui seront réutilisés plus tard.
Il y a bien entendu une limite au-dessus de laquelle ça n'a plus d'intérêt car tous les fichiers qu'on utilise tiennent en RAM, mais il faudrait avoir un usage très limité pour que cette limite soit déjà à 1Go.
Et comment sais-tu qu'il ne sature pas la RAM?
Tu crois vraiment qu'il a un système tellement léger et des besoins tellement limités que tous les fichiers qu'il peut avoir à lire depuis le disque tiennent tous dans quelques centaines de Mo?
Donc ça vaut dire pas le lecture de vidéo (ni même d'audio) ce qui ferait tout de suie exploser la consommation mémoire.
passer à 2Go ne fera que changer la taille du cache de 300 à 1300Mo, ce qui ne changera pas grand chose aux performances.
Ben si, justement!
Ça fait beaucoup de fichiers qui pourront être conservé en mémoire et ne plus être relu depuis le disque, ce qui est quelques ordres de grandeur plus rapide!
Donc ça devrait faire une grosse amélioration générale de la réactivité du système.
Ce n'est pas si sur…
L'option -Xmx de java ne configure la limite que de la partie heap, c'est à dire celle qui contient les instances des objets.
Mais il y a aussi la partie non-heap, qui contient les classes chargées par la jvm. Dans la jvm d'oracle et openjdk ça se configure avec une option en -XX. La valeur par défaut du maximum du non-heap est 128Mo en 32bits et 160Mo en 64 bits.
D'autres jvm peuvent géré ça de façon complètement différente (exemple extrême avec gcj/gij où les classes sont compilées sous forme de bibliothèques natives).
Et ce n'est pas tout, il y a par exemple la classe java.nio.MappedByteBuffer qui permet de travailler sur un fichier mappé en mémoire, qui va donc prendre de la RAM supplémentaire en dehors (et sans les limitations) de celle contrôlée par la jvm (donc fuite de mémoire potentielle).
Tu peux voir la mémoire effectivement utilisée par le processus java via les tichiers stat* dans son répertoire de /proc (man proc pour les détails des champs), ça peut surprendre.
Pas tout à fait.
Quand la jvm arrive à sa limite, le thread qui a le malheur de créer l'objet de trop (goutte, vase, …) se prend un OutOfMemoryError, ce qui va probablement tuer le thread en question (sauf si on intercepte les Error, mais c'est dangereux) et libérer la mémoire retenue par ce thread-là.
Si ce thread n'était pas le seul thread non)-daemon de la jvm, les autres vont continuer comme si de rien n'était (mais avec peut-être des objets dans un état incohérent suite à la mort violente du thread sacrifié).
# programmer le redémarrage
Posté par wismerhill . En réponse au message Désactiver poweroff. Évalué à 9.
Il est généralement possible de programmer le redémarrage automatique d'un ordinateur via la RTC.
Cela se passe dans le fichier /sys/class/rtc/rtc0/wakealarm (voir le fichier rtc.txt de la documentation du noyau, suivant le matériel il est possible qu'il y en ai plusieurs).
On peut soit lire ce fichier pour voir si le réveil est programmé et pour quand, ou écrire dans ce fichier pour programmer le réveil.
On peut écrire dans deux formats différents, soit un temps absolu en secondes depuis l'epoch (timestamp unix), soit un nombre de secondes précédé d'un + pour indiquer das combien de secondes dans le futur il faut se réveiller.
Donc dans ton cas, il suffirait d'ajouter un script à l'extinction qui fait un
/bin/echo +120 > /sys/class/rtc/rtc0/wakealarm
pour que la machine se réveille deux minutes après (il faut laisser assez de temps pour qu'il soit effectivement éteint).
Attention que, de mon expérience (c'est peut-être dépendant du matériel), s'il y a déjà une date de réveil programmée il faut le mettre à 0 (echo 0) avant de pouvoir en affecter une nouvelle.
[^] # Re: grep
Posté par wismerhill . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 3.
Oui, forcément puisque ces caractère sont ajoutés à la sortie que le deuxième grep reçoit en entrée.
Dans ton exemple il faut inverser les deux grep, comme le grep -v ne sort que les lignes qui ne correspondent pas il n'y mettra aucune couleur, l'autre peut alors travailler sans problème sur le flux resultant.
Une autre solution est de faire tout en un seul grep, mais ça peut rapidement faire des expressions rationnelles très compliquées. Dans ton cas il faudrait activer les expressions rationnelles de type perl (-P avec GNU grep) pour pouvoir faire un «zero-width negative look-ahead» (man perlre), ce qui te donnerait l'expression suivante
qui peut se traduire en français pas «sélectionner bidule s'il n'est pas suivi par -truc».
[^] # Re: grep
Posté par wismerhill . En réponse à la dépêche Coloriser des flux de texte avec colout. Évalué à 7. Dernière modification le 06 avril 2013 à 13:58.
grep --color=always
très pratique à combiner avec un less -R
[^] # Re: Canonical est-elle encore une entreprise souhaitant développer le monde open source ?
Posté par wismerhill . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 4.
J'ai les deux d'activés et il s'en sort très bien.
https://wiki.mageia.org/en/Urpmi-proxy
# mageia
Posté par wismerhill . En réponse au message Distribution avec KDE ?. Évalué à 6.
L'intégration de KDE dans mageia est très bonne.
La 2 vient avec KDE 4.8, la 3 (actuellement en beta) aura KDE 4.10.
[^] # Re: x2go et alternatives ?
Posté par wismerhill . En réponse au journal x2go : le digne successeur de freenx. Évalué à 2.
Il suffit de faire un tunnel ssh et tout passera en crypté, du coup tu peux faire écouter le serveur vnc uniquement sur la boucle locale, et si tu a confiance dans tous les utilisateurs de la machine tu peux même te passer de mot de passe au niveau de vnc.
[^] # Re: redhat en poste de travail
Posté par wismerhill . En réponse à la dépêche Sortie de Red Hat Enterprise Linux 6.4. Évalué à 3.
Si c'est pour récupérer les données, va plutôt voir de ce côté-là http://www.sysresccd.org/
[^] # Re: CPanel soupçonné
Posté par wismerhill . En réponse à la dépêche Infection par rootkit « SSHd Spam » sur des serveurs RHEL/CentOS. Évalué à 8.
Non non, les admin sérieux, ça existe.
Et puis il y a ceux qui font semblant mais en fait ne comprennent rien, j'ai eu le cas où, pour me donner accès à un serveur on m'a envoyé par mail la clé privée ssh dont la version publique avait été placée pour le compte root :-O
[^] # Re: Mauvaise interprétation
Posté par wismerhill . En réponse au journal Systemd dans Debian. Évalué à 2.
Non, mc a son propre éditeur interne (qui n'a rien à voir avec nano et qui supporte les expressions rationnelles), mais il a aussi un paramètre (positionné par défaut sur certaines distributions) pour utiliser l'éditeur par défaut du système plutôt que le sien.
Et mcedit est également utilisable indépendamment de mc.
[^] # Re: Serveurs
Posté par wismerhill . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Si, grub1 reconnait le raid logiciel de Linux mais uniquement l'ancien format de méta-données (0.90), donc on peut créer explicitement avec mdadm -e 0.90 un périphérique raid pour /boot qu isera reconnu par grub1.
Il est également possible que les versions actuellement inclues dans les distributions soient patchées pur supporter le nouveau format de méta-données.
[^] # Re: Alternative libre ?
Posté par wismerhill . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 2.
Je viens de tester sur un android 4.1 de base et il ne sait pas quoi faire de cette clé USB.
[^] # Re: exFAT et Mac OS X
Posté par wismerhill . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 2.
Heu, OK, mais je répondais au fait de faire un chmod 0777 sur une partition ext2, qui elle retiendra les permissions des nouveaux fichiers qu'on y met.
[^] # Re: exFAT et Mac OS X
Posté par wismerhill . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 4.
Sauf qu'il faut refaire ton chmod à chaque ajout de fichier puisque ceux-ci seront créés avec des droits plus restrictifs.
Les ACL peuvent éviter ce problème, mais alors il ne faut utiliser le FS que sur des système qui les supportent.
[^] # Re: Licence
Posté par wismerhill . En réponse à la dépêche FUSE-exFAT en version 1.0.0. Évalué à 5.
Non, FUSE-exFAT est sous GPLv3, ce qui est incompatible avec Linux qui est GPLv2-only. On ne peut donc pas reprendre son code pour en faire un module noyau (en tout cas, on ne peut pas distribuer un tel module)
[^] # Re: Licence libre
Posté par wismerhill . En réponse à la dépêche L'astronomie libre sous Linux : le point fin 2012, début 2013. Évalué à 7.
Sauf que, comme il n'y a pas de licence indiquée dans le code on retombe sur le droit d'auteur par défaut, soit que personne n'a le droit ni de distribuer ni d'utiliser ton code.
Si tu veux donner le droit de ré-utiliser ton code et de le redistribuer, il faut le faire explicitement, par exemple avec la licence BSD.
[^] # Re: Waouh…
Posté par wismerhill . En réponse à la dépêche Sortie de Tcl/Tk 8.6. Évalué à 3.
Ben justement, le point 9 de cette page indique que la version majeure n'est incrémentée que si des changements incompatibles ont été introduits. Et il ne me semble pas que ce soit le cas ici, donc n'incrémenter que la version mineure est logique.
[^] # Re: Mouais
Posté par wismerhill . En réponse à la dépêche Grabuge à la FSF : GnuTLS quitte le projet GNU et sed et grep perdent leur mainteneur. Évalué à 10.
Ah oui, c'est sur que les scripts sed c'est vachement lisible…
[^] # Re: Samba 4, DNS et LDAP
Posté par wismerhill . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 10.
Et tu fais bien de ne pas la mettre car ça n'aurait pas été pertinent.
En effet, ils n'ont pas fait un nouveau standard mais bien une nouvelle implémentation d'un standard existant. Et c'est exactement à ça que sert un standard: permettre à chacun de choisir le programme qu'il préfère, et de faire le sien si aucun ne lui convient.
[^] # Re: usages et besoins
Posté par wismerhill . En réponse au message Améliorer un EEE pc?. Évalué à 2.
Non effectivement, mais tu trouve que lire une vidéo est un cas si anecdotique que ça?
Et avec seulement 300Mo utilisables en cache disque il ne faut pas de très gros fichiers pour rapidement déborder.
[^] # Re: usages et besoins
Posté par wismerhill . En réponse au message Améliorer un EEE pc?. Évalué à 3.
Ta calculatrice a quelques problèmes, 1024-128 ça donne 896, pour qu'il reste 768Mo au système il faudrait que la carte graphique réserve 256Mo.
[^] # Re: usages et besoins
Posté par wismerhill . En réponse au message Améliorer un EEE pc?. Évalué à 3.
La cache disque n'est jamais mise en swap (ce serait idiot). S'il n'utilise que la moitié de sa RAM pour les applications la swap est effectivement inutile, mais ça ne veut pas dire qu'augmenter la RAM n'aura aucun effet bénéfique, au contraire il y aura beaucoup plus de chances que le chargement d'un gros fichier ne fasse pas sortir de la cache d'autres fichiers qui seront réutilisés plus tard.
Il y a bien entendu une limite au-dessus de laquelle ça n'a plus d'intérêt car tous les fichiers qu'on utilise tiennent en RAM, mais il faudrait avoir un usage très limité pour que cette limite soit déjà à 1Go.
[^] # Re: usages et besoins
Posté par wismerhill . En réponse au message Améliorer un EEE pc?. Évalué à 3.
Et comment sais-tu qu'il ne sature pas la RAM?
Tu crois vraiment qu'il a un système tellement léger et des besoins tellement limités que tous les fichiers qu'il peut avoir à lire depuis le disque tiennent tous dans quelques centaines de Mo?
Donc ça vaut dire pas le lecture de vidéo (ni même d'audio) ce qui ferait tout de suie exploser la consommation mémoire.
[^] # Re: usages et besoins
Posté par wismerhill . En réponse au message Améliorer un EEE pc?. Évalué à 3.
Ben si, justement!
Ça fait beaucoup de fichiers qui pourront être conservé en mémoire et ne plus être relu depuis le disque, ce qui est quelques ordres de grandeur plus rapide!
Donc ça devrait faire une grosse amélioration générale de la réactivité du système.
[^] # Re: POO
Posté par wismerhill . En réponse au journal Du code propre, c'est quoi ?. Évalué à 4.
Ce n'est pas si sur…
L'option -Xmx de java ne configure la limite que de la partie heap, c'est à dire celle qui contient les instances des objets.
Mais il y a aussi la partie non-heap, qui contient les classes chargées par la jvm. Dans la jvm d'oracle et openjdk ça se configure avec une option en -XX. La valeur par défaut du maximum du non-heap est 128Mo en 32bits et 160Mo en 64 bits.
D'autres jvm peuvent géré ça de façon complètement différente (exemple extrême avec gcj/gij où les classes sont compilées sous forme de bibliothèques natives).
Et ce n'est pas tout, il y a par exemple la classe java.nio.MappedByteBuffer qui permet de travailler sur un fichier mappé en mémoire, qui va donc prendre de la RAM supplémentaire en dehors (et sans les limitations) de celle contrôlée par la jvm (donc fuite de mémoire potentielle).
Tu peux voir la mémoire effectivement utilisée par le processus java via les tichiers stat* dans son répertoire de /proc (man proc pour les détails des champs), ça peut surprendre.
[^] # Re: POO
Posté par wismerhill . En réponse au journal Du code propre, c'est quoi ?. Évalué à 4.
Pas tout à fait.
Quand la jvm arrive à sa limite, le thread qui a le malheur de créer l'objet de trop (goutte, vase, …) se prend un OutOfMemoryError, ce qui va probablement tuer le thread en question (sauf si on intercepte les Error, mais c'est dangereux) et libérer la mémoire retenue par ce thread-là.
Si ce thread n'était pas le seul thread non)-daemon de la jvm, les autres vont continuer comme si de rien n'était (mais avec peut-être des objets dans un état incohérent suite à la mort violente du thread sacrifié).