gaaaaaAab a écrit 1393 commentaires

ok, je me demandais si un simple wc -l suffisait (mais grep -c, c'était incontestablement mieux), mais vu ce commentaire, la réponse est non.

ton xargs | awk pour récupérer la dernière ligne peut se remplacer par un tail

et grep | awk | cut par un sed

Du coup :
grep mail.server.server'.*'.type prefs.js | sort -n |tail -1 | sed 's/.\{29\}\([0-9]*\).*/\1/'

sed '/keyword1\|keyword2/ { s/keyword3//g}'

raisonnement logique, mais le monde de l'entreprise n'est pas toujours rationnel.
Il arrive que des choix technologiques soient fait pour des raisons purement arbitraires. Ca va du "le patron de cette boite c'est mon copain alors on choisit sa technologie" à "on ne peut pas dépendre d'un seul fournisseur alors on va prendre le produit de machin même s'il est moins bien que celui de bidule".

sur le principe, avec un makefile du genre:


$ cat makefile

all: cmd1 cmd2

cmd1:
while [ 1 ]; do echo "hu"; sleep 5; done

cmd2:
while [ 1 ]; do echo "ha"; sleep 3; done
.PHONY: cmd1 cmd2


ensuite:
$ make -j 2
while [ 1 ]; do echo "hu"; sleep 5; done
hu
while [ 1 ]; do echo "ha"; sleep 3; done
ha
ha
hu
ha
ha
hu


en oubliant pas que make exige des tabulations en début des lignes de commande (ici, devant chaque while), mais je ne sais pas comment faire apparaitre ça proprement sur linuxfr.
pour toi, ça sera make -j 8 (man make)

yapuka(c) écrire une moulinette pour générer le makefile (parce que se cogner les 400 commandes à la main, c'est pas glop) et roule :)

je me répète, mais comme tu sembles n'avoir pas lu mon autre commentaire, mettre de l'eau sur un livre ne le rend pas inutilisable.
Je comprends que ça t'embêtes pour ta démonstration, mais un livre, c'est pas *si* fragile que ça. Quant à la pérennité des livres électroniques, je veux bien te suivre sur le plan théorique, mais admet qu'on manque un petit peux de recul sur la question.

Une fois qu'on aura bien trollé pour décider si le livre électronique est mieux que le livre papier, ça nous dira pas si le grand public suivra.

D'après ce que je vois sur le grand 'Ternet, sont considérés comme gros lecteurs les gens qui lisent plus de 20 livre par ans [1]. Chiffre non recoupé, j'ai vu le chiffre de 12 ailleurs (mais je ne sais plus ou).

Je ne sais pas quelle est la proportion de gros lecteur dans la population. Ca demanderait plus de recherche documentaire.
En tout cas, si on se réfère au premier paragraphe de [2] citant une étude de TNS Sofres (Mars 2008):
le nombre de livres lus est en baisse : si 42 % des Français lisaient plus de cinq livres en 1983, ils ne sont plus que 34 % aujourd'hui

Les gens vont-il vraiment acheter des ebooks en masse pour s'en servir 5 fois par an ?

A tempérer, puisque d'après [3], la lecture ne serait pas en perte de vitesse. Mais comme le contenu est payant, on a pas le détail.

[1] http://www.grinzane.net/Osservatorio2003/Osservatorio2003_FR(...)
[2] http://www.actualitte.com/actualite/1315-lecture-France-habi(...)
[3] http://www.scienceshumaines.com/index.php?id_article=4988&am(...)

Hop un verre d'eau et tu perds ton livre.
il est hyper-dépendant d'un verre d'eau mal placé

heu ... non. D'après mon expérience, même avec une bouteille d'eau complète (mal refermée qui se vide dans tout le sac à dos), le livre résiste.
Certes, il est gondolé à mort, mais l'encre et le papier tiennent bien.

en plus, le livre, il résiste probablement au micro onde, alors que pas l'e book.
Alors, on fait moins le malin ? :o)

--> []

effectivement, les systèmes de fichiers habituellement utilisés sous Unix stockent la date de dernière modification, et pas la date de création. Et effectivement, c'est parfois génant.

Pour répondre aux autres questions du message de départ, la date de dernier accès à un fichier (le atime) est disponible. On peut la voir avec la commande
stat fichier
ou avec ls (mais probablement pas du tout portable)
ls -l --time atime fichier

Attention cependant, pour gagner quelques pouillèmes en performance en lecture (sur les gros systèmes très sollicités, ça peut faire des gros pouillèmes), les systèmes de fichiers sont parfois montés avec l'option noatime. Dans ce cas, les dates d'accès ne sont pas mis à jour dans les inodes des fichiers.
Tant que j'y suis, les atime, en fait, osef. En tout cas, je n'en ai jamais eu besoin jusqu'à présent, et je ne connais (en tout cas, pour l'instant) aucun soft qui s'en serve.

