Revert de subversion.spec subversion.spec-mat.patch.
------------------------------------------------------------------------
rev 31: anonymous | 2002-07-17 02:27:36 -0400 (mer, 17 jui 2002) | 1 line
Petit adaptation de packages/rpm/subversion.spec-mat.patch pour suivre les modifs de subversion.spec.
------------------------------------------------------------------------
rev 25: anonymous | 2002-07-16 19:34:52 -0400 (mar, 16 jui 2002) | 1 line
Tous ce qui est spécifique à matias contient "-mat".
------------------------------------------------------------------------
rev 24: anonymous | 2002-07-16 19:14:53 -0400 (mar, 16 jui 2002) | 1 line
Mise à jour des patchs pour construire les packages rpm.
- - - - - - - - - - - - - - - - -
Sinon, si tu tients à travailler à l'ancienne, une ne fait des modifications de l'aborescence qu'un fichier à la fois :
$ svn commit -m "Ajout blague du jour" README
Version 10 commited
$ svn commit -m "Ajout blague du jour" cmdline.c
Version 11 commited
$ svn commit -m "Ajout blague du jour" cmdline.h
Version 12 commited
> C'est surtout très lourd d'avoir apache si on n'en a pas besoin.
Le problème, c'est libapr qui est une couche qui facilite la portabilité. Subversion tourne sur Unix Mac OS X , Windowns, etc... Et çà en version Alpha. Leur choix d'utiliser libapr est bon.
Le problème est que libapr est livré avec Apache 2.0 et n'est pas encore totalement séparé d'apache : C'est en cours.
Je me suis fait des packages rpm d'apache-2.0 qui s'épare libapr d'apache. Sur une becane qui doit rester en Apache 1.3 j'ai :
apache-1.3.22-2
httpd-libapr-utils-0.2002.06.25-1
httpd-libapr-0.2002.06.25-1
subversion-0.13.2-2639
=> Donc du peut utiliser Subversion sans Apache 2.0.
sur un autre becane, utilisée pour compilier subversion :
httpd-2.0.40-1
httpd-devel-2.0.40-1
httpd-libapr-0.2002.06.25-1
httpd-libapr-devel-0.2002.06.25-1
httpd-libapr-utils-0.2002.06.25-1
httpd-libapr-utils-devel-0.2002.06.25-1
subversion-devel-0.13.2-2639
subversion-0.13.2-2639
subversion-server-0.13.2-2639
Ici, pour avoir Subversion-server il me faut apache.
Par contre apache (libapr) est nécessaire pour compiler subversion.
Actuellement c'est un peut lourd d'installer apache-2.0, neon, db4 pour avoir subversion.
Mais comme les futurs (très proches) distribes auront apache-2.0 en standard, çà va s'arranger.
Le problème est que Mandrake a toujours été en avance sur RedHat côté desktop. RedHat fait un peut le forcing pour leur prochaine distribe côté desktop. Mandrake se retrouve comme un con en train de proposer la même chose de RedHat. Alors pour "signer" leur différence il font ... ce qu'il peuvent.
Je parlais pas d'un manque de version majeur et expliquait pourquoi il fallait plus de version majeur mais l'inverse. J'ai indiqué que la fréquence est élevée sans réelle justification.
Quand faire une changement majeur?
Pour moi c'est une décision du distributeur et pas une soit disant incompatibilité de librairie.
Sortir rarement des versions majeur d'impose de faire attention aux compatibilité. Si le distributeur ne veut pas se faire chier, il sort une version majeur à chaque fois.
Alors, cette situation te plait peut-être, tu trouves que le 8.0 y fait jolie chez toi mais en entreprise tout ces versions incompatibles en 2/3 ans, c'est naze. D'avoir une Mandrake 7.0 d'il y a deux ans (ou moins) incompatible avec une proche Mandrake 8.0 (Comme c'était le cas avec 6.0 et 7.0). C'est naze, naze, naze.
Et maintenant tu ne peut pas reprochez les incompatibilités que fait parfois Microsoft ! Linux est bien plus fort !
> qu'est ce qui peut motiver une montée de numéro alors celon toi ?
Quand il y a de vraies et justifiées incompatibilités et ce n'est pas limité à une incompatibilité binaire...
Mais, pour moi, c'est pour signifier que la version N.x peut faire tourner les programmes de la version N-1.x et non les programmes N-2.x qui ne sont plus supportés. Une versoin major pour une distribe doit arriver tout les 2 à 3 ans. Mais tous les distributeurs sortent une version majeur tout les 12 à 18 mois. La fréquence est trop élevée. çà signifi qu'un programme de 2/3 ans n'est plus supporté !
> Uniquement un changement majeur de version du noyeau ?
Non. Et un changement de noyau ne justifie pas un changement majeur ! Passer d'un noyau 2.2 à 2.4 n'a pas d'impact important sur un utilisateur. Perso, j'ai pas remarqué grand chose... (y en a qui vont péter un plomb... en disant patati système de fichier journalisé ... patata un autre truc...) La méthode de configuration du noyau n'a pas changé depuis Linux 2.0 (arrivée des modules)... Enfin, l'arrivé futur de Linux 2.6 ne justifi pas de version majeur. Il y a alsa mais alsa a un module qui offre une excellente comptabilité avec oss. De plus, Linus a indiqué son intention de "ressérer" les sorties sortie de Linux.
> Perso j'estime que casser la compatibilité de libs partagées de base mérite une telle montée en version.
Et non.
Linux à tout (ou presque tout, contrairement à windows, pour faire cohabier différentes librairies, voir différents format de binaire , le a.out n'est plus supporté d'accord, mais elf est utilisé depuis linux 1.2).
Sur un serveur RH 7.2 qui utilise de vieux programmes, j'ai glic5 glibc2 et glibc2.2 (glibc2 est la suite de glibc5 !).
J'ai également 2 loader : ld-linux.so.1 et ld-linux.so.2 pour supporter elf V1 et elf V2.
Ceci me permet de faire tourner des binaires développés à l'origine sur une Slack avec noyau 1.2 (autour de 95/96) !
çà montre que les changements de version majeur c'est uniquement des choix de distributeur et non une limitation technique.
Cette petite expérience m'a permis de contrater de RedHat (mais tous les autres sûrement) ne fourni pas le minimum de base pour faire tourner (je dis pas compiler !) des programmes qui n'utilise que la libc et qui ont été développés sous RedHat 5.2 ! J'ai été dans l'obligation de créer des packages sous RH 6.2 (ne se compile pas sous RH 7.2 mais çà ce n'est pas un reproche) de libc5 et ld-linux-1 pour conserver un système "rpm-base".
C'est scandaleux ! car la 5.2 date de 99/98 seulement !
Je n'aime pas Microsoft, mais ils sont bien, bien meilleur avec windows ! On faire facilement tourner des programmes win95 (voir win3.1) sous win2000/XP !
> Et pour une distrib orientée desktop (c'est comme ca que je vois lamandrake, pas de troll please) que changer les API de KDE et gnome (kde 2.2 => 3 et gnome 1.4 => 2) mérite aussi un changement de version.
Bof...
S'il faut changer de version majeur parce que kde 2.2 => 3, gnome 1.4 => 2, gcc 2 => 3, apache 1.3 => 2, etc... çà nous fait 2 à 4 versions majeurs tous les ans ! C'est trop.
Regarde les unix commerciaux qui ne changent pas de version majeur car leur compilateur ou noyau a évolué, car il sont passé de motif 1.2 à motif 2, car, car, car...
Il pense, tient Gnome/KDE devient interessant, on va mettre la version 2/3 dans notre prochaine version majeur et çà roule pour 3/5 ans.
> Je crois que debian a aussi changé récement son numéro principal non ? alors pourquoi met tu debian de coté ?
débian est à 3 en numéro de version et pas 8 ! entre la 2 et la 3 il y a de grosses différences ! Pour passer de 2 à 3 il ont mit près de 5 Ans (un Debian user pour confirmer? Je me rappèle que Debian était à la version 1.3 en 95).
Définitivement, il y a trop de version majeurs de GNU/Linux. C'est peut-être un mal nécessaire pour que la partie desktop se stabilise. gnome 2 (qui sera suivi assez rapidement par 2.2) a déjà une pérénité significative. gnome 3 ne devrait pas arrivé avant un bon bout de temps et sa pérénité sera enfin significative (peut-être 4 à 5 ans). Quand je pense que certains gueules car gnome 2 a été long à sortir, ils n'ont pas fini d'être déçu...
Faut pas tout mélanger. Car sinon tu va admettre que visual basic est un language très puissant.
Perl (comme php, python, etc...) c'est un language et des librairie de base (en générale écrite en C). Si tu prend perl que du ajoute le binding pour gtk, gnome, bonobo, gconf, etc...
ben du fini avec 3 % de perl et 97 % de C. Dans ce cas, on ne peut pas dire que perlbox soit principalement écrit en Perl !
Le problème est que l'on avait décidé de se fixer sur RH (à tort ou a raison, çà pouvait être autre chose ...). Un gus s'amène et pour des raisons de sécurité (totalement caduque pour un réseau local) choisi une debian.
Je rappel que j'était principalement développeur.
> Ton collègue a peut-être mal apprécié les moyens.
Non, il est butté. Je comprend que l'on puisse mal apprécier une situation (temporairement). Mais camper sur ses positions uniquement pour des raisons de principes (sécurité, séparation serveur/développement) fini par me soualer. Surtout que c'est toutjour ma bécane de "merde" qui fait le gros du boulot. Que c'est moi qui configure apache/php/postgresql et les backup car cette "pointeure" d'admin debian doit se concentrer sur l'installation d'un outil de statistique d'utilisation de firewall.
> ton problème avec lui est lié au fait qu'il utilise Debian ou tout simplement parce qu'il est comme ça...
oui. evidament.
J'ai rien contre la distribe (que je connais mal d'ailleur). S'il était un bon administrateur même avec sa débian et était à l'écoute des utilisateurs / problèmes. Il y aurait partiquement rien comme problème.
Je parle de cette esprit que l'on retrouve plus souvent dans les administrateurs de debian, qui se prennent pour de grosses élites car il font une fixation sur la sécurité, utilise une Debian et qu'a ce titre ont des tonnes de merde dans les oreilles.
Je rappel le PS que j'ai mis au début du thread.
PS : il est claire qu'il y a de très bon utilisateurs de debian et je regrette pour eux que certains leur donne une mauvaise image.
> pour but de créer un concurrent direct à Gnome et KDE.
Quand je vois le nombre de ligne nécessaire à gnome en C. Même si perl est plus éficace en terme décriture, çà fait encore beaucoup de ligne. Niveau performance et utilisateur mémoire çà va devenir des trucs monstrueux...
Pour une machine accessible depuis l'Internet je suis intransigant. Que du ssh (compte root interdit), que des comptes ftp séparé des comptes système et avec chroot, mot de passe "compliqué". etc...
Je parlait d'une bécane sur un réseau local. si quelqu'un du réseau local veut les donnés il peut au pire piquer le disque dure, copier les données chez lui et remettre le disque dure.
> Entre autres faire le moins de choses possibles sous le compte root.
absolument. Quand je donne le compte root, c'est pour que les utilisateurs ne soit pas arrêté dans leur boulot car il ne peuvent pas faire un mkdir ou éditer httpd.conf. Pour contre, s'il font une connerie, je les allume. Dans la très grande majorité des cas, si je suis là, il me demande de faire le boulot (préférant que ce soit moi qui fasse une connerie sous le compte root :o) ).
> Euh... Effectivement, dans l'industrie,
C'est un problème de moyen. Si t'as les moyens, tu le fait. Ma bécane était très chargée et avait un pII 233 et 128 Mo de mémoire et pas question d'acheter un autre PC !
Par exemple.
Ceux qui sont malades ont une espérances de vie plus faible.
Ceux qui sont malades prennent des médicaments.
Donc si on fait un sondage sur l'utilisation des médicaments et l'espérance de vie, on en conclu que la prise de médicament diminue l'espérance de vie.
Le sondage du Linux-Journal est un sondage sur l'utilisation d'un formulaire.
Et on a des statistiques sur l'utilisation du formulaire qui pose la question "quel est votre WM préféré ?" :
=> enlightment (valeur par défaut)
=> fvwm2
"Quel est votre WM préféré ?" n'est pas "Quel WM utilisez-vous actuellement ?".
Je peux utilisé fvwm2 et préférer enlightment (j'ai vu des screenshots top-classe, etc...).
On a des statistiques sur l'utilisation du formulaire qui pose la question "quel est votre éditeur préféré ?" :
=> emacs
=> vi
=> notepad
Je vais répondre emacs car çà me flatte. Je me donne l'illusion d'appartenir à cette communauté de hackers qui connait par coeur les subtilités d'emacs et ponde quelques lignes de lisp chaque fois qu'il leur manque une fonctionnalité pour améliorer leur productivité dans le développement. Alors que j'ai lancé deux fois emacs et que je ne suis pas arrivé à quitter proprement (Trop puissant emacs !).
Bref, finalement c'est un sondage assez révélateur...
> je suis stupefait par la position de Debian et la position de certains outils difficiles a utiliser.
Je vais me faire allumer mais je reconnais que les utilisateurs de debian (certains ! la distribution est plus que respectable ) me casse les c....
Arrêtons ici ce qui ressemble à un troll. Je vais donner un exemple qui m'a particuliairement gonflé.
J'arrive dans une boîte qui fesait aussi du web. Faut installer un nouveau serveur web sous Linux. J'étais le seul avec de bonne compétences Linux/Unix et qui avait un peu de temps.
Je proprose un RH 6.2 (j'ai un faible pour RH ...), comme tout le mode est d'accord, c'est parti pour une RH. Comme il y avais déjà des slack, des mdk, et une debian on décide de se fixer sur RH pour les nouvelles bécanes (çà pouvait être mdk, debian, etc... Mais c'est tombé sur moi de prendre la décision...) pour avoir moins de problèmes de maintenance.
J'étais principalement développeur. Un nouvel admin arrive. Objectif, installer un serveur pour faire un Intranet.
1- Il me chie une pendule car ma bécane à named, squid, sendmail, samba, telnet et que tout çà n'est pas très "secure". Ma bécane n'est pas accessible depuis l'Internet et on est une petite boite. Je lui dit que ma bécane est parfaitement maintenue et que s'il y a des trous de sécurité, ils sont volontaires et que je ne suis pas paranoïaque. Par exemple, le mot de passe root est connu de tout le monde qui est sur le réseau local et que ce mot de passe est "root" et que le telnet de root est autorisé. Trou de sécurité ENORME, mais volontaire. Je lui lance un défit. Sans utiliser telnet avec le compte root, je lui demande de cracker ma bécane à distance. => c'est rien passé... Ma bécane était la seule pour faire les développement Linux. Les autres postes étant sous windows. Les autres pour développer passait par samba et parfois utilisaient un telnet. Je lui dis que c'est pas l'idéal (une bécane personnelle pour faire du développement à plusieurs avec seulement 128 Mo !) et qu'il pourrait faire en sorte que tout soit fait sur le serveur Intranet en utilisant ssh au lieu de telnet.
2- j'apprends que pour l'intranet (qui n'est pas accessible depuis l'Internet) le nouvelle admin installe une debian car plus "secure". çà c'est du debian touch.
3- hors de question de faire de cette machine une bécane de développement. Raison : C'est un serveur et pas une bécane de développement. C'est tout.
4- celui qui devais développer l'intranet le fait sur ma bécane car il y a pas samba, telnet (ou ssh) sur le serveur intranet (pas assez "secure") et pas plus de serveur X11.
> un copain se disait Fan de Linux, ... il avait Windows XP.
Cf les stats linuxfr.
Les linusiens intégristes sont souvent uniquement des frimeurs.
Ils aiment se la péter. Montrer qu'ils sont pointu en sécurité noyau par exemple, cf la news en première page d'un exploit "pot de miel sous openBSD" qui ne concerne pratiquement personne.
PS : il est claire qu'il y a de très bon utilisateurs de debian et je regrette pour eux que certains leur donne une mauvaise image.
Petite précision. A chaque nouvelle connection, le serveur génère un nouveau code.
Le système n'est pas parfait mais il permet de complique la vie des crackers et sourtout le cracker aura du mal a "remonter" au mot de passe tapé (surtout pour ceux qui utilise le même mot de passe partout).
> C'est quoi le système de PHPLib pour les mots de passe ?
Selon mes souvenir :
1 - le serveur à les mots de passe stockés en crypté (md5 je crois).
2 - le serveur fixe un identifiant (un numéros de session).
3 - il crée un code aléatoire et l'envoi au client avec l'identifiant.
4 - le client (avec du javascript) crypte le mot de passe tapé comme le fait le serveur avant de stocker les mots de passes. Puis le client créé un code basé sur le mot de passe, qu'il vient de crypter, et sur le code que lui a envoyé le serveur.
5 - le client retourne le user, le code nouvellement calculé et son identifiant.
6 - le serveur, en se basant sur l'identifiant, récupère le code qu'il a envoyé au client.
7 - le serveur récupère le vrai mot de passe (crypté md5) et fait le meme "calcul" que le client (mais avec le vrai mot de passe).
8 - le serveur compare son calcul avec celui du client. Si çà correspond, le "gus" est authentifié.
[^] # Re: Versionnement + question aux admins
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à -2.
Merci.
[^] # Re: Versionnement + question aux admins
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 3.
> on peu laisser des traces détaillées de l'histoire de chaque fichier :
çà reste valable :
$ svn log subversion.spec-mat.patch
------------------------------------------------------------------------
rev 46: f.matias | 2002-07-23 02:28:34 -0400 (mar, 23 jui 2002) | 1 line
Revert de subversion.spec subversion.spec-mat.patch.
------------------------------------------------------------------------
rev 31: anonymous | 2002-07-17 02:27:36 -0400 (mer, 17 jui 2002) | 1 line
Petit adaptation de packages/rpm/subversion.spec-mat.patch pour suivre les modifs de subversion.spec.
------------------------------------------------------------------------
rev 25: anonymous | 2002-07-16 19:34:52 -0400 (mar, 16 jui 2002) | 1 line
Tous ce qui est spécifique à matias contient "-mat".
------------------------------------------------------------------------
rev 24: anonymous | 2002-07-16 19:14:53 -0400 (mar, 16 jui 2002) | 1 line
Mise à jour des patchs pour construire les packages rpm.
- - - - - - - - - - - - - - - - -
Sinon, si tu tients à travailler à l'ancienne, une ne fait des modifications de l'aborescence qu'un fichier à la fois :
$ svn commit -m "Ajout blague du jour" README
Version 10 commited
$ svn commit -m "Ajout blague du jour" cmdline.c
Version 11 commited
$ svn commit -m "Ajout blague du jour" cmdline.h
Version 12 commited
Perso, je trouve çà ridicule.
[^] # Re: Versionnement + question aux admins
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à -2.
voir la FAQ .
[^] # Re: Doc en francais et HTML
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 3.
Voici la même version en un "big-fichier" :
http://feliciano.matias.free.fr/svn/svn-handbook-french.html(...)
[^] # Re: Subversion est prêt pour le Desktop ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 2.
http://svn.collab.net/repos/svn/trunk/tools/cvs2svn/(...)
[^] # Re: Subversion est prêt pour le Desktop ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 6.
Le problème, c'est libapr qui est une couche qui facilite la portabilité. Subversion tourne sur Unix Mac OS X , Windowns, etc... Et çà en version Alpha. Leur choix d'utiliser libapr est bon.
Le problème est que libapr est livré avec Apache 2.0 et n'est pas encore totalement séparé d'apache : C'est en cours.
Je me suis fait des packages rpm d'apache-2.0 qui s'épare libapr d'apache. Sur une becane qui doit rester en Apache 1.3 j'ai :
apache-1.3.22-2
httpd-libapr-utils-0.2002.06.25-1
httpd-libapr-0.2002.06.25-1
subversion-0.13.2-2639
=> Donc du peut utiliser Subversion sans Apache 2.0.
sur un autre becane, utilisée pour compilier subversion :
httpd-2.0.40-1
httpd-devel-2.0.40-1
httpd-libapr-0.2002.06.25-1
httpd-libapr-devel-0.2002.06.25-1
httpd-libapr-utils-0.2002.06.25-1
httpd-libapr-utils-devel-0.2002.06.25-1
subversion-devel-0.13.2-2639
subversion-0.13.2-2639
subversion-server-0.13.2-2639
Ici, pour avoir Subversion-server il me faut apache.
[^] # Re: Et cela vaut quoi ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 4.
Donc tu as les facilités d'apache pour tout le dépôt.
Après pour un réglage plus fin, il y a les accroches :
http://feliciano.matias.free.fr/svn/Accroches-d-un-d%E9p%F4t.html(...)
[^] # Re: Et cela vaut quoi ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 10.
Pour de la production, ce n'est pas près car trop récent (Alpha).
La production c'est V1.0 + 3 à 6 mois.
[^] # Re: Et cela vaut quoi ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 10.
voir ici : http://feliciano.matias.free.fr/svn/SVN-pour-les-utilisateurs-de-CV(...)
> Il compte rendre cela "stable" quand ?
Ben à partir de maintenant puisqu'il sont en alpha sans ajout de fonctionnalité (tient, t'as déjà la stabilité pour les fonctionnalité!).
La version beta est prévue courant Septembre.
[^] # Re: Subversion est prêt pour le Desktop ?
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 10.
Actuellement c'est un peut lourd d'installer apache-2.0, neon, db4 pour avoir subversion.
Mais comme les futurs (très proches) distribes auront apache-2.0 en standard, çà va s'arranger.
[^] # Re: 9.0 ?
Posté par matiasf . En réponse à la dépêche Mandrake 9.0 beta1. Évalué à -1.
[^] # Re: Atonique
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 10.
C'est en passant pour un con qu'on progresse.
[^] # Re: hép, modéros !
Posté par matiasf . En réponse à la dépêche Subversion rentre en phase alpha.. Évalué à 4.
Pour "les developpeurs utilise" et "atonique", c'est moi!
[^] # Re: gcc 3.1.1 ?!?
Posté par matiasf . En réponse à la dépêche Mandrake 9.0 beta1. Évalué à -4.
Le problème est que Mandrake a toujours été en avance sur RedHat côté desktop. RedHat fait un peut le forcing pour leur prochaine distribe côté desktop. Mandrake se retrouve comme un con en train de proposer la même chose de RedHat. Alors pour "signer" leur différence il font ... ce qu'il peuvent.
[^] # Re: 9.0 ?
Posté par matiasf . En réponse à la dépêche Mandrake 9.0 beta1. Évalué à 0.
Question suivante.
Je parlais pas d'un manque de version majeur et expliquait pourquoi il fallait plus de version majeur mais l'inverse. J'ai indiqué que la fréquence est élevée sans réelle justification.
Quand faire une changement majeur?
Pour moi c'est une décision du distributeur et pas une soit disant incompatibilité de librairie.
Sortir rarement des versions majeur d'impose de faire attention aux compatibilité. Si le distributeur ne veut pas se faire chier, il sort une version majeur à chaque fois.
Alors, cette situation te plait peut-être, tu trouves que le 8.0 y fait jolie chez toi mais en entreprise tout ces versions incompatibles en 2/3 ans, c'est naze. D'avoir une Mandrake 7.0 d'il y a deux ans (ou moins) incompatible avec une proche Mandrake 8.0 (Comme c'était le cas avec 6.0 et 7.0). C'est naze, naze, naze.
Et maintenant tu ne peut pas reprochez les incompatibilités que fait parfois Microsoft ! Linux est bien plus fort !
[^] # Re: 9.0 ?
Posté par matiasf . En réponse à la dépêche Mandrake 9.0 beta1. Évalué à -1.
Quand il y a de vraies et justifiées incompatibilités et ce n'est pas limité à une incompatibilité binaire...
Mais, pour moi, c'est pour signifier que la version N.x peut faire tourner les programmes de la version N-1.x et non les programmes N-2.x qui ne sont plus supportés. Une versoin major pour une distribe doit arriver tout les 2 à 3 ans. Mais tous les distributeurs sortent une version majeur tout les 12 à 18 mois. La fréquence est trop élevée. çà signifi qu'un programme de 2/3 ans n'est plus supporté !
> Uniquement un changement majeur de version du noyeau ?
Non. Et un changement de noyau ne justifie pas un changement majeur ! Passer d'un noyau 2.2 à 2.4 n'a pas d'impact important sur un utilisateur. Perso, j'ai pas remarqué grand chose... (y en a qui vont péter un plomb... en disant patati système de fichier journalisé ... patata un autre truc...) La méthode de configuration du noyau n'a pas changé depuis Linux 2.0 (arrivée des modules)... Enfin, l'arrivé futur de Linux 2.6 ne justifi pas de version majeur. Il y a alsa mais alsa a un module qui offre une excellente comptabilité avec oss. De plus, Linus a indiqué son intention de "ressérer" les sorties sortie de Linux.
> Perso j'estime que casser la compatibilité de libs partagées de base mérite une telle montée en version.
Et non.
Linux à tout (ou presque tout, contrairement à windows, pour faire cohabier différentes librairies, voir différents format de binaire , le a.out n'est plus supporté d'accord, mais elf est utilisé depuis linux 1.2).
Sur un serveur RH 7.2 qui utilise de vieux programmes, j'ai glic5 glibc2 et glibc2.2 (glibc2 est la suite de glibc5 !).
J'ai également 2 loader : ld-linux.so.1 et ld-linux.so.2 pour supporter elf V1 et elf V2.
Ceci me permet de faire tourner des binaires développés à l'origine sur une Slack avec noyau 1.2 (autour de 95/96) !
çà montre que les changements de version majeur c'est uniquement des choix de distributeur et non une limitation technique.
Cette petite expérience m'a permis de contrater de RedHat (mais tous les autres sûrement) ne fourni pas le minimum de base pour faire tourner (je dis pas compiler !) des programmes qui n'utilise que la libc et qui ont été développés sous RedHat 5.2 ! J'ai été dans l'obligation de créer des packages sous RH 6.2 (ne se compile pas sous RH 7.2 mais çà ce n'est pas un reproche) de libc5 et ld-linux-1 pour conserver un système "rpm-base".
C'est scandaleux ! car la 5.2 date de 99/98 seulement !
Je n'aime pas Microsoft, mais ils sont bien, bien meilleur avec windows ! On faire facilement tourner des programmes win95 (voir win3.1) sous win2000/XP !
> Et pour une distrib orientée desktop (c'est comme ca que je vois lamandrake, pas de troll please) que changer les API de KDE et gnome (kde 2.2 => 3 et gnome 1.4 => 2) mérite aussi un changement de version.
Bof...
S'il faut changer de version majeur parce que kde 2.2 => 3, gnome 1.4 => 2, gcc 2 => 3, apache 1.3 => 2, etc... çà nous fait 2 à 4 versions majeurs tous les ans ! C'est trop.
Regarde les unix commerciaux qui ne changent pas de version majeur car leur compilateur ou noyau a évolué, car il sont passé de motif 1.2 à motif 2, car, car, car...
Il pense, tient Gnome/KDE devient interessant, on va mettre la version 2/3 dans notre prochaine version majeur et çà roule pour 3/5 ans.
> Je crois que debian a aussi changé récement son numéro principal non ? alors pourquoi met tu debian de coté ?
débian est à 3 en numéro de version et pas 8 ! entre la 2 et la 3 il y a de grosses différences ! Pour passer de 2 à 3 il ont mit près de 5 Ans (un Debian user pour confirmer? Je me rappèle que Debian était à la version 1.3 en 95).
Définitivement, il y a trop de version majeurs de GNU/Linux. C'est peut-être un mal nécessaire pour que la partie desktop se stabilise. gnome 2 (qui sera suivi assez rapidement par 2.2) a déjà une pérénité significative. gnome 3 ne devrait pas arrivé avant un bon bout de temps et sa pérénité sera enfin significative (peut-être 4 à 5 ans). Quand je pense que certains gueules car gnome 2 a été long à sortir, ils n'ont pas fini d'être déçu...
[^] # Re: 9.0 ?
Posté par matiasf . En réponse à la dépêche Mandrake 9.0 beta1. Évalué à -3.
Perso, et c'est valable pour presque toutes les distribes (sauf debian) cette montée de numéro de release est nulle.
[^] # Re: Perl rulz
Posté par matiasf . En réponse à la dépêche un gestionnaire de bureau en Perl !. Évalué à 10.
Perl (comme php, python, etc...) c'est un language et des librairie de base (en générale écrite en C). Si tu prend perl que du ajoute le binding pour gtk, gnome, bonobo, gconf, etc...
ben du fini avec 3 % de perl et 97 % de C. Dans ce cas, on ne peut pas dire que perlbox soit principalement écrit en Perl !
[^] # Re: Ces sondages ne veulent rien dire !
Posté par matiasf . En réponse à la dépêche Sondage 2002 des lecteurs de Linux Journal. Évalué à -1.
Je rappel que j'était principalement développeur.
> Ton collègue a peut-être mal apprécié les moyens.
Non, il est butté. Je comprend que l'on puisse mal apprécier une situation (temporairement). Mais camper sur ses positions uniquement pour des raisons de principes (sécurité, séparation serveur/développement) fini par me soualer. Surtout que c'est toutjour ma bécane de "merde" qui fait le gros du boulot. Que c'est moi qui configure apache/php/postgresql et les backup car cette "pointeure" d'admin debian doit se concentrer sur l'installation d'un outil de statistique d'utilisation de firewall.
> ton problème avec lui est lié au fait qu'il utilise Debian ou tout simplement parce qu'il est comme ça...
oui. evidament.
J'ai rien contre la distribe (que je connais mal d'ailleur). S'il était un bon administrateur même avec sa débian et était à l'écoute des utilisateurs / problèmes. Il y aurait partiquement rien comme problème.
Je parle de cette esprit que l'on retrouve plus souvent dans les administrateurs de debian, qui se prennent pour de grosses élites car il font une fixation sur la sécurité, utilise une Debian et qu'a ce titre ont des tonnes de merde dans les oreilles.
Je rappel le PS que j'ai mis au début du thread.
PS : il est claire qu'il y a de très bon utilisateurs de debian et je regrette pour eux que certains leur donne une mauvaise image.
# Bonne chance ...
Posté par matiasf . En réponse à la dépêche un gestionnaire de bureau en Perl !. Évalué à 10.
Quand je vois le nombre de ligne nécessaire à gnome en C. Même si perl est plus éficace en terme décriture, çà fait encore beaucoup de ligne. Niveau performance et utilisateur mémoire çà va devenir des trucs monstrueux...
[^] # Re: Ces sondages ne veulent rien dire !
Posté par matiasf . En réponse à la dépêche Sondage 2002 des lecteurs de Linux Journal. Évalué à 4.
Pour une machine accessible depuis l'Internet je suis intransigant. Que du ssh (compte root interdit), que des comptes ftp séparé des comptes système et avec chroot, mot de passe "compliqué". etc...
Je parlait d'une bécane sur un réseau local. si quelqu'un du réseau local veut les donnés il peut au pire piquer le disque dure, copier les données chez lui et remettre le disque dure.
> Entre autres faire le moins de choses possibles sous le compte root.
absolument. Quand je donne le compte root, c'est pour que les utilisateurs ne soit pas arrêté dans leur boulot car il ne peuvent pas faire un mkdir ou éditer httpd.conf. Pour contre, s'il font une connerie, je les allume. Dans la très grande majorité des cas, si je suis là, il me demande de faire le boulot (préférant que ce soit moi qui fasse une connerie sous le compte root :o) ).
> Euh... Effectivement, dans l'industrie,
C'est un problème de moyen. Si t'as les moyens, tu le fait. Ma bécane était très chargée et avait un pII 233 et 128 Mo de mémoire et pas question d'acheter un autre PC !
[^] # Re: Ces sondages ne veulent rien dire !
Posté par matiasf . En réponse à la dépêche Sondage 2002 des lecteurs de Linux Journal. Évalué à 4.
C'est les conclusions qui sont (parfois) fausses.
Par exemple.
Ceux qui sont malades ont une espérances de vie plus faible.
Ceux qui sont malades prennent des médicaments.
Donc si on fait un sondage sur l'utilisation des médicaments et l'espérance de vie, on en conclu que la prise de médicament diminue l'espérance de vie.
Le sondage du Linux-Journal est un sondage sur l'utilisation d'un formulaire.
Et on a des statistiques sur l'utilisation du formulaire qui pose la question "quel est votre WM préféré ?" :
=> enlightment (valeur par défaut)
=> fvwm2
"Quel est votre WM préféré ?" n'est pas "Quel WM utilisez-vous actuellement ?".
Je peux utilisé fvwm2 et préférer enlightment (j'ai vu des screenshots top-classe, etc...).
On a des statistiques sur l'utilisation du formulaire qui pose la question "quel est votre éditeur préféré ?" :
=> emacs
=> vi
=> notepad
Je vais répondre emacs car çà me flatte. Je me donne l'illusion d'appartenir à cette communauté de hackers qui connait par coeur les subtilités d'emacs et ponde quelques lignes de lisp chaque fois qu'il leur manque une fonctionnalité pour améliorer leur productivité dans le développement. Alors que j'ai lancé deux fois emacs et que je ne suis pas arrivé à quitter proprement (Trop puissant emacs !).
Bref, finalement c'est un sondage assez révélateur...
[^] # Re: Ces sondages ne veulent rien dire !
Posté par matiasf . En réponse à la dépêche Sondage 2002 des lecteurs de Linux Journal. Évalué à -2.
Je vais me faire allumer mais je reconnais que les utilisateurs de debian (certains ! la distribution est plus que respectable ) me casse les c....
Arrêtons ici ce qui ressemble à un troll. Je vais donner un exemple qui m'a particuliairement gonflé.
J'arrive dans une boîte qui fesait aussi du web. Faut installer un nouveau serveur web sous Linux. J'étais le seul avec de bonne compétences Linux/Unix et qui avait un peu de temps.
Je proprose un RH 6.2 (j'ai un faible pour RH ...), comme tout le mode est d'accord, c'est parti pour une RH. Comme il y avais déjà des slack, des mdk, et une debian on décide de se fixer sur RH pour les nouvelles bécanes (çà pouvait être mdk, debian, etc... Mais c'est tombé sur moi de prendre la décision...) pour avoir moins de problèmes de maintenance.
J'étais principalement développeur. Un nouvel admin arrive. Objectif, installer un serveur pour faire un Intranet.
1- Il me chie une pendule car ma bécane à named, squid, sendmail, samba, telnet et que tout çà n'est pas très "secure". Ma bécane n'est pas accessible depuis l'Internet et on est une petite boite. Je lui dit que ma bécane est parfaitement maintenue et que s'il y a des trous de sécurité, ils sont volontaires et que je ne suis pas paranoïaque. Par exemple, le mot de passe root est connu de tout le monde qui est sur le réseau local et que ce mot de passe est "root" et que le telnet de root est autorisé. Trou de sécurité ENORME, mais volontaire. Je lui lance un défit. Sans utiliser telnet avec le compte root, je lui demande de cracker ma bécane à distance. => c'est rien passé... Ma bécane était la seule pour faire les développement Linux. Les autres postes étant sous windows. Les autres pour développer passait par samba et parfois utilisaient un telnet. Je lui dis que c'est pas l'idéal (une bécane personnelle pour faire du développement à plusieurs avec seulement 128 Mo !) et qu'il pourrait faire en sorte que tout soit fait sur le serveur Intranet en utilisant ssh au lieu de telnet.
2- j'apprends que pour l'intranet (qui n'est pas accessible depuis l'Internet) le nouvelle admin installe une debian car plus "secure". çà c'est du debian touch.
3- hors de question de faire de cette machine une bécane de développement. Raison : C'est un serveur et pas une bécane de développement. C'est tout.
4- celui qui devais développer l'intranet le fait sur ma bécane car il y a pas samba, telnet (ou ssh) sur le serveur intranet (pas assez "secure") et pas plus de serveur X11.
> un copain se disait Fan de Linux, ... il avait Windows XP.
Cf les stats linuxfr.
Les linusiens intégristes sont souvent uniquement des frimeurs.
Ils aiment se la péter. Montrer qu'ils sont pointu en sécurité noyau par exemple, cf la news en première page d'un exploit "pot de miel sous openBSD" qui ne concerne pratiquement personne.
PS : il est claire qu'il y a de très bon utilisateurs de debian et je regrette pour eux que certains leur donne une mauvaise image.
[^] # Re: arf
Posté par matiasf . En réponse à la dépêche compte-rendu d'un pot de miel avec OpenBSD 3.0. Évalué à 10.
Le système n'est pas parfait mais il permet de complique la vie des crackers et sourtout le cracker aura du mal a "remonter" au mot de passe tapé (surtout pour ceux qui utilise le même mot de passe partout).
[^] # Re: arf
Posté par matiasf . En réponse à la dépêche compte-rendu d'un pot de miel avec OpenBSD 3.0. Évalué à 10.
Pas moi.
> C'est quoi le système de PHPLib pour les mots de passe ?
Selon mes souvenir :
1 - le serveur à les mots de passe stockés en crypté (md5 je crois).
2 - le serveur fixe un identifiant (un numéros de session).
3 - il crée un code aléatoire et l'envoi au client avec l'identifiant.
4 - le client (avec du javascript) crypte le mot de passe tapé comme le fait le serveur avant de stocker les mots de passes. Puis le client créé un code basé sur le mot de passe, qu'il vient de crypter, et sur le code que lui a envoyé le serveur.
5 - le client retourne le user, le code nouvellement calculé et son identifiant.
6 - le serveur, en se basant sur l'identifiant, récupère le code qu'il a envoyé au client.
7 - le serveur récupère le vrai mot de passe (crypté md5) et fait le meme "calcul" que le client (mais avec le vrai mot de passe).
8 - le serveur compare son calcul avec celui du client. Si çà correspond, le "gus" est authentifié.