benja a écrit 1211 commentaires

Aussi, il y a peut-être une application tierce…

Pour en avoir le coeur net. tu pourrais créer toi même un script à la place de /usr/share/screenlets-manager/screenlets-daemon.py qui contientrait, par exemple, ceci:
`#! /bin/sh

echo Mon parent est $PPID >> /tmp/mon-parent
echo "Il s'agit de ps -p $PPID" >> /tmp/mon-parent
`
(à faire en root et ne pas oublier un 'chmod +x /path/to/screenlets-daemon.py' afin qu'il puisse être exécuté)

Il te suffira ensuite de cliquer sur Oui une fois et d'examiner le contenu de /tmp/mon-parent. Aucun résultat garanti :p

Non celui ci contient uniquement la configuration de screenlet. Il ne dit pas à ton WM de lancer qq chose. En fonction de la distribution, de la méthode utilisée pour lancer ton interface et de ton environnement graphique, différents mécanismes sont utilisés. De mémoire (i.e. liste non exhaustive, erreurs attendues) les fichiers ou répertoires suivant peuvent être consultés : /etc/X11/xsession /etc/X11/xession.d, $HOME/.xsession, $HOME/.xinitrc, $HOME/.kde/Autostart, etc.
Aussi, il y a peut-être une application tierce, démarrée par KDE, qui essayerait ensuite par un mécanisme de configuration qui lui est propre de démarrer screenlet.

Cela a fonctionné pour moi afin de mettre à jour le bios de mon ordi portable. J'ai installé le paquet grub-imageboot (debian) et mis ce qui suit dans /etc/grub.d/40_custom, suivi d'un `update-grub'.
menuentry "BIOS Upgrade" {
set root=(hd0,1)
linux16 /memdisk iso
initrd16 /biosupgrade.iso
}

La suppression complète (purge) signifie avec les distribution type debian ou ubuntu que l'on désire aussi supprimer les fichiers de configurations système associés au paquet (càd essentiellement les fichiers qui résident dans /etc et /var). Car avec dpkg (le gestionaire de paquet bàs-niveau de debian, au même titre que rpm pour redhat et consors), lors d'une suppression simple, ceux-ci sont conservés pour permettre de ne pas devoir reconfigurer le logiciel au cas où l'on réinstallerait, plus tard, ce paquet (ou une version postérieure). Note que les fichiers utilisateurs ne sont en aucun cas touchés !
Cela concerne donc essentiellement les applications de type serveur. Si, supposons que le paquet screenlet crée un fichier dans /etc/xdg/autostart (ces fichiers servent justement à indiquer à l'environnement graphique de démarrer un programme au lancement de la session), si, la suppression simple ne le supprime pas, alors je pense que l'on peut considérer cela un bug d'empaquetage qui devrait être rapporté via le bugzilla de ta distribution.
Je pencherais plus pour un fichier, genre dans $HOME/.kde/share/autostart ou $HOME/.kde/Autostart, à supprimer toi même donc (à voir: il y a peut-être un gestionnaire de session inclu dans kde (que je n'utilise pas donc je ne sais pas)).

Gni??? Source.

Le manuel de ma moto :) "For odometer reading or time periods higher than 31000 km (19,600 mil) or 31 months, repeat the same maintenance as listed in the table from the 7,000 km (4,400 mi) or 7 months every 6000km (3,800mi) or 6 month interval."

Les conducteurs de voiture non plus, même si ils ont un peu plus de protection ils ne sont pas 100% protégés par un épave.

J'ai du mal à comprendre la porté de cet argument, je n'y réponds pas (j'allais écrire une ânerie à la place).

C'est super ton argument: c'est déja cher de rouler en moto alors il n'y a pas de raison de ne pas encore augmenter encore le prix. Logique :-)

À la différence des maladies orphelines, la il y a un vrai petit mago à se faire… J'ai du mal à croire qu'il s'agit de philantropie; amha c'est juste que ça arrange tout le monde : le politicien peut dire qu'il lutte contre le fléau numéro 1 de nos société, c.-à-d. la Sécurité avec un grand S (n'est-ce pas?), les centres de contrôle technique récoltent l'impôt supplémentaire.

Concernant la fréquence: comme précisé plus haut, la distance maximale recommandée entre les entretiens est ~6000 km (ou 6 mois) pour les motos. Le dimensionnement et la sollicitation mécanique différents des pièces moto font que celles ci peuvent s'user beaucoup plus vite (i.e. système de freins, transmission, pneus). Il va de soit que pour les grands rouleurs, 1 ans c'est déja beaucoup trop long pour détecter une défaillance. Sauf que (je renfonce le clou), l'ami motard, il n'est pas suicidaire et il ne roule pas avec n'importe quoi.

60€ = 1 plein de réservoir

Eh ben ça c'est du gros réservoir moto !

C'est sur, il est aussi très courant de faire tomber sa voiture sur le côté.

default via 192.168.100.254 dev eth0 proto static

C'est bien cela.
Ceci devrait te permetre de tester un changement de gateway:
ip route change default via 192.168.42.IP

Ce qu'il est possible de faire avec network manager, c'est créer une nouvelle connexion filiaire en utilisant le mode DHCP/addresse seulement. Je ne sais pas, par contre, si la bascule depuis ton ancienne connexion vers la nouvelle interrompt les connections actives dans ce réseau (il va de soit que les connexion internet le seront). À tester !

En fait si, il s'agit bien aussi des données (cache). Cf. http://www.dragonflybsd.org/features/#index6h2

« This DragonFly feature allows SSD-configured swap to also be used to cache clean filesystem data and meta-data. The feature is carefully managed to maximize the write endurance of the SSD. […] »

J'accuse plutôt celui qui l'autorise à le faire, le gendarme qui n'a pas fait son boulot.

Belle philosophie :)

s/emacs.org/emacswiki.org/ je suppose, non ?

Sinon il y a toujours la forme suivant qui peut marcher aussi : 'sudo SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK ma_commande'.
Pour répondre à votre question: un process root aura les permissions nécessaire sur la socket unix de l'user donc ça marche. !

En fait l'option -E de sudo préserve l'environement c.-à-d. tes variables SSH_* pour que le process root se connecte à l'agent de l'user. (Il y a peut-être qq chose à activer du côté de /etc/sudoers, je ne me souvient plus.) ssh-add -L c'était juste pour prouver que le process root se connecte bien à l'agent de l'user. De suite l'intégration avec kwallet ou que sais-je est transparente il me semble…

[HS] Bonsoir, auriez-vous l'aimabilité de me dire si la solution proposée dans votre dernière question sur le forum est pertinente ? Merci.

En gros tu veux lancer des ssh -L port:remote:remoteport avec port < 1024, n'est-ce pas ?

Ce que je cherche c'est à avoir au minimum un ssh-agent pour root au boot du système. Le reste c'est cosmétique.

Je ne suis pas sur de suivre ton raisonement… Quel est l'interêt ? Tu veux pouvoir manipuler un trousseau "global" par ton user (ou par sudo) afin que tes scripts ne te demande plus aucun mot de passe, est-ce donc cela ? Personnelement, je ferais l'inverse cf. plus bas… Enfin soit puisque c'est ce que tu as gentillement demandé…

dans rc.boot, rc.local ou le truc qui va bien pour ta distrib:
ssh-agent > /root/ssh-agent.env

dans /etc/bash.bashrc ou le truc qui va bien pour ton shell
if [ `id -u` -eq 0 -a -r /root/ssh-agent.env ]; then source /root/ssh-agent.env ; fi

Bon c'est assez dégueu, ça ne vérifie pas que le ssh-agent est encore là,… 'fin ce serait plus ou moins l'idée. Est-ce que ça te convient ?

Ceci dit je ferais l'inverse, je demanderais à mes "scripts de connections" d'interroger le ssh-agent de l'user… Alors chez moi sudo -E /bin/bash -c "echo \$SSH_AGENT_PID; ssh-add -L" fonctionne et permet de lancer ssh en root mais en utilisant le trousseau de l'user… Est-ce que cela pourrait te convenir ? Sinon merci d'expliquer ton problème de façon plus explicite pour que l'on puisse t'aider… Aussi pourquoi tiens-tu absolument vouloir lancer ces scripts en root, vu que ce n'est pas une question de port <1024, quelle est la raison ? Merci d'avance de satisfaire à ma curiosité :)

Sinon le coup d'iptables ça marche aussi, il suffit de rediriger le port <1024 sur un port que l'user peut binder.

ah ben merci :-) /me se sent un peu con d'être passé à côté du coup…
Donc une solution pour créer un sparse file est `truncate -s 100M fichier', avec les problèmes associés de fragmentation et d'exhaustion possible de l'espace disque à posteriori.

Maintenant ce dont Christophe a vraiment besoin et qui est mentioné par netsurfer est bien fallocate. Chez moi il y a un utilitaire qui fait partie du paquet util-linux et il s'utilise comme suit : `fallocate -l $((1024*1024*100)) fichier'.

Bon aller, sans utiliser dd il suffit d'utiliser l'appel système ftruncate (ou ftruncate64 si gros fichiers). Je n'ai pas trouvé d'utilitaire servant de surcouche mais bon créer une implémentation en C est simple, voir triviale en python, cf.: http://www.tutorialspoint.com/python/os_ftruncate.htm

De la man page : « If the file previously was larger than this size, the extra data is lost. If the file previously was shorter, it is extended, and the extended part reads as null bytes ('\0').»

Je ne comprends pas comment ils gagnent de l'argent avec ce truc. En jouant sur le volume et en pariant que la plupart des gens n'utiliseront que peu de ressources et resteront fidèles des années durant ? Un an d'abonnement couvrirait juste l'achat d'un DD. Quid des autres frais ? Je reste perplexe…

Si tu passes quand même le pas BSD, penses à jetter un oeil sur DragonFly et HAMMER qui gèrent aussi la déduplication "offline" (ou différée) en version stable et en "live" en version expérimentale.

http://www.shiningsilence.com/dbsdlog/index.php?s=dedup
http://www.dragonflybsd.org/docs/docs/howtos/howtosoftwareraid/
http://ask.slashdot.org/story/12/01/04/1955248/ask-slashdot-freeopen-deduplication-software

Hello,

Avez-vous connaissance de http://harbour-project.org et auriez-vous déja envisagé une migration de vos applications clipper dessus ? Effectivement, il y aura probablement le code d'impression à modifier pour avoir un fonctionnement satisfaisant sous linux (tel est mon constat suite à un portage d'une application modeste). Néanmoins, même si le changement d'OS n'est pas à l'ordre du jour, il n'en demeure pas moins qu'il reste la possibilité de migrer vers un compilateur et un éco-système ouvert (et... vivant...) ;-)

En plus y a un bar sympa avec de bonnes bières pas trop chères (à consommer après la session) :-)

http://fosdem.org/2012/certification

Le SCOOP c'est pas le programmateur fonctionnel qui vient de découvrir la programmation orienté objet ? ( pun intended :P )