or zax a écrit 195 commentaires

tu as un /etc/ftp ou quelque chose ?

le serveur ftp peut très bien être réglé pour empêché toute modification, et là c' le FTP qui te bloque quoi que tu fasse sur les permissions des fichiers. C'est pour çà que la configuration du serveur FTP mérite attention

Quel est le serveur FTP que tu utilises ?

Quel est son fichier de configuration ?

Dans un premier temps je vais essayer ce que tu me dis.

Puis plus tard je le referais soit en C soi en ADA (pas eut l'occasion de le tester ce langage encore) je sais pas

chez moi c'est pareil.

Ce serait une bonne chose oui de faire un mirroir

Si j'ai bien compris le commencement de la conversation, "neuneu" était utilisé au sens de bourrin qui ne réfléchit pas qui va dans les salons linux pour dire au combien linux c'est nul est *bsd c'est génial. Ce n'est pas dans le sens débutant ou plutôt utilisateur incapable de lire une documentation, mais plutôt le genre moi je suis un bon un vrai de la dur vous vous êtes des nazes, bref tu vois le genre de réaction d'adolescent pré puber qui se moque des gens qui demande de l'aide dans les forums.

tous ces outils ont des approches très intéressantes, mais trop spécifique à certaines utilisations.

si je veux faire un mot de passe utilisant les probabilités suivantes :
Minuscules : 0.33333334
Majuscules : 0.33333334
Chiffres : 0.16666667
Speciaux : 0.16666667

ou autre chose, difficiles car les outils manques de flexibilités.

Certains font des clients et des serveurs de génération de mot de passe, cool mais pas utile, d'autres sont là pour faire des mots de passe prononcable, sympas par contre mais restrictif. Ou alors générer des mots de passes binaires pour des applications (excellente idée d'ailleur, on y pense pas souvent mais c'est utile)

J'ai vu une fois une applet java sur un site proposé ce genre de flexibilité, malheureusement en outils ligne de commande ça manque.

Quelque chose de conceptuellement simple et flexible il n'y a pas beaucoup de choix.

Pour le langage JAVA, je l'avais fait ainsi pour délirer. Du C ou de l'ADA ou n'importe quoi d'autres dans la pratique sera plus adapté que JAVA.

Un petit utilitaire tout simple regroupant un peu toute ses qualités, serait sympas, qui ne fasse que la génération de mot de passe, mais sache faire tout ce qui concerne les mots de passes serait une modeste contribution mais sympathique tout de même, donc si ça intéresse quelqu'un ....

ridicule c'est certain, c'était une excuse pour tester les apis, je l'assume complètement

Les propositions qui te sont faites te donnent l'information : à partir de quel machine tu établis la session SSH.

avec la commande "who" tu vois qui est connecté et depuis où, si tu veux voir même les connexions passé, "last " fera ton bonheur.

http://www.mandrake-linux.com/fr/fdoc.php3
A cette adresse tu as des guides de démarrage rapide qui t'accompagne dans ta migration de windows ou mac vers linux, en t'indiquant les applications phares selon ce que tu veux faire. ils sont super bien fait, c'est que du bonheur.

Bienvenue à toi dans un monde libre

En fait le serveur X du serveur SSH n'est pas utilisé, ton programme X envoi les instruction au serveur X de la machine cliente.

Donc le serveur X du serveur ssh n'est pas nécessaire, tu peux lancer une application sur une machine qui n'a pas de serveur X hé hé !


Par contre juste une chose, évite de lancer des applications root de cette façon, car le serveur X de la machine cliente peut laisser communiquer les programmes de la machine cliente avec ceux du serveur sans distinction sur le fait de qui appartient à quel compte.

Pour ma part j'utilise des distributions comme mandrake ou suse (surtout suse maintenant) selon les cas, dans la pratique je n'utilise pas le support vu que je télécharge les isos.

Par rapport au décideur, le seul intérêt est lorsque l'installation est externalisée. Exemple, tu fais du développement, et la direction ne veut pas te débloquer du temps pour faire l'installation, donc tu achètes du pré installé avec Oracle etc ...
Ce cas de configuration arrive lorsque les rapports sont difficiles, maintenant si ils te font confiance, choisis n'importe quel distribution mais en fonction de la communauté, exemple mandrake ça bug pas mal mais il y a du monde, donc beaucoup d'info compenser , suse très carré mais récent en france, donc la communauté est jeune et pas forcément bon, donc tu es obligé de passé par la mailing list suse en anglais et là c'est bon, debian avantage la mise à jour et le changement de génération ca marche tout seul, par contre la communauté, suffit de voir les commentaires cela montre bien la mentalité qu'ils ont et l'image qu'ils ont d'eux même.

Après tu as d'autres distrib qui sont très sympas comme la slackware, orienté configuration dans les fichiers textes directement sans outils, mais des commentaires partout et très précis.
Unbuntu, beaucoup de gens en parle en bien, je ne la connais mais à tester aussi

Pour la sécurité, ce n'est pas la distribution qui va déterminer le niveau mais ton sérieux, exemple si tu es du genre à vouloir montrer que ta machine tourne depuis 1 an sans interruption comme une communauté de distrib que je ne nommerai pas, ça fait un an de patch de sécurité pour ton noyau qui n'est pas appliqué, méfie toi des outils qui font des pré-réglages de sécurité, tu dois t'assurer que tu peux tout contrôler à la main dans un terminal (c'est souvent la cas maintenant) donc dégrossi le travail avec les outils, mais affine après.

