D'après le code, il y a un double rot13 sur le mot de passe, ce qui le ramène à sa version de départ. Donc ce serait plutôt le login uniquement qui serait stocké en rot13 (va savoir pourquoi...).
On n'a pas dit qu'il n'y avait que 100 ports ouvrables, on a parlé de ports ouverts simultanément (100 connexions TCP). Et si tu sais comment fonctionne le NAT en IPv4, c'est absolument normal : le routeur en sortie maintient une table et traduit les ports, il doit répartir équitablement entre tous les clients.
Sondant ton principal outil du WWW du mot anglais pour « mathurin », l'inquisition fournira pour solution tout sauf « Chromium ». Par componction ? Non, plutôt par subordination aux flics anti-spams qui ont vu l'immoral truc du backlink payant. Accusation d'implication : il jurait tantôt « non ! », l'artisan agissant pour sa communication faisant un parfait fautif.
Pourtant, nous constatons aujourd'hui la volatilisation pour 60 jours, voyant ainsi www.chromium.org trahi par son papa.
Non, justement c'est tout le contraire : dans sysvinit les démons doivent se détacher pour que le script puisse retourner après que tu appelles start.
En gros, dans sysvinit, les scripts servent juste à lancer et arrêter les démons, en espérant qu'ils continuent à s'exécuter correctement dans l'intervalle (en se détachant par double fork). Et dans runit, à l'inverse, les démons restent attaché au processus runsv qui les a lancé, et qui peut donc détecter quand ils meurent et les relancer immédiatement (enfin avec un délai d'une seconde pour éviter de surcharger ton CPU si un démon se plante à répétition). C'est évidemment l'approche de runit qui est la bonne : essayer de maintenir de l'état sans surveiller comme sysvinit, c'est voué à l'échec.
En fait non, tu vas utiliser un script shell dans quasiment tous les cas, pour passer les options à ton démon (rarement, un lien symbolique vers l'exécutable suffira). Par contre, si un démon fait systématiquement un double-fork, il est vraiment incontrôlable pour runit et ça ne marchera pas du tout (ou alors il faudrait vraiment un script très complexe qui reste attaché et face l'interface et le "polling" du démon d'une manière ou d'une autre, un peu comme systemd il me semble).
Mais encore une fois, je ne connais pas d'exemple de démon qui ne propose pas cette option.
C'est exactement pour ça que runit est fait, et il fonctionne plutôt bien. Il faut juste que les services supportent le fait de ne pas se démoniser (double fork), mais rester attachés au processus qui les a lancés. Et ça ne fait tous les trucs magiques de systemd (comme les socket activation) mais le style « séparons clairement les rôles, faisons des utilitaires de moins de 400 lignes de code et construisons un système propre avec », c'est efficace.
(Après, je n'aime pas du tout le style du code, largement repompé des daemontools de Bernstein.)
Un dossier unique. Par défaut, les mails ont un flag "Important", sauf ceux qui ne le sont pas (mailing-lists, logs, etc.). Quand la tâche est accomplie, j'enlève le flag (ou je supprime le mail). Dans mutt ou roundcube, je filtre pour ne voir que les mails avec un flag : sur cette vue limitée, ça me fait donc une TODO list, avec comme but un "zéro inbox".
Avantage : ça n'utilise pas le statut lu/non-lu pour quelque chose qu'il n'est pas (à faire/fait).
Inconvénient : ça ne marche pas pour les tâches loin dans le futur, qui traînent dans la vue par défaut. Pour ça, un patch à mutt permet d'appliquer des tags plus fins, mais je m'en sers peu en pratique.
Si je retrouve le lien où j'ai trouvé cette organisation, je le reposterai ici.
Il y a certains fonctions POSIX qui se comportent de manière exotique (pour être poli) sous OS X. Ça rend le portage d'applications intéressant... un peu comme porter un site pour Internet Explorer.
Ça ne va pas fonctionner : le mode non-bloquant ne marche que pour les tubes (pipes) ou le réseau. Les écritures sur disque sont toujours potentiellement bloquantes, ou pour le dire autrement select te dira toujours « le disque est prêt » (parce qu'effectivement le disque est toujours prêt, il est juste lent).
Il n'existe pas de solution totalement satisfaisante mais les deux approches classiques sont les suivantes :
Utiliser des entrées/sorties asynchrones (async I/O) : il y a une API POSIX pour ça. La référence avec la GNU libc : http://www.gnu.org/s/hello/manual/libc/Asynchronous-I_002fO.html#Asynchronous-I_002fO. Problème majeur : en fait, ça ne marche pas, ou alors pas très efficacement. Si je ne me trompe pas, la libc utilise des threads par derrière pour l'implémenter, il n'y a pas de support direct du noyau.
Utiliser un fichier mappé en mémoire, avec prefetch : l'idée est d'utiliser mmap pour accéder au fichier comme une zone mémoire, puis madvise(POSIX_MADV_WILLNEED) pour dire qu'on va avoir besoin d'un bout du fichier. Ensuite, mincore permet de savoir si une partie du fichier est en cache, donc si le prefetch demandé par madvise a été honoré, et si tu vas effectivement bloquer. Référence : http://www.gnu.org/s/hello/manual/libc/Memory_002dmapped-I_002fO.html#Memory_002dmapped-I_002fO Problèmes : en théorie madvise et mincore peuvent bloquer, et surtout je ne sais pas si c'est utilisable pour faire des écritures non-bloquantes (je suppose que non). C'est surtout une technique pour les lectures non-bloquantes.
Dans ton cas, je suppose qu'utiliser les async I/O de POSIX ou mettre en place ton propre thread est la meilleure solution.
Et pour aller plus loin, que les conspirationnistes demandent à l'état américain de mener une enquête, pourquoi il n'y a pas de rapport, etc. Mais que de leur point de vue, de toute manière, toute source officielle, venant de cet état, est soupçonnée de mensonge a priori.
[^] # Re: Mhh
Posté par MrLapinot (site web personnel) . En réponse au journal SOPA pénible. Évalué à 5.
De toute façon, ses livres sont sous GFDL avec section invariante, qui n'est même pas libre.
[^] # Re: Stockage des mots de passes
Posté par MrLapinot (site web personnel) . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 5.
D'après le code, il y a un double rot13 sur le mot de passe, ce qui le ramène à sa version de départ. Donc ce serait plutôt le login uniquement qui serait stocké en rot13 (va savoir pourquoi...).
[^] # Re: Internet quoi
Posté par MrLapinot (site web personnel) . En réponse à la dépêche Free lance son offre mobile : ce que ça change. Évalué à 6.
Tu peux dire ça. Mais c'est faux (ou au moins incomplet).
[^] # Re: Internet quoi
Posté par MrLapinot (site web personnel) . En réponse à la dépêche Free lance son offre mobile : ce que ça change. Évalué à 10.
On n'a pas dit qu'il n'y avait que 100 ports ouvrables, on a parlé de ports ouverts simultanément (100 connexions TCP). Et si tu sais comment fonctionne le NAT en IPv4, c'est absolument normal : le routeur en sortie maintient une table et traduit les ports, il doit répartir équitablement entre tous les clients.
[^] # Re: dtrace un jour ?
Posté par MrLapinot (site web personnel) . En réponse à la dépêche Le noyau Linux 3.2 est disponible. Évalué à 1.
Si tu as testé dd après cat sans vider ton cache, forcément, tu ne vois plus la différence (le fichier est déjà en cache).
[^] # Re: La Disparition, par Mr Lapinot
Posté par MrLapinot (site web personnel) . En réponse au journal La disparition. Évalué à 9.
Tu en as laissé passer un ;-)
[^] # Re: LaTeX
Posté par MrLapinot (site web personnel) . En réponse au journal Pour une disponibilité des articles de revues scientifiques au format Epub. Évalué à 2.
Vu le délai de rafraîchissement des pages, rajouter un délai d'une demi-seconde pour le calcul ne serait qu'à peine plus gênant.
# La Disparition, par Mr Lapinot
Posté par MrLapinot (site web personnel) . En réponse au journal La disparition. Évalué à 10.
Mais où a disparu Chromium ?
Sondant ton principal outil du WWW du mot anglais pour « mathurin », l'inquisition fournira pour solution tout sauf « Chromium ». Par componction ? Non, plutôt par subordination aux flics anti-spams qui ont vu l'immoral truc du backlink payant. Accusation d'implication : il jurait tantôt « non ! », l'artisan agissant pour sa communication faisant un parfait fautif.
Pourtant, nous constatons aujourd'hui la volatilisation pour 60 jours, voyant ainsi www.chromium.org trahi par son papa.
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Non, justement c'est tout le contraire : dans sysvinit les démons doivent se détacher pour que le script puisse retourner après que tu appelles start.
En gros, dans sysvinit, les scripts servent juste à lancer et arrêter les démons, en espérant qu'ils continuent à s'exécuter correctement dans l'intervalle (en se détachant par double fork). Et dans runit, à l'inverse, les démons restent attaché au processus runsv qui les a lancé, et qui peut donc détecter quand ils meurent et les relancer immédiatement (enfin avec un délai d'une seconde pour éviter de surcharger ton CPU si un démon se plante à répétition). C'est évidemment l'approche de runit qui est la bonne : essayer de maintenir de l'état sans surveiller comme sysvinit, c'est voué à l'échec.
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
En fait non, tu vas utiliser un script shell dans quasiment tous les cas, pour passer les options à ton démon (rarement, un lien symbolique vers l'exécutable suffira). Par contre, si un démon fait systématiquement un double-fork, il est vraiment incontrôlable pour runit et ça ne marchera pas du tout (ou alors il faudrait vraiment un script très complexe qui reste attaché et face l'interface et le "polling" du démon d'une manière ou d'une autre, un peu comme systemd il me semble).
Mais encore une fois, je ne connais pas d'exemple de démon qui ne propose pas cette option.
[^] # Re: Ni pour ni contre, bien au contraire …
Posté par MrLapinot (site web personnel) . En réponse au journal L'édition des commentaires sur LinuxFR, ou pas ?. Évalué à 6.
J'ai un doute : pour « compteur », tu as fait exprès ?
[^] # Re: stop
Posté par MrLapinot (site web personnel) . En réponse au journal Libre vs Open Source - Faisons le point. Évalué à 3.
Euh, ce n'est pas à toi qu'il répondait mais à Zenitram, non ?
(Certes, Zenitram n'a pas d'avatar.)
[^] # Re: stop
Posté par MrLapinot (site web personnel) . En réponse au journal Libre vs Open Source - Faisons le point. Évalué à 4.
Les gens n'ont vraiment aucun sens de l'humour ici.
J'ai ri, et plussé.
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
C'est exactement pour ça que runit est fait, et il fonctionne plutôt bien. Il faut juste que les services supportent le fait de ne pas se démoniser (double fork), mais rester attachés au processus qui les a lancés. Et ça ne fait tous les trucs magiques de systemd (comme les socket activation) mais le style « séparons clairement les rôles, faisons des utilitaires de moins de 400 lignes de code et construisons un système propre avec », c'est efficace.
(Après, je n'aime pas du tout le style du code, largement repompé des daemontools de Bernstein.)
# Dossier unique et flags
Posté par MrLapinot (site web personnel) . En réponse au journal Tri des mails. Évalué à 2.
Un dossier unique. Par défaut, les mails ont un flag "Important", sauf ceux qui ne le sont pas (mailing-lists, logs, etc.). Quand la tâche est accomplie, j'enlève le flag (ou je supprime le mail). Dans mutt ou roundcube, je filtre pour ne voir que les mails avec un flag : sur cette vue limitée, ça me fait donc une TODO list, avec comme but un "zéro inbox".
Avantage : ça n'utilise pas le statut lu/non-lu pour quelque chose qu'il n'est pas (à faire/fait).
Inconvénient : ça ne marche pas pour les tâches loin dans le futur, qui traînent dans la vue par défaut. Pour ça, un patch à mutt permet d'appliquer des tags plus fins, mais je m'en sers peu en pratique.
Si je retrouve le lien où j'ai trouvé cette organisation, je le reposterai ici.
[^] # Re: Il est vrai
Posté par MrLapinot (site web personnel) . En réponse au journal Steve Jobs décortiqué dans le New Yorker. Évalué à 3.
C'est pas pour dire, mais depuis 2008 quasiment tous les logiciels de Bernstein sont dans le domaine public :
http://cr.yp.to/distributors.html
(OK, il a mis du temps à changer d'avis, mais pour Steve Jobs, on peut attendre le revirement encore longtemps.)
[^] # Re: Jobs est cité dans le livre de management
Posté par MrLapinot (site web personnel) . En réponse au journal Steve Jobs décortiqué dans le New Yorker. Évalué à 6.
Il y a certains fonctions POSIX qui se comportent de manière exotique (pour être poli) sous OS X. Ça rend le portage d'applications intéressant... un peu comme porter un site pour Internet Explorer.
Puisqu'on va me demander d'argumenter, lire par exemple la section suivante du manuel de libev : http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS
[^] # Re: Les annonceurs forcement
Posté par MrLapinot (site web personnel) . En réponse au journal Ma vie : moi qui allait publier mon code en GPL.... Évalué à 4.
La moitié de leurs CGU, ils n'ont pas le droit de les imposer légalement. Ça n'empêche pas de les faire écrire (fort cher) par un juriste.
[^] # Re: Pas sur que ce soit une bonne idée
Posté par MrLapinot (site web personnel) . En réponse au journal Bureaux debout réglables en hauteur, ça se vend vraiment ?. Évalué à 2.
La solution : http://rwmj.wordpress.com/2010/01/25/treadmill-desk-part-6-hopefully-the-final-summary/
[^] # Re: non-blocking I/O
Posté par MrLapinot (site web personnel) . En réponse au message Ecritures disques non bloquants. Évalué à 3.
Ça ne va pas fonctionner : le mode non-bloquant ne marche que pour les tubes (pipes) ou le réseau. Les écritures sur disque sont toujours potentiellement bloquantes, ou pour le dire autrement select te dira toujours « le disque est prêt » (parce qu'effectivement le disque est toujours prêt, il est juste lent).
Il n'existe pas de solution totalement satisfaisante mais les deux approches classiques sont les suivantes :
Dans ton cas, je suppose qu'utiliser les async I/O de POSIX ou mettre en place ton propre thread est la meilleure solution.
# Lapin
Posté par MrLapinot (site web personnel) . En réponse au journal Commit Logs From Last Night . Évalué à 10.
Ça a l'air cool, ou au moins parfois rigolo, mais je ne comprends rien.
Ce sont des commits, OK. Pris sur github, OK. Mais sélectionnés comment, par qui ? C'est un concours du commit le plus trash ?
Bref, les journaux bookmarks, pourquoi pas, mais au moins avec une ligne d'explication...
[^] # Re: skoistruc ?
Posté par MrLapinot (site web personnel) . En réponse au journal Pour les développeurs qui en ont dans le slip. Évalué à 5.
Le google analytics libre, c'est Piwik. Piwigo, c'est l'alternative à Picasa.
[^] # Re: Mise à jour automatique
Posté par MrLapinot (site web personnel) . En réponse à la dépêche Firefox Sept : consommation mémoire nettement améliorée. Évalué à 2.
Mozilla distribue des binaires Firefox 64 bits ? Où ça ? (vraie question)
[^] # Re: euh, comment dire ?
Posté par MrLapinot (site web personnel) . En réponse au journal La Saône et Loire libère ses données. Évalué à 8.
La licence et les formats ne sont pas forcément au rendez-vous.
Une synthèse plutôt équilibrée : http://libertic.wordpress.com/2011/09/29/l-open-data-du-cg71-ce-qui-va-changer-en-france/
[^] # Re:Mégabullshit
Posté par MrLapinot (site web personnel) . En réponse au journal 11 septembre: où en est-on ? . Évalué à 7.
Et pour aller plus loin, que les conspirationnistes demandent à l'état américain de mener une enquête, pourquoi il n'y a pas de rapport, etc. Mais que de leur point de vue, de toute manière, toute source officielle, venant de cet état, est soupçonnée de mensonge a priori.