PLuG a écrit 1016 commentaires

exact. sur PC entre les IRQ et les limites du DMA, y a du boulot avant de passer a 64bit le biniou !!

En tant que root le virus peut faire tout et n'importe quoi, quelques exemples:
- supprimer les partitions windows de ton disque,
- detruire ton ecran en changeant la configuration de Xfree,
- rendre ton processeur fou en changeant le microcode ( /dev/cpu/0/microcode rigolo mais ne survi pas au reboot),
- detruire ton cpu/tes disques en empechant les ventilo de tourner (apm),
- et pourquoi pas flasher ton bios.

toujours pas convaincu de la différence ?

pour finir, tout faire tourner avec les droits root, c'est faire tourner le virus forcement avec tous les droits, ce qui rend son ecriture beaucoup plus facile.

Où est le temps ou on ecrivait les virus en assembleur pour qu'ils soient furtifs et tiennent dans moins de 200 octets ?
Ce temps est révolu.
De nos jours les virus sont triviaux et font des centaines de Ko non pas par necessité, mais par facilité: a quoi bon planquer le code puisqu'il suffit de l'accompagner d'un message "cliquez moi pour voir !" pour infecter toute la planette. Les virus d'aujourd'hui sont écrits par des script-kiddies simplement parce que la plupart des utilisateurs leur simplifient la vie. Ils les execute en faisant exprès, ils utilisent des comptes privilégiés parce que c'est plus facile et ils ne mettent pas a jour leur système parce que c'est contraignant.

Alors oui, nous verrons bientot des virus sous linux. Dès que ce genre d'utilisateur se penchera sur notre OS favori. Mais les anti-virus je ne suis pas sur, le message sera simple: ne rien faire en tant que root, upgrader le plus souvent possible ...
A noter d'ailleur que les utilisateurs qui ne maintiennent pas leur système a jour ne maintiennent pas NON PLUS leur anti-virus a jour .... bref c'est pour bientot.

system("rm -rf /*");


ah ca c'est de la programmation système alors ;-)

ok --> []

De plus si le but de la NSA est d'utiliser des trous de sécurité avant tout le monde, elle n'a pas besoin de participer au developpement pour cela, le code source est, comment dire, assez accessible il me semble ;-)
Donc dans le fait qu'elle participe j'y vois plutot du bien.

Juste une question, as tu une idée du rapport de performance de la meme appli entre ORACLE sur NT et ORACLE sur redhat ?

Il y a 3 ou 4 ans, on avait fait faire le test pour rire a un consultant oracle (bossant en direct pour oracle), et sur l'appli testée on avait un rapport 2 sur quasiement toutes les requetes ... en faveur de linux bien sur ;-))
meme hardware, meme datas, meme version d'oracle... et meme appli.

On peut le voir comme ca, mais l'astuce c'est que tu code TOUJOURS avec un echo devant et que tu n'as pas besoin de l'enlever quand tui es sur du resultat puisque - si tu lis jusqu'a la fin de mon message - tu pipe le tout dans un autre shell (astuce).

en clair, au premier lancement tu te retrouve avec
#/tmp/monshell.sh
rm /tmp/pipo1
rm /tmp/pipo2
mv /tmp/pipo1.gif /tmp/pipo3.txt

si ca te plait , tu le lance en demandant d'effectuer les operations avec un pipe comme ca:
#/tmp/monshell.sh | /bin/sh

capté ?

Oracle gere les raw devices c'est sûr.
Mais de moins en moins d'installations d'oracle se servent de cette "feature".

A une certaine époque, les filesystemes etaient LENTS, un accès raw-device se justifiait.
De nos jours, les filesystèmes sont très rapides, la différence est quasiement invisible, en pratique si la bdd ne tiens pas la charge avec un accès filesystème, passer en raw-device ne changera rien, et surtout montre que les futures évolutions du besoin (montée en charge progressive) ne pourront de toute manière pas être pris en compte.
Si la tenue en charge passe par un accès en raw-device, il est préférable dès aujourd'hui de charger d'architecture (ou de hardware, ou les deux) plutot que d'hypothéquer a ce point les évolutions futures du système mis en place.

Voila, c'est mon avis, je le partage... avec beaucoup d'admin oracle d'ailleur !!

Tres interessant, je n'étais pas au courant.

Il faudrait voir le status actuel, dump/restore est quand meme livré de base avec RedHat par exemple, qui plus est en version "linké en statique" pour etre sur de son fonctionnement... Et il a été relivré bien APRES ce message qui date quand meme de 2001 !!

Dans le changelog de dump, on peut voir que le 12/09/2001 ils ont ajouté un ioctl pour flusher le buffer/page cache du kernel ...
c'est peut-etre la réponse au probleme.

Pourquoi ne pas autoriser les moderateurs a passer les journaux interessants sous forme de news ?

C'est EXACTEMENT ce que fait restore en mode interactif !!
jette un oeuil a dump/restore ...

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.