gaaaaaAab a écrit 1387 commentaires

pour comprendre, il faut revenir aux raisons pour lesquelles SCO a porté plainte. En gros, si j'avais bien suivi à l'époque, IBM avait acheté à SCO le droit de voir les sources de l'Unix d'ATT mais avec un NDA assez sévère. Des gens d'IBM ont contribué à Linux.
SCO affirme que les employés d'IBM qui ont contribué à Linux sont les même que ceux qui avaient accès au code d'Unix, et que donc le noyau Linux est un derivative work d'Unix.

Rien de tel pour les *BSD (qui sont bien des unix, mais pas dans le périmètre de la plainte de SCO)

Ne rentrons pas dans le détail de la qualité de l'argument, tout a été soigneusement démonté à l'époque. Relisez groklaw comme suggéré dans un autre commentaire. Il serait temps de laisser ce troll mourir ;)

Réécrire des bouts du noyau (ou autre), c'est déjà galère
certes. Et ? C'est impossible ?

ou alors j'ai loupé quelque chose cette été !!!
ouais, mais c'était pas cet été. Depuis quelques temps déjà, Debian expérimente l'intégration d'autres noyaux que Linux. Y a eu une Debian/Hurd, des Debian/BSD.
Il me semble que c'est d'ailleurs pour ça que les packages du noyau (autrefois kernel-2.6*) ont été renommé en linux-image-2.6*.

sinon, je l'ai peut-être mal dit dans mon commentaire, mais pour moi, le vraiment pire qui pourrait arriver serait de devoir ré écrire des bouts de noyau. Maintenant, la probabilité qu'on en arrive jusque là est vraiment très faible, et vraiment pas à court/moyen terme.
Dans l'absolu, je prétend aussi que la fin du noyau Linux ne signe pas la fin du logiciel libre, et ça, ça me parait difficilement contestable.

Pour finir, c'est une histoire qui va se régler entre SCO, Novell, IBM, Redhat, ... Ca prendra du temps parce que les machins légaux entre grosses boites prennent toujours du temps, mais je serais vraiment surpris que ça sorte un jour de ce périmètre.

C'est simplement le titre du journal que je remet en cause.

mais y a pas beaucoup d'enjeu pour le "Libre".

Le pire qui pourrait arriver, c'est que les développeurs du noyau Linux soient obligés de réécrire des bouts du noyau. C'est tout.
Soyons ultra pessimistes, y a plus le droit d'utiliser Linux du tout, ça sera l'occasion de se pencher sérieusement sur debian/bsd !

bref, déjà que je ne me faisais pas trop de soucis pour Linux, je m'en fais encore moins pour le "Libre".

et accessoirement pour qu'il soit frais quand t'aimes bien le lait frais

tu peux peut-être aussi creuser du côté des templates genre Cheetah [1] ou autres

[1] : http://www.cheetahtemplate.org/

pour compléter, plus elle est grande et plus elle est remplie, plus fsck est long
Vivement btrfs !

je viens de jeter un oeil au man. En fait, si, on peut en awk, et c'est en fait beaucoup plus simple (donc beaucoup moins rigolo ;) qu'en sed ...
pour reprendre mon exemple précédent :
echo $ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 |awk '{print substr($0, 22, 4) " " substr($0,47, 9) " " substr($0,56,9)}'
BCDE ghijABCDE FGHIJ1234


bon, on peut dégainer du sed alors, mais ça va pas être très lisible ...
Par exemple, pour les intervalles de ta question de départ ("22-25,47-55,56-64")

$ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 |cut -c"22-25,47-55,56-64"
BCDEghijABCDEFGHIJ1234


D'après ton propre aveu, tu n'es pas une grosse brute en sed, on va donc construire la commande pas à pas. Tu peux aller te faire peur en allant direct à la fin du commentaire, mais une fois que tu auras lu ce petit pavé, ça devrait être claire comme de l'eau à peine croupie ;)

On va utiliser sed suivant la syntaxe suivante :
sed -e 's/<pattern>/<replacement>/'
qui permet d'appliquer une regex. Dans cette regex, il faut définir un motif capable de représenter les découpes qu'on veut faire dans la ligne de départ.

rapidement :
^ symbolise le début de ligne
. remplace une occurence d'un caractère quelconque
{ et } permettent de "compter" des motifs
( et ) permettent d'extraire les bouts de lignes pour les réutiliser dans la chaîne de remplacement.
* match n occurences du motif qu'il suit.

Pour le motif de recherche, on peut construire quelque chose comme:
^.{21}(.{4}).{21}(.{9})(.{9}).*
le .* à la fin représente la fin de la ligne (tous les caractères entre la position 65 et la fin de ligne)

Pour la chaîne de remplacement, c'est beaucoup plus simple. On va utiliser une série de chiffres représentant le numéro du motif entre parenthèse de la chaîne de recherche. Autrement dit, 1 va correspondre au groupe de 4 caractère, 2, au premier groupe de 9 et 3 au second groupe de 9.

on aura quelquechose comme :
sed -e 's/^.{21}(.{4}).{21}(.{9})(.{9}).*/1 2 3/'

sauf que j'ai légèrement simplifié. Les chiffres représentants les blocs entre parenthèses dans le motif de remplacement doivent être échappés par un \, sinon, ils représentent simplement des chiffres.
sed -e 's/^.{21}(.{4}).{21}(.{9})(.{9}).*/\1 \2 \3/'

et même qu'en fait, j'avais beaucoup simplifié, parce qu'il faut aussi échapper les accolades et les parenthèses, et d'un seul coup, c'est le bordel :

$ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 | sed -e 's/^.\{21\}\(.\{4\}\).\{21\}\(.\{9\}\)\(.\{9\}\).*/\1 \2 \3/'
BCDE ghijABCDE FGHIJ1234


