PLuG a écrit 1006 commentaires

A noter quand meme que unison est limité dans la taille des fichiers pour d'obscures raisons de langage de developpement ... donc restez en dessous des 2Go par fichiers.

et sinon il y a aussi duplicity (non testé) qui comme rdiff-backup utilises librsync pour ne backuper que les morceaux de fichiers qui ont changé (une VRAIE sauvegarde incrémentale !!) et stocke le tout au format tar !?! a tester donc! http://www.nongnu.org/duplicity/

Ben dans ce cas la utilises un bon vieux dump/restore. c'est un format lisible sur tous les unix avec restoration selective si besoin, et sauvegardes incrementales si necessaires ... dump/restore est tres vieux et dispo dans toutes les distrib dignes de ce nom.

Je pense que ceux qui ont voté - ce commentaires n'ont pas compris que ce n'est pas une connerie ...

250 clients j'aimerai bien savoir sur quels critères ils ont calculé cette limite entre parenthèses.

rappel: en WiFi 802.11b les clients partagent un canal de 11Mbps théoriques, plus proche des 7/8Mbps en pratique. C'est rééllement un partage (comme sur un hub pour rappeler des souvenirs), alors 250 clients qui arrivent sur un serveur de fichier dans ces conditions ...

OK je comprends mieux :-)
Je savais que quelqu'un allait se dévouer pour nous refaire le coup des serveurs en user-space, etc ...
J'ai bien lu tout cela mais je ne crois pas que cette différence soit si importante que cela dans le sens ou les avantages en souplesse ne sont pas interdit sur un noyau monolitique non plus...

D'un autre coté je n'ai pas dit qu'il fallait arreter sur le champ de coder Hurd hein ! La diversité ca a évidement du bon, surtout quand c'est de la diversité en GPL ou les expériences peuvent profiter aux 2 OS ...

De mon coté je ne comprends toujours pas l'interet de HURD face a Linux.
certes le bla bla habituel de micro noyau. mais dans la vie pratique les drivers ne plantent heureusement pas souvent sous linux, et pour leur developpement rien n'empeche d'utiliser user-mode-linux. Ton histoire de monter un serveur FTP en local existe deja sous linux (pas besoin de micro-noyau pour ca) ...

bref linux avec des modules c'est pas bien loin de notre futur HURD.
Pour moi le HURD c'est beau. mais ca n'apporte rien que linux ne peut faire.

Bizarre ca, gnucash (comme cbb) gerent les catégories (sous forme de comptes différent pour gnucash puisqu'il utilise le systeme de double entrée).
gnucash peut donc sortir les graphiques que tu cherches a obtenir AMHA.
et son système de graphes est assez ouvert pour que tu contribue un type de graphe supplémentaire au besoin ...
ne repart pas de zero avec un autre soft, contribue a l'existant pour l'améliorer encore !!

C'est juste. Je ne connais pas fam dans le detail. C'est pas un gros programme (140k). Il n'utilise peut-être pas beaucoup de fonctionnalités avancées du C++. Il est donc peut-être assez portable. Çà reste des supositions.

Ben justement, FAM est un daemon porté sur linux par SGI.
Les process qui en ressentent le besoin s'enregistrent auprès de FAM et son alors prévenus des modifications des fichiers qui les concerne dès que possible.
L'interet pour un filemanager est facile a comprendre: il demande a FAM de le prevenir de toute modification qui concerne le repertoire actuellement reperesenté à l'écran, il est prevenu dès qu'un fichier est créé/change/... et il peu donc mettre a jour les icones immediatement.

sous SGI, FAM c'est aussi un driver kernel qui evite de faire du polling. C'est le kernel qui averti le daemon FAM quand il fait des modif sur le fs. SGI a porté FAM sous linux, les intégrateurs en chef du noyau ont dit que l'idée était sympa mais que l'implémentation sucks, et ils ont remplacé le driver FAM de SGI par la fonction dnotify. RedHat a alors modifié le daemon original FAM pour qu'il puisse utilisé dnotify du kernel Linux et nous arrivons a l'état actuel.

Tout ca pour conclure sur le fait que le daemon FAM ne doit pas etre dur a porter en lui même, mais que sans la fonctionnalité FAM/dnotify dans le kernel, son utilité est moindre puisqu'il se met a faire du polling sur le filesysteme ...

Ben pour ca tu n'as pas besoin de logiciel de comptes !!
regarde juste ton solde quand tu en as besoin, en access https sur le site de ta banque. :-))

comme deja signalé, l'interet c'est justement ce cheque perdu et retrouvé au moment ou on ne s'y attend pas, ou les operations de CB frauduleuses.
Le plus repandu en matiere de fraude CB c'est la recharge de telephones mobiles (volés eux aussi). Ca donne des CB de montant raisonables et répétés mensuellement ... pas facile a detecter sans faire ses comptes !!