Par conséquent la qualité du serveur dépend de toi, prend la distribution ou tu te sens à l'aise, ou l'information est accessible et c'est parfait.

si tu ne veux pas faire d'accès distant désactive ssh, il te sert à rien, pour apache fait le écouter uniquement en localhost.

La plupart des services sont inutiles si tu n'accèdes pas au moins de ton réseau local.

Pour le ping ce n'est pas bien méchant, moi je l'ai bloqué au niveau de shorewall, mais au besoin suffit de supprimer la règle.


Ta machine c'est pour faire un nat ?

tu n'as pas besoin de récupérer un module, tu peux charger un module noyau dans l'interface du mini iso.

Donc si tu connais quel module va avec ta carte c'est gagné.

Pour moi l'installation réseau est passé comme une lettre à la poste.

si tu vas dans /etc/sysconfig/hardware/ tu dois avoir un fichier qui sert à identifier ton périphérique réseau et lui associer un module, tu dois pouvoir lui indiquer des options pour qu'il passe en full-duplex je pense.

Juste pour voir essai avec un prio de 0 partout, car si la limitation de bande passante est bien ajusté, tu n'as peut-être pas besoin de mettre de prio différent.

Le principe est que ce n'est que quand les prio sont vides que il passe à la suite, donc de freiner sur l'utilisation de la bande passante sera peut-être suffisant vu que ce sont des flux constant.

Le prio c' vrai que c'est prévu pour assurer le ssh ou des trucs commes çà.

la classe mère n'est pas 1:1 mais 1: normalement.

puisque tu met
tc class add dev eth0 parent 1: classid 1:11 htb rate 113 ceil 113kbit

si 1:1 doit être la mère des autres classes

met
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 113 ceil 113kbit

et là 1:1 est le parent de 1:10 et 1:11


Donc tu profiles tes différentes utilisation, tu te débrouilles pour répartir le quota pour que le total fasse ton maximum d'upload et c'est gagné

pour la partie voix, le but du jeu est d'attribuer peu de bande passante mais un maximum de priorité. Car là ou tu donnes une priorité il faut pas qu'il puisse prendre tout l'upload, donc tu indique ton prio mais ceil tu met juste le nécessaire

Il y a quelque chose qui me surprend.

tu as 128k d'upload
et tu garantis à la fois 128k + 15k + 113 o donc 143k +114 o soit plus que tu ne dispose.

Normalement il faut que le cumul des taux que tu garantis fasse les 128k.

Une chose intéressante aussi est que si au réel tu ne peux envoyer pas plus de 128k, pour éviter de saturer la mémoire tampon de ton modem, que tu envoi que 80% de ton upload maximal, car dès que le tampon de ton modem est plein, tu peux causer des perturbations sur ton download.

on peut partir aussi sur le principe de la chronologie d'une utilisation normale.

tu créé une variable session, et à chaque fois que tu charge une page, tu l'indique, comme cela dans la page suivante, tu sais quel est la page précédente, le but est de faire un referer mais côté serveur, car on ne peut jamais compter sur le client.

Donc quand tu charge ta validation de formulaire, si le précédent est la page de validation et pas le formulaire normalement attendu, tu fais une un traitement gérant ton erreur selon ton humeur.

Ou faire un pont pour que subversion lise des dépôts Arch, et Arch lise des dépôts subversion, comme cela on garde une spécialisation dans les projets, en augmentant la simplicité des concepts de chacun et donc leurs fiabilités.

tout à fait.

Mon intervention visait à replacer certains point notamment par rapport aux performances.

Linus Torvalds à une grande masse de travail d'incorporation à faire et il ne souhaite pas changer ses habitudes, ce qui est légitime.

Ce qui m'inquiète plutôt est la perennité du GIT, tant qu'à développer quelque chose, il faut que çà dure, sinon on ne fait que retarder la résolution du problème.

Le temps portera donc conseil, en espérant que le choix de Linus se révélera être le bon, car pour l'instant il essait de faire quelque chose qui réponde à se besoins.

Oui, mais prend mon cas personnel (qui n'est pas celui de tout le monde heureusement), je n'ai pas internet chez moi, donc quand je rentre chez et souhiate coder, je n'est pas besoin de faire les commits sur le serveur central.

De plus plus personne n'a besoin de se connecter au central, sauf pour faire les update de temps en temps :
_ économie d'infrastructure, car quand il faut gérer un grand nombre de contributeur ....
_ gain en sécurité

Pour la gestion des branches c'est identiques en centralisé, le distribué par sa nature te pousse juste à plus les utiliser. Car les branches sont le couteau suisse du distribué, tu fais pratiquement tout en jouant sur les branches, l'outil est accès sur cela

Ce qui me plait c'est le fait qu'il n'y est pas de serveur à installer, c'est rapide.

Donc l'un n'est pas mieux que l'autre, c'est juste une façon de travailler un peu différente.

SVN pour être franc je ne l'utilise pas mais j'ai une excellente opinion dessus sur le fait que je ne lui connais pas de critique parmi ceux qui le test, et le fait qu'il soit centralisé n'étant pas un défaut ...

Donc pour conclure, la question n'est pas ce qu'il est possible de faire ou pas avec l'un et l'autre mais la façon de travailler.

en centralisé, tout le monde se connecte en même temps sur ton serveur,

en distribué tout le monde à son propre dépot, donc tu décide de corriger un bug, en créant une branche dans ton dépot, tu préviens le responsable du projet en lui donnant l'accès, si ça l'intéresse il intègre en fusionnant ta branche dans la branche principale, sinon il fait rien, mais d'autres intéressés pourront l'intégrer pour eux.


De plus ça minimise le nombre de changeset, si il faut 20 changesets pour corriger le bug, dans la fusion de la branche le mainline ajoute un changeset regroupant toute ta branche.

Tom LORD, l'auteur de Arch/tla à envoyé une lettre personnelle expliquant le principe, les objectifs, et les possibilités de Arch.
De plus sur la lkml, et par des mails privés, Linus THORVALD a reçu des benchmarks sur l'intégration de tous les changesets, du noyau, ainsi que des benchmarks sur des cas d'utilisation, à la fois côté mainteneur et côté développeur.

L'utilisation de Arch sur le plan performance ne pose aucun problème, j'ai moi même fait des tests poussés, en respectant la règle du "je test dans le pire des cas".

La question est est-ce que la logique de Arch lui plait ou non ? Monotone semble plus lui convenir, et enfin, après les longues discussions enflammés ou il a dut défendre bec et ongle bitkeeper par rapport à l'utilisation des autres solutions, va-t-il avoir le courage de se tourner vers des solutions qu'il avait cassé ? (souvent à juste titre, on compare avec le niveau actuel des outils, mais auparavant c'était catastrophique).


GIT est la solution facile.

Mais peut importe il faut voir si cette solution à une perennité, si ce n'est pas le cas, développer son propre outils ne sert à rien et ne fait que reculer l'échéance et gaspiller les efforts

La gestion des branches associé à la gestion des distributions (projet découpé en sous projets) je voulais dire au début, désolé pour la coquille ;)