jigso a écrit 1205 commentaires

Et pour vi ? ben y'a les souris mac.

"Vous avez demander le service de délation.
Pour une délation en rapport avec une activité terroriste, taper 1.
Pour une délation juste pour le plaisir, taper 2.
Pour une délation concernant votre belle-mère, taper dessus... "


--
La délation, c'est fou !

Je suis très bien ou je suis

Ben reste z'y !

Moi je --->[]

Sur http://www.granddictionnaire.com , on trouve uniquement 'intractable' dans le contexte de la médecine, dont la traduction est 'réfractaire'; je ne sais pas si ça peut convenir dans ton contexte...

Par contre ce même dictionnaire indique que 'tractable' existe aussi bien en français qu'en anglais, dans le contexte de l'intelligence informatique.

« A problem is said to be tractable if a solution is feasible given finite resources, i.e. a solution call be found using a reasonable amount of time and space. »

Donc peut-être que 'intractable' est un néologisme, et qu'on peut utiliser le même mot en français dans ce contexte...

Je crois que je vais prendre 2 fois des moules

Y'a Chrome aussi qui propose un mode application, cad une page html occupant toute la fenêtre, sans onglet, sans barre d'adresse. La version libre Chromium le fait aussi, si la liberté importe...

ça ressemble plus à une RAM HS, les softs se mettent à crasher de manière aléatoires. Tente un memtest86 à partir d'un liveCD...

De toute façon c'est pas la taille qui compte.

C'est quoi l'intérêt de l'alias ?
Il suffit de nommer le script dbaccess (sans le .sh), et le mettre dans /usr/local/bin, ou bien créer un lien de /usr/local/bin/dbaccess vers /usr/informix/bin/dbaccess.sh

FetchExc utilise webdav pour récupérer les messages et les renvoie sur un serveur de mail SMTP classique.

http://fetchexc.sourceforge.net/

Encore une templeet dans un verre d'eau.

il sera plus efficace de faire une validation coté serveur avant d'envoyer le script dans la page, je ne pense pas que ce soit vraiment faisable dans le navigateur (à moins de refaire un parser javascript en javascript...)
Coté serveur il y a rhino http://www.mozilla.org/rhino/ qui est moteur javascript seul, on doit surement pouvoir hacker qqe chose pour vérifier si certaines fonctions ne sont pas appelées. Il y a aussi JE http://search.cpan.org/~sprout/JE-0.033/lib/JE.pm pour parser le javascript en Perl, je pense qu'on doit pouvoir ensuite jouer avec le résultat pour vérifier les fonctions appelées.

Par contre ça va fragmenter la Ram. Mais ça n'est pas très grave, la Ram est rapide.

Non, ça t'en sait rien, ça dépend de ce qui est fait dans le noyau. Je me garderais bien de faire le moindre pronostique sur la fragmentation de la RAM, et sur l'impacte sur les perfs : on peut trés bien avoir une RAM fragmentée sans impacte sur les temps d'accès, ça dépend de la granularité de la fragmentation et des modes d'accès aux blocs de données, bref faut se plonger dans le code du noyau et dans les docs techniques de fonctionnements des RAMs pour espérer deviner le comportement du système.

Vu la complexité des phénomènes mis en oeuvre, et la multiplicité des configurations possibles, comme souvent en informatique, il faut bencher et ne pas se fier à son intuition...

C'est pas ton problème, c'est celui de l'OS, et il fera ce qu'il faut :
si un processus utilise massivement /tmp, alors le processus et /tmp seront dans la RAM, au détriment des autres processus (ceux qui ne font rien donc on s'en fout un peu) ; dans la situation inverse /tmp sera majoritairement swapé sur le disque pour accéder plus rapidement aux processus.
Maintenant avoir plus de données (processus+/tmp) que de quantité de RAM, et swaper sur disque n'est jamais bon, et aura toujours un impacte coté perf et reactivité...

Bambi est mort ? on m'a toujours dit que c'était sa maman qui meurt.. On m'aurait menti ?

snif.

Et puis bon, le litre et le kilo d'eau sont plutôt proches, non ? ;)

Uniquement à 25 °C.

Je proteste ! J'ai écris en (toute petite partie) un OS, j'exige que Microsoft n'intègre aucun OS dans son OS pour ne pas nuire à la concurrence !

Blague à part, c'est peut-être plutôt de ce coté qu'il faudrait que la commission se penche...

Pour certains serveurs (je pense aux serveurs web), cela peut sembler délicat. en effet les exploitations des applications web sont très courantes. Tout cela est affaire de logique ! Évaluer les risques etc.

Surtout qu'en plus patcher un serveur Web - ou tout autre application - n'est pas synonyme de reboot systématique... du moins sous Un*x ;-)

Non il n'est pas auto-signé, il est certifié par CAcert : http://www.cacert.org/
Il te suffit de rajouter leur certificat dans ta liste des certificats de confiance et zou.

Moi aussi j'ai ce problème... avec mon portable que je branche régulièrement sur ma télé. La résolution n'est pas la même et l'adaptation à ce changement est foireux et irréversible. Cela signifie que lorsque l'on retrouve la résolution d'origine, les éléments ne se remettent pas là où nous les avions placés (dans cette résolution) mais les laisse là où l'adaptation les a "amenés".

C'est marrant, c'est comme sous Windows.

Vraiment bien imité !

Dans LinuxMag numéro 113 et 114, il y a des articles sur SSO et CAS.
Sinon une page qui résume tout ça : http://www.esup-portail.org/consortium/espace/SSO_1B/cas/

En Perl il y a le module LWP qui permet de scripter simplement des requêtes Web.
http://search.cpan.org/~gaas/libwww-perl-5.825/lib/LWP.pm

Si ça pouvait être le seul problème du c++... (soupir)

il y a aussi l'extension Firebug, qui permet de voir toutes les requetes (au chargement, et durant la "vie" de la page).

Le plus drôle est que le message est toujours disponible si on utilise certains agrégateurs de flux RSS en ligne, par ex Google Reader ; comme il index en continue le flux, et qu'évidemment le contenu est partagé entre les différents utilisateurs qui s'y abonnent, tu peux le retrouver par ce biais là...