C'est juste l'interet d'avoir un logiciel de tenue de compte ...
oui j'en utilise un et j'avais commencé avec un livre donc je sais a peu près a quoi ca sert.
Ce que je trouve bizarre c'est de télécharger les infos de la banque, car pour moi l'interet c'est:
-de les saisir les opérations LE PLUS TOT POSSIBLE (et ne pas attendre qu'elles soient en banque) pour savoir combien il me reste a dépenser.
-de les pointer une a une pour voir si quelqu'un n'a pas utilisé mon numero de CB a l'insu de mon plein gré.

Ma question porte donc sur l'interet du TELECHARGEMENT DU RELEVE, et pas sur l'interet des logiciels de compte :-)

De mon coté je n'utilises pas ces imports automatiques, je ne comprends pas trop l'interet de faire ses comptes si c'est pour recopier ceux publier par la banque.
Pour moi l'interet de faire ses comptes c'est justement de COMPARER sa version avec celle de la banque en pointant les operations ...

Mais vous allez surement éclairer ma lanterne et me convaincre que je dois essayer ;-))

Essai cbb alors, c'est extremement leger (perl + tcl/tk), ca fonctionne correctement, les comptes sont stockés dans des fichiers textes normaux (separés par des tab ou des virgules je sais plus) et il y a une fonction d'export QIF au cas ou pour plus tard si tu veux passer a GnuCash !

je l'ai utilisé plusieurs mois, certains aspects ne me plaisaient pas mais ils ont surement encore progressé ...

http://cbb.sourceforge.net/index.html(...)

il n'empeche que le daemon FAM (le serveur) est en C++.
cela dit, je ne voit pas ce que ca change au probleme.

C'est clair que c'est pas un petit projet.

<mavie>
Je suis passé a GnuCash il y a pas mal de temps ...
j'utilisai un soft sous windows qui m'avait ete fourni avec un de mes PC.
il ne passait pas l'an 2000, l'editeur etait introuvable sur le web et ma misère coincée dans un format proprio sans solution d'export !!
j'ai donc utilisé 'imprimer dans un fichier' avec une imprimante texte-only et un script perl pour traduire ca dans le format texte de cddb (un projet GPL concurent a gnucash). cddb n'etait pas top, après plusieurs patchs il etait toujours moins pratique que mon precedent soft. la critique de ma compagne etait terrible et elle voulait MSMONEY.
Pour moi hors de question de me remettre dans la meme position avec un autre soft proprio. On a essayé GnuCash et hop pax romana dans le ménage ;-))
completion des saisies, graphiques, ... il fait plus que l'ancien soft (et surement moins que Money que je n'ai jamais essayé)
</mavie>
bref va falloir tester la nouvelle mouture.

A vous lire je pense qu'il y a un moyen... et qu'on l'utilise déjà.
J'ai commencé Linux il y a assez longtemps (noyau 0.99pl qqchose, SLS) et depuis je n'achete que du matériel utilisable avec Linux. meme ma camera DV Sony, mon reflexe a été "et le memory stick c'est standard quelque-chose ca ?, y a un driver ??". Evidement le vendeur ne sait pas, evidement j'ai trouvé l'info rapidmement sur le web (il fallait un patch a l'epoque) et evidement j'ai acheté le matériel après avoir validé tout ca.
Aux personnes se lancant dans des essais linux et ayant plein de problemes de matériel (scanner ...) j'ai expliqué le pourquoi/comment et je certifie que meme si ces personnes bootent la plupart du temps sous windows (peut-etre meme ont ils desinstallé linux), ils ont bien compris l'interet des standards dans les protocoles et ils valident le matériel qu'ils achetent autrement que "c'est pas cher".

Apparement, la plupart des lecteurs de LinuxFr sont dans ce cas, je pense donc que OUI nous apparaissons dans les stats des constructeurs de matériel. Si ATI NVIDIA et consor font des drivers (pas GPL, ok), c'est qu'ils nous ont vus. La prochaine étape sera qu'ils nous comprennent (GPL).

marrant moi avec les memes arguments je ne conclu pas la meme chose:

Le tout alors que la plupart des gens surfent sur le web en cliquouillant à partir de la page d'accueil de leur FAI.....
Donc ils n'en ont rien à foutre de la tronche de l'URL puisqu'ils cliquent sur un lien hypertexte. Moralité, que les URLs soient compliquées à taper n'est pas un problème. Ce qui compte, c'est qu'elles aient un sens quand elles s'affichent dans la barre d'adresse, et pour ça il faut que l'on puisse avoir des URLs dans toutes les langues, donc avec tous les jeux de caractères (ou plutôt tous les caractères d'UTF-8).

