PLuG a écrit 1016 commentaires

Tiens ?
Je ne savais pas que les reponses aux requetes MX n'etaient pas mises en cache.

D'ailleur je viens de sniffer sur un dns ici, et apparemment il repond aux requetes MX en se basant sur son cache (vu qu'il me repond et qu'il ne pose la question a aucune autre machine) ...

Peux-tu nous indiquer tes sources ??
A moins que cela vienne de mon bind (9.2.1 evidement).

beaucoup de services importants tels que la messagerie dépendent du DNS

heuuu c'est bizarre cette phrase. Qui utilise des services en configurant l'adresse IP directement ???


la messagerie utilise le DNS, certes, mais http,ftp,ntp,irc,ssh... en fait TOUS les services reposent sur DNS.
En clair si on fait tomber les serveurs DNS c'est tout Internet qui en souffre (et pas seulement le mail)

humm, le cheval celebre contenait surtout une bande armée qui a foutu le souk en interne dès la nuit tombée ...
AMHA son programme serait bien un trojan, pas besoin "d'ouvrir les portes".

la config gnome de redhat previent aussi du danger lorsque l'on se loggue root (mais se logguer root sous Gnome + X11 ce devient vraiment de la provoc :-)

Je parle de l'architecture JAVA que je connais, pas du langage que je n'ai pas assez pratiqué.
Mais dans ta citation tu te gardes bien d'inclure ma phrase complete ... pas très honnete comme comportement !

Je n'ai jamais prétendu que JAVA avait inventé le bytecode ni le GC. Dans l'embarqué JAVA devait tourner sur des processeurs JAVA donc exit les problemes d'architecture JAVA que je dénonce dans mon message.

Ensuite tu me réponds "facilité de développement en JAVA".
Cela ne me pose pas de problèmes, mais je pense que tu t'enerves tout seul et que tu ne parles pas des mêmes aspects que moi (facilité de developpement == langage or j'ai averti que je ne parlais pas du langage).

Quand a mon allusion a IIS, regardes la de plus près:
-techniquement windows+IIS ont AMHA moins d'atout qu'un unix + apache notement en termes de sécurité, de licenses, etc.
Un defenseur acharné de Microsoft répondrait a ta manière, facilité d'installation, disponible et supporté par plein de gens ...

CE N'EST PAS MON PROPOS.
Je dis qu'il est domage de payer en performance alors que ce qui plait dans JAVA c'est le langage.
le GC, les DP et les frameworks pour faire des serveurs d'applications. On pourrait avoir tout cela sans le surcout lié au bytecode. Ce qui fait l'interet de JAVA c'est le nombre de developpeurs et les produits/bibliotheques qui existent, plus que son architecture.

Reste a compiler le langage java que tu aimes tant, ainsi que tous ses frameworks ... Quand GCJ sera pret !!

Si tu sort d'une ecole d'ingenieur, tu vas pouvoir nous dire comment tu as réussi a "carroter".

