Reprise du message précédent :

Ca marche mieux que Windows Update ou c'est pareil ?
Je crois qu'on en a un qui traine en salle serveur (si je ne l'ai pas déjà brûlé pour le purifier )

swapon

roh chava chuis pas un noob non plus  

En plus ca a rien à voir  

C'est juste le message d'erreur qui m'a fait exploser de rire (et les gars du bureau 10s après)

Nicolas Sarkozy me fait l'impression d'une personne voulant tout contrôler quant à son image.
Si c'est le cas, c'est non seulement pitoyable mais en plus vain.
---
EDIT
Et puis, si il se trouve dans de si nombreux magazines, c'est qu'il l'a un peu cherché, non ?
</Argument certes fallacieux>

 
C'est juste pour centraliser et que toutes tes machines ai les mêmes updates installée
 

 
http://www.laboratoire-microsoft.o [...] rver/WSUS/

Dans l'idée (et le principe) c'est  comme RHN Satellite

je vais pas installer une VM-win32 sur mon proxy nux pour cela, je suppose qu'il faut encore une licence  
de plus il faut que toutes les machines disposent de la même version d'OS ou bien?

Ah OK, de grands noms bien marketing pour de simples rsync sur les mirroirs officiel quoi
J'ai ca pour Debian, ca me suffit

Bonjour
 
Le vendredi, c'est sarkozy

non mais windows c'est simple.

moins que MacOS quand même

vu sur dlfp :
http://info.rsr.ch/fr/monde/Ingrid [...] 5170284000

aller k'sauce à la rem  

Goto Solidays
 
/warko/  \ooo/////////////////