Ma version:
Donc ils n'en ont rien a foure de la tronche de l'URL puisqu'ils cliquent sur un lien hypertexte. Moralité, les chinois du FBI n'ont pas besoin de savoir taper simplement ces URL, ils n'ont qu'a cliquer. La souris n'est pas bloquée en mode américain j'espère :-)
Ce qui compte c'est que le site utilise un TITRE écrit dans la bonne langue, en UTF-8/16 puisque ce titre s'affiche dans la barre de controle de l'application (IE/Mozilla au moins) et que ce TITRE est visible meme quand le navigateur est iconifié (IE/Mozilla toujours).... allo ? excusez moi ... on me souffle a l'oreille que le contenu des pages HTML et donc le titre est déjà compatible avec UTF-8/16 !!!
Que demande le peuple ?

et eux il sne savent pas utiliser les bookmark ?
ok --> []

Franchement ?
pour nous c'est vraiment faire mal aux mouches.
soit tu utilises le web et tu sais déjà que les url sont sans accents, soit
tu ne le sais pas et le systeme va tout de suite te le dire avec un beau message 'url invalid', soit on te file un navigateur spécial débutant_du_web_qui_sait_pas_encore_cliquer et qui va remplacer les lettres accentuées par des lettres ascii simples.
Ca regle le probleme pour les langues a caractères latin.

Reste le reste du monde, et comme il a été dit plus haut:
1/ le reste du monde utilise un clavier capable de produire de l'ascii.
2/ le reste du monde SAIT utiliser ce clavier sinon il a de GROS problèmes pour utiliser son ordinateur aujourd'hui. Donc avant d'accepter tout les codes UTF-? dans les noms de domaines, il y a du boulot coté OS/BIOS/...
3/ un peu plus haut, quelqu'un dit que ne pas pourvoir saisir les URL c'est pas grave puisqu'elle ne sont pas tappées mais plutot cliquées ... ben alors pourquoi tout ce foin ? il sait pas cliquer le chinois ?? [nb:je tappe souvent des url ...]
4/ comme le dit bereta, si les URL deviennent moins universelles [et elles le sont dans le sens ou TOUT le monde peut s'en servir aujourd'hui], on va bientot s'en passer et filer des adresses IP sur nos cartes de visite, a moins que les chiffres arabes soient eux aussi remis en question ?

Je pense que tout cela part d'un bon sentiment [du moins je l'espère], mais dans la pratique ca me parait pas être une avancée si interessante a long terme, ni pour nous qui ne sommes pas trop genés, ni pour ceux qui n'utilisent pas notre jeu de caracteres, qui vont se retrouver "isolés" dans une toile en UTF-16. La liberté a un prix, peut-etre que le prix c'est de pourvoir cliquer sur des URL en ASCII sur toute la planette.

De même que cela ne me dérange pas "outre mesure" de considérer que sur le web on se doit de faire une version "in english" des infos si on veut leur donner une universalité... et que celui qui ne parle pas anglais est handicapé sur la toile...

Filtrer sur l'UA, c'est ni plus ni moins faire aux autres ce que l'on leur reproche de nous faire subir !!

Je ne suis pas sur que ce soit une preuve d'intelligence ...

Lucas, tu sera chatié et expulsé de la Communeauté, tu viens de rendre service au fils du daemon
ok, c'est par la ->[]

Fait gaffe quand meme !!
un scan de port sur une machine un peut fragile (genre un cluster HA AIX d'IBM non patché) et hop --> DoS.
Si tu freeze a distance le cluster HACMP vital pour ta boite, ils von t'en vouloir, même si ca démontre un probleme du coté du cluster ...

Bon j'y vais de mon astuce aussi.

hypothese: vous ecrivez un script qui doit renomer/deplacer/effacer des fichiers, bref qui est dangereux pour les datas si ca se passe mal.

mon idée: remplacez les appels a "rm" "mv" "cp" ... en placant un "echo" devant.

ca donne: monscript.sh
#!/bin/bash
ls | while read FILE
do
if ......
then
echo "rm $FILE"
fi
done

vous le lancez tel quel, tous les "rm /tmp/pipo/..." s'affiichent a l'ecran pour visualisation et si c'est bien ce qui était souhaité, vous relancez le script en
pipant la sortie dans un shell:
./monscript.sh | /bin/sh

chez moi ca evite pas mal de problemes liées aux fotes de phrapes ;-)

De plus dans la loi on n'autorise pas les citoyens a obtenir la clefs mais les eventuelles informations le concernant et ratachées a cette clef. c'est important mais cela n'empeche pas de cloquer la lecture des documents ou de fixer une date de peremption sur les emails ...

C'est marrant, moi je constate l'effet inverse: tous les admins unix qui posent les yeux sur mon terminal me demandent comment ca se fait que mon vi fait "arbre de noel" ... et si c'est faisable sous aix/sun/hpux/...
Parce que la coloration syntaxique ca a quand meme du bon !!
[maintenant, si tu utilise vi juste pour modifier /etc/hosts c'est sur que ca perd de son interet ...]

d'ailleur sous AIX maintenant les admins ont décidé de déployer RPM qui est fourni par IBM. Ensuite, ils pourront installer les packages produits par IBM pour tous ces outils inutiles donc indispensables: bash / vim / less / ...