Prae a écrit 2839 commentaires

Je pense que son tips est plus orienté "scripting shell"
tandis que le tien est plus orienté "interactivité"

bah, nan, je l'ai toujours pas recu ;-)

Le pire je crois, c'est quand ils te posent une question de ce style; Tu leurs demande s'ils ont recherchés un minimum et te sortent _la_ phrase qui tue en guise de réponse :

# "finalement, elle aide pas trop la communauté du libre"

Je sais pas comment leur faire comprendre que "aide de la communauté" ne veut pas dire "esclave"

JE VOIS PLUS RIEEEEN !!! MES YEUX BRULLLEEEENNTTT !!!
AAAAAAAAAAAAAAH !!!

Bon trève de plaisanterie, j'apporte à peu-prêt la même conclusion que les autres: tu vas te faire flammer par ton "pote".

Et puis bon, y'a pas plus important que de s'engeuler avec son pote sur une bétise pareille ?

Je reste un peu sur ma faim avec ta réponse :-)
Donc les radios payent des droits à la SACEM pour quoi ? :)

> Ca fait très longtemps qu'on peut graver tranquillement sous nux

Tout comme il y avait des db avant l'arrivé d'Oracle sur une plateforme Linux :-)

Ton commentaire me laisse un gout amer: de l'intégrisme pur et dure.

Quand j'irais voir quelqu'un (une société, un groupement, une association, un ministère, etc..) qui souhaite migrer leur plateforme proprio à du Linux mais pour des besoins logiciels sont obligés d'utiliser du propriétaire (db'Oracle par exemple), je leur sortirais ton argumentaire ...

je suis sur que ca va leur plaire ...

J'ai pas très bien compris la différence entre Mozilla et un packaging de tout les applicatifs de la fondation Mozilla (Firefox+Thunderbird+etc....)

> Ça ressemble beaucoup à "ne partez pas chez la concurrence, on va bouger et vous verrez"...

Ca s'appelle aussi du vaporware :-)

Les radios payent déjà des "droits" à la SACEM pour la diffusion de musique "propriétaire"

I haaaavve a dreaaaam ! :-)))

>> Ben j'aurais bien voulu, mais Giscard, il m'a pas invité.
> Pauvre choux.

De toute façon, Giscard c'est un pote agée

Je me répond à moi-même parce que j'avais croiser un peu les données :

mainteneur PaX != Brad Spengler

voila :-)
désolé pour le bruit :)

Subject: [grsec] grsecurity 2.1.3 released for 2.4.29/2.6.11 *CRITICAL UPDATE FOR RBAC USERS*
From: "Brad Spengler" <spender AT grsecurity POINT net>
Date: Mon, March 7, 2005 15:46
To: grsecurity AT grsecurity POINT net


grsecurity 2.1.3 has been released to fix a number of problems found
during a routine audit of grsecurity. Changes in this release include
allowed gradm -u for non-root users in a no-authentication special role,
addition of a missing ptrace hook on amd64, fixed hidden file check that
takes subject inheritance into account, unification of the mmap hook so
it no longer requires a per-arch component, and the breakup of the "O"
subject flag into "O" and "t", where "O" now means to allow writable
library loads for the process, while "t" allows a process to ptrace any
task. The "t" mode should be used sparingly in combination with the
no-ptrace object flag. A bug in PaX that causes a SIGBUS in a task when
SEGMEXEC is enabled but MPROTECT is disabled has been fixed in this
release as well.
During the audit, a critical vulnerability was found in the RBAC system
that effectively gave every subject the "O" flag, allowing a root user
for instance to gain the privileges of any other process through
LD_PRELOAD or ptrace. If you have already upgraded to 2.1.2 and use the
RBAC system, I strongly urge you to upgrade to 2.1.3. To ensure that
problems like this won't occur in the future, I will be developing an
extensive regression test suite for the RBAC system similar to the one
that exists already for non-RBAC features.

Sorry about the timing of this release, but the vuln I discovered is
quite serious, and I'm hoping to catch the people who haven't updated
their machines to 2.1.2 yet due to it being released over the weekend.

-Brad

> Brad Spengler, un des auteurs de grsecurity, s'est cependant porté volontaire pour reprendre le flambeau.

Je suis un peu étonné car je le vois souvent sur la ML
Ou alors j'ai fumé des GNUs en plastiques ?!

> Sans le quick start la 2.0 va un peu plus vite que la 1.1. Au chronomètre, je gagne 2 secondes. Avec le quick start le chargement est plus lent et je perds 2 secondes! Mais il vaut mieux le quickstart quand même (5-6 secondes pour ouvrir au lieu de 9 ou 10).

Tu réponds presque à ma question, mais ... est-ce que OpenOffice est toujours aussi lourd au niveau CPU et mémoire ?
parce que bon ... franchement, c'est pas super-super rapide OOo