bref, sur le principe, pas très compliqué de faire ça en sed, mais pas très lisible ...
Je dirais même que ça doit être plus lisible avec un one liner en perl :D

bon, ça n'explique pas pourquoi ton cut n'applique pas l'ouput delimiter.

tu peux poster ta ligne de cut avec ton output delimiter qui ne fonctionne pas ?

parce que chezmoisamarche:

$ echo "aaa" | cut -c1,2,3 --output-delimiter="|"
a|a|a


ou ":x"

Pourquoi "grep" ?
parce que je travaille sur des projets assez volumineux pour lesquelles les implémentations de toutes les fonctions ne sont pas contenues dans un seul fichier ;)
effectivement, pour de la recherche interne au fichier, /, n, N, ?, * et # sont mes amis


Ce que je reproche aux ctags (à part ne pas gérer tous les langages, mais ça, c'est un peu de la mauvaise foi), c'est de remplacer mon buffer en cours d'édition par un autre truc, or, la plupart du temps, je veux voir la définition d'une fonction, mais je veux aussi continuer à voir le code que j'étais en train de consulter.
Y a surement (ou pas ?) pleins de raccourcis dans ctags qui me permettraient de m'en servir "comme j'aime" mais j'avoue piteusement que j'ai la flemme de regarder :)

Comme Maxime, je fais tout en vim.
ça m'est même arrivé de débugger du Java avec =)

par contre, soyons honnéte, j'utilises vim *et* grep. Sans grep, ça serait plus compliqué et je serais obligé d'utiliser les ctags, que j'aime pas trop.

Question modérément trollifique : y'a-t-il d'autes éditeurs que vi (ou vim ou dérivé) utilisant le paradigme mode de commande / mode d'édition ?

parce qu'au final, c'est quand même bien ça qui fait que vim est supérieur à tous les autres éditeurs de texte.

(jolie conclusion non ? :)

oula, fatigué moi
s/ est/, et/

oui est les vrais libristes utilisent la distribution GNU/Linux gNewSense, non mais ! :)

unsigned byte, soyons précis :)

il faut bien renvoyer un statut dans exit et *surtout pas* des datas.
Accessoirement, on ne peut pas renvoyer trop de status non plus.
En tout cas, chez moi :

$ cat main.c
#include <stdlib.h>
int main (int argc, char *argv[]) {
int exitValue = -1;
exit(exitValue);
}
$ gcc main.c; ./a.out; echo $?
255

autrement dit, mon shell récupère un unsigned byte.

pour la conf des runlevel, j'ai mis le temps à retrouver parce que je ne m'en sers pas tous les deux jours, mais sur debian, sysv-rc-conf (en curses), c'est bien pratique.

Concernant l'édition de fichiers de conf, y a-t-il vraiment moins de fichiers à modifier sur d'autres distribs ou est-ce juste que les clickodromes vont modifier les fichiers de confs à ta place ?

Perso, je fais tout en CLI (j'aime bien comprendre ce que je fais) mais je ne connais vraiment bien que les dérivées de Redhat et debian, pour lesquels la différence de complexité ne me parait pas évidente.

tant qu'on y est :
s/mémo-technique/mnémotechnique

oui, car l'algo de google est infaillible, forcément.

bon, j'ai farfouillé un peu.
http://www.blogbilger.com/blogbilger/2006/11/le_journalisme_(...)
Mon expérience personnelle depuis 2003 n'a cessé de me le démontrer. Le fact checking ne fait pas partie de la culture du journalisme à la française

Du coup, tu as raison sur le fait que l'expression "fact checking" désigne quelque chose qui n'a pas de traduction française répandue.

Encore une fois, ne connaissant pas le terme "fact checking", ce n'était pas sur l'utilisation du terme anglais que je tiquais, mais sur la justification que tu donnais.

Qu'il soit maintenant admis que "fact checking" peut rester non traduit et désolé pour le bruit :)

Il se passe quelque chose entre 18.232095 et 196.734335, mais lp n'est pas forcément le coupable. Ca peut aussi être le chargement du module pour le touchpad qui prend du temps.

si tu désactives le touch pad, il se passe quoi ?

le chargement du module lp à la main après le démarrage de la bécane prend combien de temps ?

google ne propose pas de traduction donc c'est impossible à traduire en français ?
Genre "vérification des faits". D'autant que tu utilises déjà le mot "vérification" dans la phrase précédente de ton commentaire originel.

C'est pas tant le fait que tu utilises "fact checking" qui me gène que la très mauvaise justification que tu donnes (google ne sait pas donc on ne peut pas traduire) qui me fait réagir.

ouais ! \^.^/

Je vous rassure, c'est pas une guerre :)

Et puis, plus y a de solutions proposées, mieux c'est (mon petit côté Perl ;)

Sinon, c'est aussi possible de remplacer le syslog fichier par un syslog qui stocke en DB. Ensuite, trouver l'info de départ, c'est un simple SELECT dans la dite DB

Sachant qu’une requête sur une image retourne toutes les informations associées, cela fait quatre jointures par requête.

et alors ?
Si tu penses que ça peut poser des problèmes de perf, tu as peut-être raison, mais c'est beaucoup trop tôt pour s'en soucier. Privilégie la propreté du design de la DB, et implémente les requêtes qui vont taper dedans.
Si un jour tu rencontres un problème de perf, il sera temps de réfléchir à la façon d'y faire face ... mais pas maintenant.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

sinon, une remarque en passant, il peut y avoir plusieurs villes portant le même nom dans un même pays.

tiens, il reste un artefact de mes tests dans la ligne de grep, les '\(' et '\)' n'y servent à rien. La ligne suffisante est
grep -o "to=<[^>]*>" fichier