AMHA c'est typiquement le mauvais exemple (je ne parles pas des autres - je ne les connais pas).
1/ faut le bac (on peut carroter)
2/ faut un dossier pour entrer en prepa (plus chaud a carroter)
3/ faut tenir les 2 ans de prepa (la tu m'explique comment tu triches ...)
4/ faut carroter aux concours d'entree aux ecoles et aux oraux qui suivent ...

après c'est clair t'es sauvé, en Ecole on ne te demandes plus grand chose.

Je comprends ton message, ton exemple est peut-etre un poil exagéré cependant ... a moins qu'on parles des ecoles d'ingenieur payantes et pour lesquels on ne passe pas par la case prepa ... ben les recruteurs savent faire la difference deja (souvent ils ont un classement des ecoles et proposent des salaires en consequence ....)
reste que l'ecole c'est important au debut de la carriere, ensuite c'est surtout l'experience qui compte.

Crois-tu vraiment que tout ceux qui ont postés dans cette news sont passés à coté du danger de cette politique de RedHat ??

Je ne pense pas.

On verra plus tard si RedHat nous enfumes ou si leur stratégie était payante pour eux, ou pour le libre en général. On ne peut pas le savoir maintenant.

Reste quand meme ces points:
-aux US les brevets logiciels ont cours. RedHat est cotée a la bourse de NY, ils doivent utiliser les règles du jeu qui sont en place la bas si ils veulent avoir des chances. Meme si c'est mal (tm).
-admettons qu'un jour en europe aussi les brevets logiciels soient appliqués. Que ferons nous ? Allons nous abdiquer et laisser les autres tenir de devant de la scène informatique ?? Allons nous laisser le libre disparaitre lorsque toutes les nouvelles idées seront brevetées ?? Moi je pense que si les brevets passent en europe, on aura peut etre interet a avoir des idées en premier et a les breveter vite fait, en laissant le droit aux autres de se servir de l'idée. Et peut etre que les "autres" sera restreint de facon a fermer la porte à MS... tiens, ben ca alors !! c'est justement ce que RedHat a fait aux US. mince c'est peut etre pas si con alors ??

La GPL s'applique a du code, le brevet a une idée. On ne protege pas la meme chose.

Sinon, l'idee d'Ingo Molnar qui permet a une tache de savoir a-priori si elle risque d'etre reschedulée lorsqu'elle fait un appel systeme a open(), tu peux la coder dans une librairie, certes mais on est quand meme bien au coeur d'un système là.
Le public interessé n'est pas très large...

Quand a l'interet de la chose, je me pose des questions. L'interet est surtout pour les applis qui font beaucoup d'open() [serveur web tux par exemple]. Et encore, la methode permet de savoir si tux risque d'etre reschedulé mais comme de toutes facons il faudra faire le open() en question ... cela permet juste de decider quand lancer un nouveau thread pour faire un nouveau open... je suppose que tout cela a été passé au bench par Ingo et que l'on peut trouver des chiffres explicant ce que l'on y gagne, pour le moment je ne suis pas convaincu.

mais je doute qu'ils gardent pour eux le travail effectué sur le noyau.

effectivement, d'autant plus que le kernel linux (et les outils GNU) compilent en 64 bit sur pas mal de plateformes deja. Le boulot pour adapter a un cpu compatible x86 mais en 64 bits ne doit donc pas etre enorme... surtout quand le fondeur du CPU participe.

les licenses libre sont donc suffisantezs pour protéger d'un brevet

oui mais un brevet permet de faire plus.

Si le code d'Ingo Molnar est GPL, l'idée (ce n'est pas le code qui est breveté) peut etre utilisée sans prejudice apparent par d'autres (mais pas breveté puisque déjà connu de tous).

Si l'idée derrière le code d'Ingo Molnar est brevetée aux USA, les autres doivent acquerir un droit d'exploitation de cette idée. RedHat donne le droit a tous ceux qui écrivent du code libre, mais pas aux mastodontes qui brevetent tout ce qu'ils créent (IBM, MS, ...)

Donc oui cela donne une légitimité aux brevets aux USA (mais ils n'en ont plus besoin). D'un autre coté cela gène surtout ceux qui jouent a fond le jeux des brevets. Utiliser le système pour le combattre en somme ...

Aujourd'hui, je ne sais pas quoi penser. Est-ce bien joué de la part de RedHat ? Est-ce inutile ??
Passé un temps, la communeauté OS proposait bien de tout breveter meme le plus stupide (sorte d'attaque D.O.S. du système) ... au moins RedHat n'a pas breveté le "double click" (meme si l'invention d'Ingo Molnar est un peu alambiquée)

PS: pour ceux qui découvrent cette nouvelle, RedHat a fourni cet explication sur leur site oueb il y a relativement longtemps (quelques jours après la vague a troll sur linuxfr)

pour le one time pad, tu peux utiliser des cartes que tu pioches dans un chapeau.
tu remplis deux carnets (identiques) de ces "clefs",
tu en remet un a ton correpondant en main propre et voila, votre correspondance est chiffrée correctement pour autant de messages qu'il y a de pages dans le carnet ...

reste a ne pas se faire photocopier le carnet par un intrus ...

oups mea culpa, j'avais oublié cette astuce ...

A la lecture je me suis fait la meme reflexion que toi, puis je me suis dit qu'avec un budget de 5M, on peut en investir 4% pendant 5 ans pour obtenir le resultat escompté ...

reste que toutes ces affirmations sont un peu gratuites effectivement.

apparement (je viens de lire les liens que j'ai posté en dessous), TPE fait ce que tu dis effectivement. De plus il garde une liste de user qui ont le droit d'executer des binaires et a chaque lancement l'UID est cherché dans la liste.

Je ferai remarquer qu'a moindre cout, tous les unix peuvent etre installés de facon a limiter la casse si /home, /tmp et /var sont montés en mode "noexec" et "nodev".

TPE est apporté sur OBSD par les patch "stephanie" décrits ici: http://c0ke.kaizo.org/mirrors/stephanie/(...)

la technique TPE a été décrite dans Phrack numero 54 ( http://www.phrack.org/phrack/54/P54-06(...) ) et repris par la nsa ( http://www.nsa.gov/selinux/inevit-abs.html(...) )

reste a lire tout cet anglais :-)

Je suis d'accord avec toi, la maturité des solutions a base JAVA disponibles aujourd'hui font que ces solutions sont incontournables.
Comme le dit un post plus bas, si on compare JAVA et PHP, y a pas photo.

Mais cela ne prouve rien quand a l'architecture de la solution. La portabilite cote serveur est un leurre. On peut très bien developper du C sur un linux et le compiler / tester sur une plateforme autre (solaris) avec un peu d'experience.

Donc oui les solutions JAVA actuelles sont sexy.
et Non cela ne prouve rien sur son architecture completement dédiée a la portabilite binaire. Cela prouve juste que JAVA a interessé suffisement de monde pour que des solutions web soient développées. Et cela surement parce que java apporte la compatibilite en mode source aussi. Pour un developpeur, c'est agréable de savoir que son code risque de marcher de partout => succès, alors que la compatibilité binaire n'est pas necessaire.


les objets, le GC, ... tout le reste est applicable a d'autres langages reposant sur d'autres architectures, donc ces "avantages" ne sont pas dédiés à java.

heu ... sans vouloir te contrarier ... un langage évolue .

Le langage java - je ne me permettrai pas d'en penser quoi que ce soit, c'est un langage qui a ses atouts, ses inconvenients, et je suis mal placé pour en parler (pas assez pratiqué).

Par contre l'architecture associée - JAVA et son mode de pseudo-interpretation (pseudo code, ...)- a clairement été pensée pour les applets. Avant cette achitecture JAVA, il etait impossible de distribuer via le web des "binaires" a faire tourner sur les clients.
JAVA répondais a un besoin précis, un besoin qui n'avait pas d'autres solutions.

Maintenant, utiliser l'architecture JAVA du coté du serveur, a mon avis c'est pas optimal du tout. Certes cela permet d'installer la meme applis sur n'importe quel serveur, mais cet avantage a un coup a chaque execution, alors qu'un soft bien developpé [meme en C] est facilement recompilable sur tous les systèmes.

JAVA sur le serveur c'est:
-un avantage pour l'editeur du soft [un seul packaging/livrable quel que soit la plateforme du client. Donc moins de frais pour l'editeur qui fait payer la note au client (en perfs)]
-un lobbying des developpeurs JAVA [mais on pourrait developper avec le langage JAVA et compiler du code natif ...]
-un effet de mode [qui passera plus vite que celui du C, rendez vous dans 30 ans]

Alors les pro-java vont repondre que les perfs sont la, que blablabla ... moi je leur dit:
utiliser JAVA cote serveur, c'est comme heberger un serveur WEB avec IIS/WIN 2000. On ne peut pas dire que cela ne marche pas, il y en a meme qui s'en servent ... par contre d'un point de vue technique ...

Le coût n'est pas la chose la plus importante AMHA

oui mais bon, faut pas se leurrer quand meme.
d'après mon experience chez les clients (je suis prestataire), celui qui prend la decision n'est pas du tout celui qui va "adapter/personnaliser" mais plutot le decideur pressé.
Et le décideur il croit qu'il achete un truc qui marche du premier coup et qui a été pensé depuis le début d'après ses besoins (c'est ce que le commercial lui vend).
Dans ces conditions, RIEN ne pousse vers linux (toujours moins bien représenté commercialement meme si cela change).
Bref dans le dossier il y a plusieurs solutions, celles que les architectes/techniciens ont conseillés (dont linux), et celles que les commerciaux ont apportés. Le decideur choisit LINUX pas pour faire plaisir a son equipe technique (un peu quand meme ...) mais surtout parce qu'il se dit qu'a 5 ou 10 fois moins cher, il garde un peu de budget pour autre chose ...
Il peut meme se payer 2 machines en redondance (vrrpd, heartbeat, ...) en continuant a faire des économies ...
Pour moi c'est clair, LINUX a bien des avantages TECHNIQUES. Mais quand il passe chez un client c'est TOUJOURS parce que la notion de cout réduit lui donne un avantage.

mais cela souleve un autre probleme: aujourd'hui le decideur paye des licenses AIX + HACMP + ORACLE +... pour ses applis critiques ou a fort besoin de performances [il ne prend pas le risque du cluster linux], par contre il joue a fond LINUX pour tous les services annexes (proxy, dns, dhcp, serveur de fichiers, serveur web, serveur de temps, de pki ...).
Se rend-il compte qu'a moyen terme les gros unix disparaitront du fait de ces diminutions de licenses vendues ?? Quand IBM ne voudra plus soutenir AIX (SUN/SOLARIS, ...), le decideur pressé sera obligé de passer ses applis critiques sous LINUX [mais a ce moment là, plus personne ne pourra le lui reprocher ... et il pourra le faire avec IBM/SUN/... si il le souhaite].

Et si IBM preparait doucement ses admin AIX au passage à RPM et a d'autres linuxeries ...

Cela n'engage que moi, mais je pense que la strategie est bien dans ce sens. Il y a quelques temps le site IBM offrait les memes softs GPL en packages natif AIX. Ils ont donc sciement décidé de tout repackager différement ...

On peut y voir un autre avantage pour IBM: ils prennent les packages src.rpm et font un "rpm -ba" pour obtenir la version AIX sans avoir a trop travailler sur le packaging.
D'ailleurs ils ont re-packagés leurs softs 2 fois:
-au debut -> packages smit
-ensuite -> packages rpm, mais les rpm n'etaient pas lisibles sur un linux x86. le format n'etait pas compatible (surement un probleme d'indiens).
->enfin -> packages rpm actuels, lisibles aussi sur une redhat des familles ...

Par contre a priori, pour dreamworks, les fonctions CMJK et Pentone ne doivent pas etre importantes. Si je ne me gourre pas elle servent surtout pour obtenir une sortie papier/imprimerie décente...

ca me fait penser qu'il fut un temps ou l'on pouvait monter /usr en NFS (au moins avec sun OS, pas avec linux ...).
mais de nos jours, /usr/bin contient plein de binaires utilisés par les scripts de démarrage ... cela devient donc impossible.
dommage, dans la culture unix, /usr devait contenir que des softs "utilisateur", pas des soft indispensables au systeme ....

moi j'avais compris l'inverse, mais c'est vrai que l'article est un peu flou.

autre hypothese:
la copie du cd contient bien une copie du code d'identification. Du coup on peut savoir que ce cd a ete grave a partir du cd de celine dion achete a la fnac de Rouen.
On peut peut-etre aussi demander a la fnac de Rouen la trace comptable de l'achat (numero cb ?).

il y a deja plein de donnees sur les cd vierges, d'ailleur cdrecord les affiche quand on grave.
il affiche entre autre le nom de l'usine de fabrication du cd vierge, le type de surface utilisée, et des numeros.

bof, moi je vois bien la limite quand meme:
-quand on copiera les CD on aura un soft pour anonymiser la copie (pour ne pas pouvoir remonter au cd original)

-il seront bien content quand ils decouvriront que les cd de mediatheque sont allegrement copiés. ca les mènent ou ensuite ??

-deja qu'ils ne perquisitionnent pas chez les particulier pour verifier les licenses des logiciels, ils ne vont pas plus perquisitionner pour verifier les cd...

-et de toutes facons, quand on echange les mp3 via napster/kazaa, le code ne sera pas la.

bref c'est bien futile comme méthode.

heu, si je peux me permettre, OUI c'est une connerie :-)
lsof te permet, au mieux de connaitre la liste des fichiers ouverts sur un systemes et le nom des process qui les ont ouverts. C'est un bon outils qui peux meme te dire la position du pointeur dans le fichier (de sorte que tu peux le voir avancer en meme temps que le process lit le fichier) ...

Par contre pour la question posée ci-dessus, je pense que la réponse doit etre "BSD accounting" ou process accounting. C'est une option dans le kernel, et les outils en user space sont accton / acct / sa.
normalement (c'est le cas sur AIX, mais je ne sais pas sous linux), on peut obtenir des infos sur les IO consommées par les process.
Mais si cela se trouve sous linux tout n'a pas ete implementé ... je ne peux pas verifier maintenant.

e n'imagine pas ce que j'aurais fait si on m'avais demander de payer des impots, quels qu'ils soient
prélevé a la source, un truc linéaire peut commencer avec des sommes insignifiantes. genre au rmi on en est a 10F d'impot/an.

c'est symbolique et ca évite l'effet de marche qui se produit avec le système actuel.