Ca dépend vraiment de ce que l'on entend par plantage et reprise: c'est comme temps réel, ca ne veut strictement rien dire (à part émerveiller le décideur pressé qui pense que c'est mieux).

Ca c'est sur, la partie applicative ne gère pas les couches réseaux, elle se contente de faire des syscalls et laisse l'OS se démerder pour le reste. Forcément, c'est plus simple.

Maintenant, j'attends de voir une appli capable de gérer des interruptions déportées sur une connexion réseau, ou gérer une reprise potable sur une connexion TCP qui tombe, _sans_ intervention du client (ce qui est le cas ici).

J'aimerai bien dont tu me parles d'une telle appli. Bien évidemment, les dev spécifiques ou client et serveur sont maitrisés ca ne pose pas de problème, mais là, c'est pas du tout le cas.

 
A définir. Quelle relation d'identité?

Bon goto @home bonne soirée a tous.

Je ne comprends pas la question monsieur l'examinateur

C'est le sujet de "C dans l'air" d'ailleurs

http://www.lemonde.fr/europe/artic [...] r=RSS-3208
 
196 et 47 coups de couteau [:w3c compliant:]

 
Ca fait longtemps que t'es pas venu en France ?

en gros c'est un proxy qui regarde ce qui est dispo, et tu choisis ce que tu installes sur les machines en clicka clicka.

A tous les coups le tueur souffre de la maladie de Parkinson

Salaud de Michael J Fox !!!

 

 
Quels critères te permettent de dire que deux systèmes sont identiques?
 
Exemple: une page qui a un contenu dynamique, est identique à une autre:
1 - si elle offre les mêmes fonctionnalités?
2 - si à un instant t, elles retourneront un affichage similaire (pub qui change, randomisation des captchas)?
3 - si à un instant t, elles retourneront un affichage strictement identique, pub et variables aléatoires comprises?
- ...
 
C'est pas une question triviale. Il y a des écarts à définir pour donner une tolérance dans le comportement, et dire s'ils sont identiques ou pas.
1 - deux pages au contenu et au moteur de rendu différents (CSS différents, par exemple), mais qui interrogent la même base de données.
2 - deux pages webs identiques niveau code, et qui interrogent la même base de données. Les random() sont gérés par la station qui fait tourner le serveur.
3 - on cherche à garantir les mêmes variables data et aléatoire entre deux machines différentes (déjà plus dur, surtout d'un pdv sécurité)
 
C'est un gros problème d'ingénieurie sur des applications à temps contraints (médical, transport, énergie).

 
Il est evident que les applis n'ont pas à avoir ce niveau de détails.
L'appli c'est : l'opération à réussit je valide, elle a pas réussit je tente une reprise
 
Il ne faut quand même pas oublier qu'a la base IP est créer pour faire du best-effort, pas du 100% de réussite.
En théorie les applis devraient en tenir compte aussi.
 
Personnellement j'ai vu des applis reprendre l'activité sans plantage après une bascule de base en cluster d'un site à un autre, si elle sont capable de faire ça je vois pas ce qu'elles peuvent pas faire

C'est officiel, c'est nous qu'on a les ReuMeuLeuLeu de l'année prochaine \o/

Toutes les applications n'ont pas un fonctionnement transactionnel.

Oui et non. S'il fallait que html gère la chose, c'est de l'overkill. On place une grande complexité dans un client web, ca devient l'horreur. Idem pour SMTP, la plupart des opérations d'annuaire (lecture), ... Idem au niveau OS. Suffit de voir ce que donne l'implémentation multi homing de sctp, on la verra pas employée couramment avant longtemps sur des applis TCP.

Donc des applications spécifiques, dans des scénarios particuliers. Protocolairement, il n'y a rien à ce niveau. VRRP/CARP sont dans cette optique, mais on est pas dans du statefull redondant.

Edit: et je parie que ce sont des applications transactionnelles.

 
et il y en a d'Amiens et c'est le voisin d'une collègue (et accessoirement ex-étudiant du mari d'une autre)

j'ai essayé ubuntu... trop compliqué pour moi!!
 
Troll of the day \o/

Tu traines ou pour tomber sur ce topic ??

edit tc proof

Sur Windows, assez souvent.
J'ai une assez bonne mémoire de mes années sous XP, ça me permet de faire du support basique.

 
C'est effectivement la cas et oui c'est la fonctionnement le plus simple à gerer.
 
Mais quand tu parle d'un client html tu parle d'un client, une applis c'est généralement un client et un serveur.
Si ton applis est une temps réel la poindre des chose est de mettre des points de contrôles et des états stables, ça existe aussi.
Oui c'est moins facile à gérer que sur une appli transactionnel, mais moins facile veut pas dire impossible, si quand c'est pas facile on se contente de pas faire c'est juste s'arranger pour envoyer le caca au voisin.
Je dirais même au contraire, si t'as une applis qui travail en flux et en particulier en temps réel et que tu gère pas un état de prete de donnée, tu t'expose à un emmerdement sans fin à mon humble avis
 
J'ai en ce moment une applis transactionnel qui tourne client/serveur sur des bases sybase, ben à la moindre coupure réseau les bases sont corrompus et on doit faire une resto.
C'est juste de la programmation de cochon, pas une question de faisabilité.

Hmmn, la tendance avec les weberies et les archis n-tiers, c'est que la définition d'un logiciel ou d'une appli devient floue.

Je reprends mon exemple: http a toujours la déconnexion à l'initiative du serveur: même envoyer un keep-alive peut être refusé par le serveur. Ceci pour des raisons évidentes de performances et de thrash: on a aucune confiance dans le client. Mettre de la transaction ici, c'est s'exposer à un overhead important. Plutot l'implémenter par dessus; pour du coup, on retombe dans le cadre des applis spécifiques.

On mélange un peu de tout là, on s'arrête. Le temps réel ce sont des contraintes de fonctionnement dans l'execution: il n'y a _aucune_ condition de sureté de fonctionnement et _aucune_ condition d'acquittement/bon acheminement des données.

Le "temps réel", ce sont des mécanismes à temps contraint. On s'assure un ordonnancement et un flux d'execution prévisibles. C'est tout.

Malheureusement, les gens assimilent le temps réel à des systèmes mission ou safety critical. C'est une caractéristique, mais pas la seule.

Exemple, sur un avion type airbus, pour certaines approches, il y a plusieurs AP qui controlent des procédures comme l'autoland. Ici, c'est du safety critical. Il n'y a rien, au niveau de ces AP, qui garantissent qu'ils retourneront tous le même résultat. On les fait voter entre eux: on considère que ceux qui s'écartent trop de la moyenne ont des résultats inadaptés, et sont rejetés.

Pour voter, on attend les résultats en un temps donné (contrainte). C'est tout. Sur AFDX, les messages de controle process ne sont pas acquittés. Pourtant, sisi, ca rentre bien dans le temps réel. Ce sont très souvent des signaux analogique ou discret.

Autre exemple, téléphone portable: il est préferable de pouvoir traiter les trames dans le laps de temps prévu pour le GSM (surtout à cause des interférences inter signaux). Si le calculateur est largué, pour une raison ou pour une autre, il est acceptable de sauter la trame. C'est du temps réel, sans sureté de fonctionnement.

Contre exemple, ariane: c'est du temps réel dur/fort, afin d'éviter la dérive (les calculateurs complexes peuvent avoir des dérives à grand ordre, il faut les éviter).

Attention de ne pas mélanger temps réel, sureté de fonctionnement, et vitesse rapide d'execution. L'applicatif temps réel est assez simple généralement, scheduler statique, pas de migration entre proc sur SMP, les communications se font via des bus dédiés, donc les problèmes de barrière mémoire sont moins visibles (même si ca tend à ne plus être vrai, les processeurs étant beaucoup plus rapide que les mémoires, on voit de plus en plus d'analogie avec la programmation best practice pthread).

Euh non, là, c'est un sgbd de cochon Si ca plante en corrompant les bases, poubelle

Dernier'z

aucune chance

Definitivement

mais oué /hahaguy

http://support.microsoft.com/kb/556106
\ /

dernz

preum's