6 mois avec deux entreprises pour développer un simple flux RSS qui envoi de la pub ...
...
J'imagine le pire s'ils developpent d'autres produits ..

> pour pinailler, openssl sait écrire sur stdout directement, pas besoin du cat final.

oui, j'ai vu après le "submit" de ma réponse que c'était possible ;-)

> Si vraiment je peux envoyé par la poste, car je suis bon joueur ;)

Je veux bien :-)))
juste pour le fun ;-)
et en plus, y'a des gens qui réclame la photo ;-)

Pour faire plus simple :-)

echo "U2FsdGVkX1+ZtAju6xuCRUx+SMv45ot9xEHBuCyY3XzdXkhxQ9grfx2gga0vlO28Buxbx5ny2k1h32zuaqGL0/mCe1H+/Eh+uoghKTvh+KtGJM1jdSbLUQ==" | base64 -d | openssl des3 -salt -in DES3 -out DECRYPT -d -k vosgueules && cat DECRYPT

voila :-)

En fait je me suis gourré juste au niveau du mot de passe, j'ai été trop vite en redonnant l'explication, la première tentative pour le passe était "Marc" et la seconde "vosgueules"

C'est donc "vosgueules" qui est le bon mot de passe ;-)

première algo: base64
ca donne:
Salted__™´îë‚EL~HËøæ‹}ÄAÁ¸,˜Ý|Ý^HqCØ+ /”í¼ì[ǙòÚMaßlîj¡‹Óù‚{QþüH~ºˆ!);áø«F$Ícu&ËQ

Le resultat donne - probablement - une utilisation du 3DES (des3)
Hop! Hop, décryptage en DES3 ...
Il faut un mot de passe ... hmmm
"vosgueules" : non
... "Marc" ?

Ah bah oui ...

Voici le message final :
"Et dire que beaucoup ici râle quand il s'agit d'un journal _sérieux_."


La soluce version terminal :
# echo "U2FsdGVkX1+ZtAju6xuCRUx+SMv45ot9xEHBuCyY3XzdXkhxQ9grfx2gga0vlO28Buxbx5ny2k1h32zuaqGL0/mCe1H+/Eh+uoghKTvh+KtGJM1jdSbLUQ==" | base64 -d > DES3
# openssl des3 -salt -in DES3 -out DECRYPT -d
enter des-ede3-cbc decryption password: Marc
# cat DECRYPT
Et dire que beaucoup ici râle quand il s'agit d'un journal _sérieux_.

> les employés qui ont peut être des stock-options-machin

les simples employés mandrake qui ont quelques actions ...
faut pas aller voir derrière les grands chef avec un couteau en travers la machoire ...

> Je sais même pas pourquoi t'insiste, on a l'impression que celà te fait mal au cul d'admettre que le fait que MS gère tout de A à Z puisse être un sacré avantage question réactivité qu'une boîte comme Red Hat qui fait principalement de l'intégration.

J'ai pas dit le contraire;
L'interaction "equipe dev MS <-> maison mère MS" est surement plus réactive que "equipe dev à l'autre bout de la planète" <-> "boite intégration à l'autre bout de la planète"

... quoique, même à coté, parfois c'est dur d'avoir des trucs ...

> je te rappelle que Red Hat repackages toutes les applis

mais ne les développent pas !!!
(je précise qu'un patch par-ci par-là ne fait concept de "développement")

> Faux, tu n'en sais strictement rien du tout, et c'est bien en ça que tu as complètement tord : tu ne sais pas comment ça se passe derrière MS et c'est tout ce que toi en tant que client tu as à retenir :

Mais toi aussi tu n'en sais rien.
D'un autre coté, pBpG n'a toujours pas gueulé ... donc c'est que je ne dois pas dire autant de connerie que cela
(manquerait plus qu'il arrive à ce moment là ;-)

> C'est la dernière fois que je t'explique, on s'en balance du nombre d'intermédiaire

Dans une étude voulant montrer le différentiel de réactivité entre un produit "Microsoft" et un produit "open source" : non, cela n'est pas objectif.
On met les différents protagonistes aux mêmes niveaux et on compare.
Cela s'appelle être objectif.


Ce qui me chagrine le plus dans ce rapport (enfin dans la "constatation" des docteurs), c'est qu'il parle de RedHat comme ci celui-ci était le "vendeur officiel Linux"

Ca veut dire que si je rajoute d'autre prestataire derrière, pour toi ca te choque pas de mettre la finalité au même plan qu'une discussion directe avec une boite de "développement/revente" direct ?
Qu'il y est plusieurs couches d'intermédiaires non plus ?

Donc c'est une bonne expertise pour vous de mettre au même plan de réactivité une boite emettrice de produit (je parle pas de quelques patchs par ci par là hein!) par rapport à plusieurs intermédiaires avant le client final ?

Pour moi ce n'est pas un gage de qualité, dans un rapport, de mettre dans le même contexte, au même niveau différents protagonistes qui n'ont pas la même sctructure.