Pour finir, les outils habituels d'archivage sont sympas, ils préservent les dates des fichiers, donc pas la peine de s'embêter à fabriquer une liste à côté. Les fichiers sauvegardés auront les mêmes attributs fonctionnels que les fichiers originaux (uid, gid, permissions, dates diverses et variées).
Même la commande cp peut préserver ces attributs si on lui demande gentiment (man cp) !

Mais ça, avec quelques tests de ton côté, t'aurais pu répondre tout seul ;)

Le protocole SMS était à l'origine un système interne pour tester la ligne.

heu ... non. Le protocole SMS sert à pleins d'autres trucs que d'échanger des messages de type texte.

Par contre, possible que ça devienne vrai si on transforme la phrase en :
les SMS au format texte était à l'origine un système interne pour tester la ligne
mais il faudrait des gens dans le secteur depuis plus longtemps que moi pour confirmer.

... désolai pour les fôtes

(et qui semble être mal implémenté)

en fait, il y a plusieurs classes de SMS. Parmi les SMS affichables, il y en a deux sortes, ceux interprétés par le mobile qui s'affiche une fois et ne sont pas stockés, et ceux à destination de la carte SIM qui peut en stocker un certain nombre (défini au moment de la personnalisation de la carte). Vu le format du système de fichier GSM, le maximum théorique est de 255 SMS. Les anciennes cartes à puce ne supportent souvent pas le stockage de plus de 10 SMS (parce que ça prend de la place et les opérateurs veulent réduire le coup des cartes SIM en payant des composants de moindre capacité, donc moins chers).

Pour les SMS concaténés, il y a aussi une limitation au niveau de la carte. Les différents fragments sont stockés dans un tampon qui fait n * 133 (140 ou 160 en fait, avec les en-tête, la flemme de chercher), mais n vaut rarement 255 (aussi un paramètre de personnalisation).

Pour pallier les limitations des cartes SIM là dessus, les téléphones modernes permettent aussi de gérer les SMS reçus et envoyés dans la mémoire du téléphone. Avantage : on peut en stocker pleins. Inconvénient, quand on change la SIM de tél, on ne transporte pas l'historique.

Pour conclure, c'est globalement le gros bins, parce que le nombre max de fragments d'un SMS concaténé dépend du modèle de la carte (et il y a une tripotée de modèle et chaque modèle est décliné suivant une tripotée de personnalisation) et des capacités du tél.

Je comprends du coup que les opérateurs ne communiquent pas trop là dessus, parce qu'ils ne peuvent pas garantir un fonctionnement homogène pour tous leurs abonnés.

oui, bien vu.
Moment nostalgie : en prépa, sur les PCs, l'environnement Windows était très très limité. Par contre, l'IDE qu'on utilisait (ça devait être du Borland Pascal, ça nous rajeunit pas) avait une chouette menu pour ouvrir un shell dos =)

ok, j'en déduis que tu as rencontré des problèmes (probablement contournables en y passant un peu de temps) dans l'implémentation d'un script particulier, mais pas de critique de fond sur le mécanisme.
merci pour les précisions

heu ... ça m'arrive de faire ça et je ne vois pas quels problèmes ça soulève. Au contraire même, je trouve ça très bien :)
Du coup, ça m'intéresserait que tu développes sur ce que tu vois de négatif là dedans.

ah ... manifestement, je suis total à côté de la plaque là :
cf http://linuxfr.org/comments/1091331.html#1091331

donc 4100 € ? ;-)

de ce que j'en avais compris, l'idée du port knocking part du constat que les méchants pirates^w script kiddies tentent de casser les mots de passe faibles pour les utilisateurs habituels sur les ports standards (genre le mdp root/admin/www-data ou autre sur ssh).

L'idée du port knocking est que le port 22 soit fermé par défaut, et que seule une combinaison de ping sur des ports dans un ordre déterminé l'ouvre pendant quelques minutes.
Ensuite, c'est une connexion ssh classique avec authentification classique.
Au bout d'un certain temps (configuré quelque part), le port 22 se referme.

Pour tout attaquant scannant les ports en dehors de cette plage de quelque minutes, la probabilité qu'il scan les ports dans le bon ordre étant faible, le service ssh n'est pas accessible (donc pas troutable)

ce que tu décris (grosso modo, l'envoi d'un challenge), c'est finalement l'authentification par clefs . Ca existe aussi, mais c'est pas du port knocking.

je suis pas sûr que ça répond à la question de départ, mais ce que tu écris là, ça serait plus joli comme ça:

SELECT t1.id
FROM table_contenant_toutes_les_ids t1
WHERE NOT EXISTS (SELECT 1 FROM table_des_ids_réservés t2 WHERE t1.id = t2.id)


;-)
sur ce coup là, je n'aurais pas pu écrire ça sans ton commentaire.

Le hold space, c'est le genre de trucs ou on se demande après coup comment on a pu passer à côté si longtemps ...
Je compte plus le nombre de trucs que j'ai appris sur programmation.shell, je l'aime bien ce forum :)

et en élaborant encore un peu (pour couper les blocs incomplets en fin de fichier, même si ce n'était pas demandé) :

sed -n '/TIMESTAMP/,/OUT/{
/TIMESTAMP/ { h }
/IN/ { H }
/OUT/ {
H
x
p
}
}' ./path/to/file


a y est, je suis fan du hold space :)

ton script m'a fait farfouiller le man =)

On peut le raccourcir un tout petit peu en omettant le label, puisque d'après le man (et confirmé par mes tests), lorsqu'il est omis, ça branche en fin de script.

Sinon, avec sed, on peut aussi travailler par bloc de lignes (pas seulement en ligne à ligne), et ça permet de simplfier :

sed -n '/TIMESTAMP/,/OUT/{
/IN\|OUT\|TIMESTAMP/{
p
}
}' /path/to/file


à noter que dans ces deux versions, on affiche le début du dernier bloc TIMESTAMP/IN/OUT même s'il est incomplet.

par "requête SQL plus courte", tu parles de la longueur de la chaîne de caractères qui contient la requête ? ou de la conso mémoire lors de son exécution ?

j'aurais presque envie de faire un multi pour pouvoir te re plusser :-)

C'est mieux?
En mettant de côté le "petit" problème opérationnel avec RMS (le clônage n'existe pas ;-), envisageons un logiciel pas libre qui forge des captures d'écran de logiciel libre et qui les envoie toutes les secondes (au lieu d'une seule fois).

Quand l'utilisateur veut se connecter, le serveur lui envoie la fameuse fonction d'authentification générée pseudo-aléatoirement. Là l'utilisateur dispose de 3 minutes pour compiler le client et se connecter avec. Le role de la fonction c'est qu'elle doit être réputée très difficile a analyser et réimplémenter en 3 minutes. Donc l'utilisateur ne pourra en 3 munites n'utiliser que celle là.

Je pense qu'en quelques dizaines de connexion, un attaquant aura suffisamment de billes pour distinguer les quelques classes de ces fonctions (vu comme c'est déjà pas simple d'en fabriquer ne serait-ce qu'une seule, je ne suis pas convaincu que ça soit très faisable d'en générer pleins à la volée), analyser tranquillement et écrire du code pour gérer tous les cas.
Sinon, pas la peine de s'embêter, suffit de s'en servir une fois dans un client libre dans la plage des 3 min, en espionnant la mémoire ou les traces réseaux, et les quelques informations utiles sont accessibles.

Vu tout ce que tu lui demandes de faire à cette fameuse fonction, c'est plus une fonction, c'est un logiciel ! Ce qui nous ramène au cas précédent. Il suffit de comprendre le protocole entre cette fonction et le serveur pour la ré implémenter sans l'utiliser.

Le problème fondamental, c'est que tu dois donner au client des moyens pour se connecter, et, tu peux essayer tout ce que tu veux pour essayer d'obscurcir le mécanisme d'authentification, in fine, la machine cliente dispose toujours des informations nécessaires à la connexion. Du coup, ça sera toujours contournable par quelqu'un d'expérimenté (cf toutes les majs d'Itunes).

La liberté n'a pas de prix!
En même temps, il me semblait que pour la GPL, l'idée, c'était de protéger les liberté tant des développeurs que des utilisateurs. Si on ne s'occupe de protéger la liberté que d'un point de vue dogmatique (il faut que ça doit libre parce qu'il faut que ça soit libre), ça perd un peu de son sens.

En fait, on mélange un peu deux choses dans ce débat j'ai l'impression : la liberté du code et l'ouverture d'un service. Et là, on n'essaie de calquer les notions de liberté (qu'on a l'habitude de voir pour le code) sur un hybride code/service, et amha, ça marche pas bien :)

voui, je ne peux que présenter mes plates excuses pour cette erreur grossière :)

Effectivement, tant qu'il n'y a pas de redistribution, y a pas de question.

précaution d'usage : IANAL (je ne suis pas juriste)

Par conséquent, j'imaginais qu'une donnée (au sens large), nécessaire pour se connecter au service, licenciée en gplv3, s'apparentait à du code source et donc ne pouvait être "fermée".

sauf qu'en droit, y a pas beaucoup de place pour l'imagination (ni pour l'imprécision d'ailleurs).
"Une donnée s'apparentant à du code source", j'avoue avoir du mal à cerner ce que ça veut dire :)
Le code source est protégé, pas ce qu'il fait (il n'y a pas de brevets logiciels en Europe). Du coup, réimplémenter un algorithme utile à une interaction avec du soft GPL n'en fait pas (à mon avis) une violation de la GPL.

Pour finir, en dehors du fait qu'on peut s'interroger sur ce que signifie le mot libre dans un tel contexte, à part des conditions d'utilisations strictes, l'enregistrement de tous les utilisateurs, des mécanisme techniques (pas très fiables) pour détecter les violations des conditions et des mécanismes de fermeture de compte, je ne vois pas trop.
Mais là, ça sort du cadre de la technique.