fcron pt etre ?
Je crois que mandriva travaille à une distribution plus axé sécurité afin de passer un niveau Je ne sais pas si c’est le 3 le 4 ou le 5 pour pouvoir travailler avec l’armée française.
Je suis curieux de connaitre la position des bsd dans ce critere d’évaluation. Par ailleur debian n’y figure pas. J’imagine qu’il faut etre une société et aligner les bifton pour ne serait-ce qu’etre candidat à la CCEAL ?
pour le niveau Common Criteria Evaluation Assurance Level
Mandr(ake|iva) préparer un système Linux qui doit repondre au niveau 4 ou 5 il me semble avec d’autres éditeurs pour le ministère de la defense française.
Arf je cherche mais ne trouve plus de news à ce sujet
Je connais tres bien les grands schedulers du marché que sont OPC, $U et CTRLM mais je n’ai jamais vu aucun tourner sous Linux.
Je me pose donc la question de la fiabilité sur cette plateforme… De tte facon, ce sera $U le scheduler chez nous pour Linux.
Donc si quelqu’un l’utilise chez lui, merci de me faire part de ses impressions.
C’est cool que Mdk se penche sur le niv 5 de sécurité mais bon pour l’instant y a bcp de boulot. Il suffit de voir les problèmes de faille de sécurité qu’on trouve chaque mois, l’arrivée de virus sous Linux… Toutes ces choses que ne connait pas z/OS :love:
On vient de te donner les principaux scheduler de linux et tu les balaies d’un revers de main sans même les tester ?
L’arrivée de virus sous linux [:galop] ???
D’autre question à poser sans attendre les réponses ou ca ira ?
Au lieu de garder ton expérience pour toi, donnes les arguements qui font de $U un meilleur scheduler, ca ne pourra en être que bénéfique pr la communauté et l’amélioration des scheduler actuel fonctionnant sous linux.
Contrairement à ce que tu semble croire, nous ne sommes pas fermé à la nouveauté, pour peu que l’on présente des arguments sérieux.
N.B.: J’imagine que tu a un mainframe chez toi ? [:dunk]
C’est pas moi qui décide les choix d’architecture. Hier nos experts ont décidé qu’afin de garder une homogénéité des schedulers on aurait OPC sous MVS et $U sur les Unix (Unix & Linux).
De plus, le manque de support sur les produits Open Source et surtout le manque d’utilisation de la part des entreprises rend nos experts un peu frileux.
C’est pas pour emmerder le monde mais la décision n’est pas la mienne et la journée d’hier a fait que la réponse est $U.
Voilà pourquoi ce sera $U.
Maintenant de ce que j’ai vu entre $U, CtrlM et OPC, c’est OPC qui a l’air d’être le plus puissant avec notamment la gestion de plan à long terme. CtrlM est très bien aussi mais n’a pas de plan à long terme (dommage) et $U n’a apparemment pas de gestion de plan courant. Donc je vois pas comment ca fonctionne !.. Voilà ce que j’ai remarqué.
Par rapport aux 2 cités : fcron et diogene.
1/ ce ne sont pas des outils centraux dans le sens ou on doit les installer sur tous les serveurs et on a pas de gestion centralisée des jobs des serveurs.
2/ pas de gestion des calendriers. Ex : certains jobs applicatifs n’ont pas besoin de passer les jours fériés. OPC, $U et CLTM gèrent ca.
3/ Docs archi minimalistes!
4/ Comptes rendus. C’est du archi archaique avec la console ! Faut pas avoir 25000 jobs à vérifier! Diogene semble avoir une interface Web c’est bien.
5/ Visiblement pas de plan à long terme mais sans gestion de calendriers c’est logique.
6/ Aucune possibilité de reprise des jobs?
7/ Aucune présentation graphique ou pseudo graphique des chainages entre jobs. C’est dommage parce que si la chaine est complexe, faut l’avoir noter sur un papier dans ce cas!
tes sources datent de 1995, 1996 et au mieux 2001 (c’est un peu ancien ) :heink:
bien sûr qu’il existe quelques virus, mais à mon avis ils ont surtout été faits pour l’exploit technologique, pas plus.
Bon ben suite à une réunion, le projet est compromis sur la plateforme LAMP.
Les raisons invoquées:
1/ Manque de support
2/ Mysql 4.0 (version utilisée actuellement ou je suis) ne gère pas le UTF-8 hors on en a besoin…
3/ l’application aura pas mal de MAJ par batch et PHP n’est pas un langage fait pour le traitement batch
4/ du fait des batchs, le SGBDR doit etre performant en écriture, ce qui n’est pas le cas de Mysql.
5/ très mauvais retour de $U sous Linux… pas plus d’infos…
Donc voilà, il y a de grandes chances pour que ce projet n’aboutisse pas sur une plateforme LAMP finalement mais sur du Websphere/J2EE sur plateforme z/OS ou HP-UX.
et pour avoir un truc puissant avec utf8, utilisez postgresql.
Quand au manque de support, vos experts servent a quoi ? :heink:
Sinon, il y a beaucoup de societes qui font du support pour les LL (redhat, suse, mandriva, idealx, linagora, et plein d’autres), il suffit de leur passer un coup de fil et signer un contrat-qui-va-bien
Mysql pas un moteur de BDD relationnelle??? :heink:
Les experts ne peuvent pas tout savoir. On a toujours besoin de support…
De tte facon le probleme majeur est technique (UTF8, manque de performances en écriture de Mysql et PHP n’est pas un langage de traitement pour le batch).
) :heink: