Sytoka Modon a écrit 4565 commentaires

Pour les homes, backuppc est très bien si quota (+ liste d'exclusion...). Les complète sur backuppc sont vraiment très très longue alors que les incrémentales vont vite. A mon avis, c'est son principal défaut. A priori, la sauvegarde complète des postes Windows obligent à tout retransférer sur le réseau !

rsnapshot, j'ai utilisé pendant des années mais la création des liens (cp -al) devient très très long sur des gros volumes.

J'utilise rdiff-backup sur des gros volume (10To) car c'est le seul que j'ai trouvé (avec rsync qui ne fait pas vraiment du backup) qui va suffisamment vite.

Le problème est que ces outils ne s'étalent pas sur plusieurs partitions. Cela oblige a avoir une grosse partition de backup et un jour...

Pour les gros gros volume, j'irais voir du coté de bacula qui semble corriger tout cela (les dernières version savent transformer une sauvegarde incrémentale en complète afin de ne pas tout retransférer sur le réseau.

Eh bien fermons la porte à Google !

Un serveur web de nos jours est souvent lié à une base de données.

Pourquoi l'affichage ne jouerais pas le rôle d'une base de données ? De type ajout retrait d'information dans un arbre XML avec rendu CSS ;-)

Si Parrot bénéficiait des ressources humaines mises sur le Java ou le JavaScript, c'est clair qu'il irait plus vite ;-)

Allez hop, je me lance !

Pourquoi pas se baser sur la machine Erlang qui a le bon gout d'avoir des variables immutables (pas de programmation en variable globale) et est parfaitement bien conçu pour gérer un grand nombre de thread parallèle. C'est parfais pour de l'IHM graphique !

Ada oblige à faire des fichiers d'en tête (comme C) assez pénible à force. En fortran, ces fichiers sont générés automatiquement (.mod) et c'est bien plus pratique.

Effectivement tu as raison, après quelques recherches (cela faisait longtemps que j'avais pas regardé de ce coté là, merci ssh), le cookie ne sers qu'a l'authentification. C'est idiot qu'ils n'aient pas associé a ce cookie un DES et une compression depuis le temps, enfin comme ssh règle un peu tous ces problèmes, je pense que personne n'était motivé pour rajouter ces petites extensions ;-)

Il me semble que le cookie ne sers pas sur localhost donc pas de chiffrement (X11) local ni via ssh (car avec ssh, le DISPLAY est localhost aussi).

Bref, si mes souvenirs sont bons, le chiffrement X11 n'a pas lieu tout le temps mais seulement pour une connexion distante avec les réglages actuels des distributions.

Prédit par Orwell dans 1984. C'est très tendance actuellement et une des bases de la méthode de notre gouvernement actuel.

Ou :

Steve Jobs mort, Apple est enfin libre ;-)

Il me semblait que le cookie X11 servait à chiffrer avec un 3DES. Donc le cookie ne passe pas en clair et il faut que les deux cotés l'ai par une méthode ou un autre. D'où les commandes xauth un peu pénible et donc au final ssh -X qui fait le boulot à notre place bien mieux dans 99,99% des cas ;-)

X11 est tout de même chiffré via le cookie...

On peut pas l'héberger au parlement Européen, à Monaco ou dans les îles anglo-normandes ;-)

Ah, l'assembleur du 5502, une merveille. Lorsque j'ai du faire un TP sur 8086 quelques années plus tard, j'ai compris que c'est souvent pas le meilleur qui gagne ;-)

Pas Solaris, SunOS avec une souris optique et un tapis de souris métallique horrible... une daube de première ! En plus, j'ai toujours trouvé CDE complètement anti-ergonomique...

MacOS X, c'est le menu global, les applications en mode service (qui a dis variable globale), le click to focus, le plein écran, un faux X11 et un faux UNIX (allez faire une administration distante en ligne de commande des MacOS !). Bref, il y en a qui aime ;-)

SGI c'était vraiment autre chose effectivement. GL qui a donné OpenGL, inventor, des machines ayant un vrai design bien avant les MAC (aller voir leur produits en 92) avec un tendance sur le bleu très marqués. Le windows manager était vraiment pratique, en follow mouse, avec des grands écrans haut (pas ces daubes allongées et ou on ne peux pas mettre une feuille A4 verticale). Les icônes était vectorisé dans le gestionnaire de fichier... En 95 il me semble, les machines était déjà livré avec un webcam. On avait l'ancêtre de netmeeting qui permettant de partager un tableau blanc. Puis, il y a eu le partage d'objet 3D (je ne me souviens plus le nom) qui n'a toujours pas de vrai équivalent.

SGI, c'était aussi le système de fichier XFS (le seul que je mets encore sur des grosses partitions > 10To). Les fichiers systèmes était ordonné proprement (pas comme AIX ou HP-UX) et je soupçonne les gars de Debian d'avoir pompé le /etc d'IRIX tellement les deux était proche au début.

Après 2000, ça a été de plus en plus dur, SGI ne basculant pas sur autre chose que MIPS comme microprocesseur et a cette époque là, c'était déjà devenu une charrette coté performance, la carte graphique ne pouvant pas tout faire ;-)

Non car dans debian, tu rajoutes un nouveau dépôt et hop, tu ouvres ton système...

Justement, je viens de relire et je ne vois pas ou cela bloque, ce qui est dis est assez général sans exemple vraiment précis. PostgreSQL permet de faire plus de chose que MySQL. Je ne vois pas en pratique ou sont les limitations et ce qui coince. Désolé, c'est une question de néophyte mais avec une couche comme DBI au milieu, cela coince ou ?

A mon avis, très peu de personne parle réellement Anglais mais plutôt le dialecte Américain. J'aimerais bien avoir des chiffres si quelqu'un en a.

Quel est le vrai pb de supporter plusieurs bases de données ? Je ne maîtrise pas le Php mais en Perl par exemple, si on fait des choses de base, on attaque la base de donnée via le module DBI et on ne voit pas quel type de base il y a derrière.

Enfin, quitte à mettre du expect, autant tout faire dans un script Perl.

• libmail-imapclient-perl - Perl library for manipulating IMAP mail stores
• libmail-imaptalk-perl - IMAP client interface with lots of features
• libnet-imap-client-perl - Perl module to communicate with IMAP servers
• libnet-imap-simple-perl - Perl module to manage an IMAP account
• libnet-imap-simple-ssl-perl - Subclass of Net::IMAP::Simple with SSL support
• libnet-imap-perl - A client interface to IMAP (Internet Message Access Protocol)

Une grande partie de l'asie centrale parle le Russe (et pas un mot d'Anglais) !

L'amérique du sud est à tendance Castillane... et cela déborde sur l'amérique du Nord. J'ai croisé des personnes en Alaska prenant des cours d'espagnol afin de pouvoir parler avec le petit matériel ;-)

Au début de l'informatique et du web, l'anglais a eu son heure de gloire pour s'imposer mais les techniques ont évolués plus vite que l'hégémonie. Il n'y a plus de gros soucis de nos jours pour que la diversité s'exprime.

A t'on déjà eu autant de documents en Breton diffusés en libre accès auprès d'autant de personne ?

PS : ce qui m'inquiète plus, c'est le troisième cycle universitaire qui devient de plus en plus anglophone. Je ne suis pas sur que cela soit une bonne voie.

Malheureux, oser mettre Slashdot devant DLFP, c'est une faute de goût impardonnable !

Mon WE ne commence par le vendredi à 14h30 ;-)

En fait, c'est pas très malin dans ce cas là de lancer un débat et de partir en WE dans la foulée. Dans une news générale, tout le monde peut répondre et en général, dans les rares news que j'ai faites, j'évite si possible de trop intervenir. Mais dans le cas présent, il n'y a que lui et Roland qui peuvent réellement répondre.

Ceci dis, l'idée de libérer le livre est une très bonne idée. J'ai déjà trois versions à la maison et j'avoue que j'hésite à acheter le suivant. D'un autre coté, j'ai aussi le super livre de Martin F. Krafft qui n'a jamais eu de mise à jour et c'est effectivement dommage.

Il y a aussi la formation initié par Alexis de Lattre

http://formation-debian.via.ecp.fr/

Moi, je trouve dommage que Raf balance sa news et ne soit plus la pour débattre dans les 24h qui suive...