"Alors il vous faut utiliser Debian (dans sa version stable bien sûr)."
Tous les debianistes vous conseillent la version stable... pratiquement aucun ne l'utilise.
Moralité, cette version est mal supportée. Par exemple, lors de la divulgation de la faille du noyau pour laquelle Marcelo n'a pas voulu sortir de version corrigée, toutes les grandes distributions ont sorti une mise-à-jour pratiquement aussitôt, sauf la Debian stable i386 (à moins de lire une mailing liste de développement Debian pour savoir où la trouver).
Avant même de considérer la cohérence entre les divers paquets, le taux de bugs n'est à mon avis pas tellement meilleur que celui d'une Mandrake moyenne, avec des versions assez anciennes des programmes, dont certaines contiennent des bugs rédhibitoires.
Là, on vous dit, "oui, mais vous pouvez mixer avec des paquets des versions unstable ou testing pour les logiciels dont vous voulez une version plus récente".
Si vous pensez prendre tout bêtement les prendre sur le FTP et les installer, c'est raté : l'organisation "intelligente" du site FTP est optimisée pour qu'il soit aussi difficile que possible de s'y repérer à vue. Heureusement, vous avez la chance qu'apt puisse gérer efficacement les sources provenant de différentes versions à votre place... en le configurant longtemps.
Quand vous en êtes à ce stade-là, vous avez enfin la chance de pouvoir lancer apt en lui indiquant que vous voulez prendre le paquet de la version unstable. Là, il vous dit qu'il lui faut certaines bibliothèques plus récentes (il me semble que c'est possible de lui dire de résoudre automatiquement les dépendances sur les versions unstable ou testing, mais j'avais voulu rester prudent). On les ajoute donc, et il vous annonce tout fièrement qu'il peut réaliser l'installation, mais qu'il va supprimer une liste de paquets qui dépendaient des anciennes versions.
Parce que certains paquets ont en effet été créés avec des dépendances strictes, anihilant ainsi tout espoir de mixer entre facilement les différentes versions pour certains logiciels et tout l'intérêt de la puissance d'apt.
Mon avis : ne perdez pas votre temps avec la version stable de Debian si vous voulez faire quelque chose de plus pointu qu'un routeur.
Reste à voir si la version unstable fait l'affaire... Concernant les failles de sécurité, elle semble beaucoup plus réactive. D'un autre côté, les debianistes que je connais utilisent tous la version unstable, mais passent pas mal de temps à la maintenir. Est-ce seulement une question de niveau d'exigence (ce qui ne m'étonnerait pas tellement), ou aussi de nécessité ?
N'oublions pas néanmoins que si l'intérêt technique d'une Debian est loin de ce que prétendent les debianistes, il lui reste au moins un intérêt éthique indiscutable.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
3) Les durées de vie des produits ne changent pas pendant la vie du produit
La durée pendant laquelle le support du produit est assuré est respectée, et peut parfois même être étendue.
Ayons une pensée émue pour la 8.2 qui est sortie à l'époque du support 24 mois et dont le support s'est finalement arrêté 18 mois après sa sortie, ou 12 mois après son remplacement.
À la décharge de Mandrake, la période était difficile et puis ils n'avaient pas réellement pris d'engagement sur la durée de support.
MandrakeSoft will provide 12 months of "desktop" updates for distributions, and 18 months of "base" updates for distributions.
Mandrake Linux 9.2 September 30, 2004 March 30, 2005
À voir les dates, il s'agit donc bien de 6 et 12 mois après le remplacement d'une distribution, ça fait bien court pour celui qui l'achète dans les derniers !
J'aime bien MandrakeSoft, ses distribs et sa politique générale par rapport au logiciel libre, je comprends que vu la conjoncture globale aussi bien que leur situation, il ne peuvent sûrement pas se permettre un support plus long, mais cela ne m'empêche pas de trouver cela bien court...
L'idée serait peut-être de faire un regroupement d'utilisateurs, dans le but de prolonger le support officiel par un support minimum non officiel en se répartissant la création de paquets et en se bornant aux mises-à-jour qui concernent des failles de sécurité.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Cela dit, sur la Mandrake 9.2 (je ne me rappelle plus pour la 9.1), l'install graphique propose une option à cocher pour désactiver l'APIC. Reste juste à savoir que le problème vient de là...
À part ça, pour info, après utilisation d'une carte à base de SiS depuis plusieurs mois (en connaissant le coup de l'APIC), je trouve que ça marche assez bien.
Moins de problèmes de support qu'un chipset nVidia : les gens de chez SiS ont fourni en GPL les drivers de base pour le contrôleur disque et le contrôleur réseau intégré, qui sont maintenant intégrés au noyau standard; l'effort est peut-être moindre que celui de nVidia, mais au moins va-t-il dans le bon sens.
Moins de risques de bugs qu'avec un chipset VIA (au boulot, on a des machines avec des chipset VIA de deux séries différentes qui ont des problèmes bizarres, sous Windows ou sous Linux...).
Par contre, l'USB qui est sensé être 2.0 sur le SiS 746 n'est reconnu que comme du 1.1.
Enfin pour le prix de ma carte, je ne me plains pas...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
L'APIC, ça n'a rien à voir avec l'ACPI (même si c'en est un anagramme), c'est la gestion des interruptions avancée, qui permet d'avoir des numéros d'interruptions au dessus de 15 et gère des trucs pour le SMP.
mais dans le cas courant, ce n'est pas indispensable et dans le cas des chipsets SiS, ce n'est pas (encore ?) supporté.
Cela dit, l'idéal c'est de désactiver l'APIC au niveau du BIOS, mais toutes les cartes mères ne le permettent pas (j'avais vérifié avant pour la mienne...).
J'ai essayé une fois en le laissant sur le BIOS et en passant le paramètre noapic, ce qui avait l'air de fonctionner, mais je n'ai rien de vital non plus qui prenne les interruptions au dessus de 18 sur ma machine. C'est-à-dire qu'en ne faisant ni l'un ni l'autre, seul le port série semble poser problème...
Tiens-nous au courant.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
le noyau de la MDK depuis la version 9.0 bloque avec le disque dur,
C'est-à-dire ?
impossible d'aller plus loin et ce sur les cartes mères équipées d'un chip sis 735 (mon ancienne carte) et sis 748.
J'ai fait tourner sans problème une 9.0 avec noyau mis à jour, une 9.1 et une 9.2 avec une carte mère à base de SiS 746.
Par contre, en désactivant le support de l'ACPI dans les paramètres de démarrage du noyau (acpi=off), mais surtout l'APIC au niveau du BIOS. Cela dit, j'ai essayé une fois en le désactivant au niveau des paramètres du noyau (noapic) et ça avait l'air de marcher aussi.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
L'équivalent de la solution proposée :
cd ton_répertoire
\ls -A | perl -e '$n = 0; while (<>) { chomp; rename $_, ++$n.".jpg"; }'
Sans renommer les fichiers commençant par un point ni les répertoires, et en conservant les suffixes pour les fichiers qui en ont :
cd ton_répertoire
perl -e '$n = 0; while (<*>) { -f $_ and rename $_, ++$n.(/^.*(\.[^.]{1,4})$/ ? $1 : ".jpg"); }'
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
À noter toute l'importance des termes dans la question.
Par exemple, le Monde Diplomatique est une source d'informations mais pas d'actualités (c'est un mensuel), tandis que le jounal de TF1 est une source d'actualités... mais pas d'informations.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Eh oui, pour arriver à voir au delà de la Pensée Unique malgré la soupe des journaux télévisés et l'épais brouillard de désinformation produit par le gouvernement (à commencer par la redéfinition de mots "négociations" ou "modernisation"), je me suis mis à lire le Canard régulièrement.
En plus, ce doit être l'un des derniers journaux indépendant des grands groupes...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
À partir du moment où on est en concurrence avec des gens qui travaillent pour un bol de riz, sans protection sociale, on finira tous logiquement par travailler pour un bol de riz ou par être au chômage.
Seuls espoirs de sortie :
- la suppression du libre-échange (donc la sortie de l'OMC) ou
- un syndicalisme mondial fort face au marché mondial (mal parti).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Bon, les objectifs de base de l'OMC, c'est le libre échange et la disparition des barrières douanières et des subventions, notamment agricoles.
Passons sur les mesures plus polémiques et réfléchissons juste à l'effet de ses principes de base.
Supposons que tu possèdes une plantation dans un pays en voie de développement. Tu peux soit cultiver des "produits exotiques" pour les occidentaux (les trucs qui ne poussent pas sous nos latitudes), soit faire des cultures vivrières pour tes compatriotes qui crèvent de faim et qui n'ont pas un rond, et sans incitation ni soutien de l'état puisque celui-ci n'a pas le droit d'intervenir.
Qu'est-ce que tu fais ?
Cela dit, tout le monde ne trouve pas forcément ça "mal" : les gens de l'OMC et ceux qui veulent l'imposer sont justement ceux qui trouvent ça "bien"...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
le message commence donc à passer auprès de ceux qui nous dirigent (NdM : et qu'on a élus).
Quelqu'un sait-il si le sénateur Trégouët est de la majorité ou de l'opposition ?
Parce que s'il n'est pas de la majorité, autant dire que son opinion, aussi valable soit-elle, n'aura que très peu de poids...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Et pourquoi continuer de fabriquer des claviers avec les touches en quinconce, alors que cette aberration ergonomique n'avait comme justification que le passage des pattes métalliques horizontales sur lesquelles étaient fixées les touches, sur les vieilles machines à écrire mécaniques ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ils utilisent des ordinateurs d'avant-guerre (entre 32 à 98 Mo de RAM, Celeron 450Mhz ou K6 de même fréquence) avec Windows98 et 2000.
J'ai a mon boulot comme chez moi des bécanes pas plus puissantes, voire moins (P2 350 MHz et Celeron 300A), mais avec carrément plus de mémoire et la majorité des applications courantes (de xterm jusqu'à Mozilla et OpenOffice, moins Galeon, qui a un temps de réaction trop important) sont tout-à-fait utilisables.
128 Mo doivent suffire pour utiliser dans de bonnes conditions une grosse appli (Mozilla, OpenOffice, par exemple), mais pour en utiliser plusieurs en même temps, mieux vaut viser 256 Mo...
Je n'irais pas charger inutilement des machines comme ça avec Windows 2000, KDE ou Gnome, là où Windows 98 (ou NT 4 pour un peu de sécurité), IceWM ou fvwm (mieux à condition de configurer longtemps) rendent un service suffisant en laissant beaucoup plus de ressources aux applications.
Ils vont peut-être acheter un peu de RAM (arrgg j'ai essayé d'installer une barrette de 128Mo de RAM en 133 , mais elle ne fonctionnait pas)
Les barrettes mémoire sans marque actuelles sont souvent bien pourries et réussissent même à ne pas fonctionner sur des machines récentes prévues pour leur type (il y a par exemple des barrettes qui ne marchent que sur des chipset Via et pas des chipsets Intel)...
Cela dit, je suis arrivé à trouver des 256 Mo PC133 fonctionnant sur les machines en question et d'autres de la même époque, mais avec difficulté et au compte goutte.
Ça doit être beaucoup plus facile en demandant spécifiquement des barrettes PC100, puisque si elles ne marchent pas sur les machines de l'époque, on ne voit pas bien sur quoi elles pourraient marcher...
Sinon, il faut faire attention au nombre de composants (la capacité des composants supportés par les machines de l'époque étant moindre que pour les machines récentes), c'est-à-dire 8 pour une 128 Mo et 16 pour une 256 Mo. Et encore, à moins de prendre de la mémoire de marque, tu risques de tomber plus souvent sur des barrettes avec des composants plus gros montés en parallèle (ça permet de recycler les rebuts : on les mets par deux en espérant que pour chaque adresse, il y en aura bien un des deux qui va marcher et on vend comme ça de la mémoire qui aurait dû aller à la poubelle)...
Pas dit non plus que certaines barettes avec des composants de la bonne taille ne posent pas de problèmes à cause de leur partie "contrôleur".
Autant dire que de la PC100, tu mettras un peu de temps à la trouver, mais de la PC133, tu mettras bien autant de temps à en trouver avec le bon nombre de composants, et en plus tu devras en passer beaucoup plus à les tester et à retourner les échanger (expérience vécue), à moins de prendre des barrettes de marques garanties compatibles avec toutes les machines (il y en a, c'est dur à trouver aussi, et c'est plus cher).
La vérification des barrettes mémoires sans marque avec un bon logiciel de test, comme memtest86, n'est pas forcément superflue...
(oui, nous avons des données sensibles)
Surtout que les ONG font partie des cibles privilégiées des services d'espionnage...
Voila, s'ils arrivent à installer et faire fonctionner GPG, ce sera positif... et ils 'attaqueront alors probablement à d'autre applications (Outlook, Word, etc)
Je me demande si ce n'est pas plus coûteux en temps d'informaticien (qu'ils n'ont pas vraiment d'après ce que tu dis) de faire une transition progressive.
Pourquoi ne pas leur faire essayer Linux avec IceWM, Mozilla pour le mail et le web et OpenOfice (plus, éventuellement, un gestionnaire de fichier léger comme ROX-Filer), voir ce qu'ils en pensent (et, si besoin, ajuster en fonction) ?
Sans augmenter la mémoire, peut-être vaut-il mieux Galeon que Mozilla, Galeon étant moins gourmand en mémoire.
Note : ça nécessiterait de la configuration "à la main" (notamment pour les menus et icônes d'IceWM et les associations de fichiers de ROX-Filer), mais après tout, il suffirait de la faire une fois et de recopier ensuite.
Note 2 : la version d'IceWM de la Debian Woody semble boguée au niveau du placement des fenêtres (ou alors c'est mon thème fait main qui l'induit en erreur, mais ça ne le fait pas avec les autres versions que j'ai utilisées).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ce que SCO dit, c'est que du code lui appartenant a atteri dans Suse et Redhat sans son autorisation
Bon eh bien, puisque de toute façon les sources des noyaux Suse et Redhat sont publics, qu'attendent-ils pour nous montrer quel est le code qui leur appartient ?
Allez, faut pas être timides !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Sérif, il y a des petites barres aux extrémités des lettres. Exemples : les polices times et courier . Sans sérif, il n'y en a pas. Exemple : helvetica.
Chasse fixe, c'est que chaque caractère prend la même largeur (éventuellement avec du blanc sur les côtés), aussi bien le i que le W. C'est le cas de la police courier et pas celui des polices times et helvetica.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Il faut interdire totalement la copie des logiciels propriétaires.
Y compris par les éditeurs eux-mêmes.
Comme ça, en ne diffusant plus leurs logiciels, ils ne courront plus aucun risque de piratage. Et puis le contrôle sera bien plus facile à assurer par les pouvoirs publics que si on autorise la diffusion en masse de copies soi-disant légales.
De même pour l'industrie du disque, il faut leur interdire aussi la diffusion sous forme de support numérique ou pas (risque de copie) et encore plus la diffusion radio ou télé (carrément une incitation à la copie).
Ainsi, nous pourrons enfin vivre tous heureux dans le meilleur des mondes, sans la moindre copie illégale...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je sais bien, mais en pratique faire des dtors qui ne sont pas appelés de manière deterministe n'est pas toujours simple.
Pas forcément, en effet.
La question est déjà de savoir, dans le cas où un objet A dépend d'un objet B, si le GC assure bien que A soit détruit avant B, sinon l'ajout de destructeurs au langage ne marchera pas fort...
File.open("foobar.txt") { |filehandle|
...
}
C'est un cas plus simple que celui auquel je pensais. Je précise ma pensée avec un exemple plus pratique (que je vais tenter de faire ressembler à du Ruby, bien que je n'aie plus trop ça en tête) :
# Le constructeur me charge le fichier alias en mémoire,
alias = AliasFile.new("/etc/aliases")
# je travaille dessus en mémoire...
alias.add("visiteurs", "toto")
alias.add("employes", "toto")
...
# et après, je m'attends à ce qu'un destructeur se charge d'enregistrer les modifications tout seul à la fin.
Bon, il y a peut-être une façon de faire plus Ruby qui ne nécessite pas de destructeur (définir une fonction équivalente à File.open sur ma classe ? enfin utiliser une fonction de ce genre avec une closure n'est pas tellement moins contraignant qu'un appel explicite à une méthode finalize...), mais ça, c'est ma façon de concevoir le truc. Et, pour reprendre les expressions de Matz dans son interview, s'il faut que je contourne ma façon de penser objet habituelle, c'est un stress et ça m'empêche d'"enjoy programming" avec Ruby, donc ça me donne plutôt envie de regarder un peu Python...
Cela dit, c'est plutôt par hobby que j'essaie de me trouver un langage sympa.
Pour mon boulot (sysadmin), je m'en tiens au choix de raison, Perl :
- plus répandu;
- pratiquement la garantie de trouver tous les modules dont je pourrais avoir besoin pour mon boulot;
- peut remplacer un script shell en un peu plus lourd, du sed et de l'awk en à peine plus lourd, mais avec la puissance d'un langage de programmation "sous le pied";
- supporte les destructeurs ;-) (enfin il faudra voir ce que ça donne avec la version 6, qui devrait utiliser un GC...).
Au chapitre des inconvénients, il y a la syntaxe "top space" et la POO lourdingue, mais bon, j'ai déjà fait l'effort de m'y habituer...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).
Ce n'est pas complètement lié à la présence ou non de destructeurs, même si certains modèles de gestion mémoire se prêtent mieux au support des destructeurs qu'un garbage collector.
Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même. C'est même plus intéressant lorsqu'on a pas systématiquement à la provoquer explicitement, parce que si on en est là, il suffit juste d'appeler une méthode "finallize" avant l'appel à la désallocation, voire essayer de mettre la désallocation à la fin de cette méthode.
L'utilité des destructeurs, par exemple, c'est que si on définit une classe pour par exemple manipuler en mémoire un fichier d'état ou de préférences (c'est tout ce qui me vient comme exemple assez général tout-de-suite), le constructeur le charge, on le manipule avec les méthodes qu'on a définies, et le destructeur se charge de l'enregistrer quand on a fini.
En C++, quand on défini un objet directement (sans pointeur), il est détruit à la sortie du scope courant. Sinon, il est vrai, si on a géré l'allocation avec new, il faut gérer soi-même la destruction avec delete, mais c'est inhérent à la gestion mémoire du C++, pas au support des destructeurs.
Perl (mais il question que ça change pour la version 6) et Python, procèdent par comptage de références, c'est-à-dire que lorsqu'un objet n'est plus référencé, il est détruit. Le défaut est que ça alourdit les objets et que ça ne marche pas trop (c'est-à-dire pas du tout en l'absence de mécanisme supplémentaire) en cas de références cycliques, mais dans le cas général, ça garantit l'appel optimal des destructeurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
C'est-à-dire habituellement à la fin du programme, ou tout du moins assez rarement si le programme tourne assez longtemps... Eh oui, les GC ont des avantages, mais là on touche à leur principal inconvénient. Non pas que je n'aie pas confiance sur le fait qu'ils se lancent avant que la consommation mémoire devienne génante, mais pour l'appel des destructeurs, ce n'est pas génial... C'est d'ailleurs il me semble la raison qu'invoque Matz pour ne pas en avoir implémenté.
une méthode peut être appelé (pour fermer des sockets, des fichiers, ce genre de trucs) ceci grace à define_finalizer().
Je connais. C'est peut-être plus approprié pour certains cas particuliers, mais dans le cas général, ça ne vaut pas un vrai destructeur défini au niveau de la classe.
J'avais pensé à étendre la classe de base appropriée (pour ceux qui ne connaissent pas, Ruby permet d'étendre des classes de manière très souple, en dehors de leur module) pour que son contructeur fasse automatiquement un appel à cette fonction si l'on a défini une méthode finalize au niveau de la classe, mais define_finalizer m'a causé quelques soucis et comme je n'avais pas vraiment l'utilité de Ruby...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Pour avoir essayé Ruby, j'ai été impressionné par la propreté de son modèle objet et les concepts avancés et par ailleurs bien pratiques intégrés au langage.
Cela dit, j'ai deux reproches à lui faire :
- Il n'y pas de destructeurs ! Et un langage objet sans destructeurs, pour moi, c'est un peu comme une voiture sans marche arrière : quelles que soient ses autres qualités, c'est bien génant...
- La forme des structures de contrôle de type while... end est certainement celle qui garantit la vérification la plus difficile qu'on a bien refermé toutes les boucles là où on le pense. Avec Python, qui prend en compte directement l'indentation, c'est clair tout de suite et avec des blocs entre accolades, comme c'est le cas pour Perl ou pour le C et C++, le premier éditeur un peu correct venu mettra en évidence les accolades correspondantes quand on passera dessus, sans même avoir besoin d'un mode spécifique au langage qu'on utilise.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J'ai un serveur NFS avec le dernier noyau pour debian woody, qui est un 2.4.18, il marche très bien.
J'en ai aussi un autre, avec un noyau 2.4.18 aussi, qui n'a que des clients Linux, par ailleurs en plus grand nombre, et qui marche très bien. Tout est dans l'interaction avec des clients Sun...
Enfin on n'est pas encore retombé au niveau du serveur NFS qui accompagnait le noyau 2.0 : l'utilisation de clients Sun finissait par causer la corruption de fichiers, y compris s'ils n'étaient accédés qu'en lecture !
Cela dit, avec ou sans bug dans le NFS, quand les Sun que j'ai au boulot seront enfin morts de vieillesse (ils prennent leur temps, les charognes), ça me fera des soucis en moins.
J'ai un autre poste qui fonctionne avec un 2.4.19 sans aucun problème avec ext3 (ce bug, reproductible facilement ?)
Je ne sais pas. En fait, au moment où je m'apprêtais à installer le 2.4.20 sur les serveurs, est sortie la news concernant le bug de ext3fs introduit dans cette version. Un des commentaires faisait référence à un autre bug répertorié pour le 2.4.19 et pas corrigé avant la sortie du 2.4.20.
Je ne connais pas trop les détails, je me suis juste dit qu'il serait peut-être aussi prudent d'attendre le 2.4.21 avant de voir à changer mon 2.4.18...
Cela dit, pour ce qui est d'arriver à prendre en défaut la journalisation avec le 2.4.19, je ne sais pas si ça a un lien avec le bug sus-cité, mais il suffit de lâcher des étudiants sur les machines (j'ai des postes clients en 2.4.19) et il finissent par arriver à péter complètement un système de fichiers...
Le "stress", et donc le risque, est moins important pour le serveur, mais les données sont plus critiques aussi, donc dans le doute, ça n'encourage pas à changer de noyau.
Ceci étant précisé, il ne me semble pas que ce Marcello puisse être jugé responsable des bugs.
Non bien sûr, mais c'est peut-être bien grâce à Alan Cox s'il passait moins de bugs critiques avant...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Mais bon, depuis qu'il s'occupe des 2.4.x, y'a pas à dire, c'est du travail de qualité !
Et tu les utilises en production, les noyaux de Marcello ?
En tout cas, sûrement pas pour un serveur NFS en environnement hétérogène...
Depuis le 2.2.0 (et en passant par maintes versions du 2.2, le 2.4.3 et le 2.4.8), j'ai un serveur NFS sous Linux qui sert des clients Linux, mais aussi quelques Sun et cela s'est avéré parfaitement stable... jusqu'aux versions de Marcello.
Avec le 2.4.18, les Suns arrivent à générer sur le serveur des erreurs bloquant l'accès par NFS aux fichiers les plus utilisés jusqu'au reboot (ça génère des messages du style : "kernel: nfsd Security: etc/cshrc bad export."), même en limitant le serveur au mode NFS v2, considéré comme stable depuis bien longtemps.
J'ai renoncé à essayer le 2.4.19, qui introduit un bug important dans l'ext3fs, et le 2.4.20, qui, non content de ne pas le corriger, en ajoute un autre. Il est vrai que l'ext3 est considéré comme expérimental, mais c'est une question de choix : soit décide de considérer comme stable une fonctionnalité cruciale qui fonctionne parfaitement en production depuis plusieurs versions, ou tout du moins d'essayer d'assurer au mieux le maintien de sa stabilité non officielle, soit on décide de changer massivement le support de l'IDE dans une sous-version avancée d'une version stable du noyau...
Si comme il le semble, Marcello ne décale pas le numéro de la future 2.4.21 pour intercaler une version du 2.4.20 patchée contre la faille de sécuritée actuelle, ça s'inscrit parfaitement dans la même logique.
Je ne dis pas que Marcello soit mauvais. Certainement peu de personnes au monde seraient capables de faire son boulot (et je suis loin d'en faire partie).
Je ne dis pas non plus que je ne suis pas satisfait de son travail : après tout, pour ce qu'il me coûte, je n'ai pas de raison de lui en vouloir, même s'il ne me convient pas. Qui plus est, il me convient tout-à-fait pour ma machine perso.
Je ne dis même pas que Marcello n'est pas à la hauteur d'Alan Cox.
Je dis juste que son sens des priorités fait que Linux, sous la forme de son noyau officiel, n'est plus un système de production mais est redevenu un système de hobby. Et qu'il faut maintenant compter sur les distributions pour founir des noyaux de qualité production, alors que jusque là on craignait plutôt que les nombreux patches plus ou moins gadget qu'elles ajoutaient au noyau ne mettent en péril sa stabilité.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Debian's urban legends
Posté par Arthur Accroc . En réponse à la dépêche MandrakeMove finale dispo en téléchargement.... Évalué à 3.
Tous les debianistes vous conseillent la version stable... pratiquement aucun ne l'utilise.
Moralité, cette version est mal supportée. Par exemple, lors de la divulgation de la faille du noyau pour laquelle Marcelo n'a pas voulu sortir de version corrigée, toutes les grandes distributions ont sorti une mise-à-jour pratiquement aussitôt, sauf la Debian stable i386 (à moins de lire une mailing liste de développement Debian pour savoir où la trouver).
Avant même de considérer la cohérence entre les divers paquets, le taux de bugs n'est à mon avis pas tellement meilleur que celui d'une Mandrake moyenne, avec des versions assez anciennes des programmes, dont certaines contiennent des bugs rédhibitoires.
Là, on vous dit, "oui, mais vous pouvez mixer avec des paquets des versions unstable ou testing pour les logiciels dont vous voulez une version plus récente".
Si vous pensez prendre tout bêtement les prendre sur le FTP et les installer, c'est raté : l'organisation "intelligente" du site FTP est optimisée pour qu'il soit aussi difficile que possible de s'y repérer à vue. Heureusement, vous avez la chance qu'apt puisse gérer efficacement les sources provenant de différentes versions à votre place... en le configurant longtemps.
Quand vous en êtes à ce stade-là, vous avez enfin la chance de pouvoir lancer apt en lui indiquant que vous voulez prendre le paquet de la version unstable. Là, il vous dit qu'il lui faut certaines bibliothèques plus récentes (il me semble que c'est possible de lui dire de résoudre automatiquement les dépendances sur les versions unstable ou testing, mais j'avais voulu rester prudent). On les ajoute donc, et il vous annonce tout fièrement qu'il peut réaliser l'installation, mais qu'il va supprimer une liste de paquets qui dépendaient des anciennes versions.
Parce que certains paquets ont en effet été créés avec des dépendances strictes, anihilant ainsi tout espoir de mixer entre facilement les différentes versions pour certains logiciels et tout l'intérêt de la puissance d'apt.
Mon avis : ne perdez pas votre temps avec la version stable de Debian si vous voulez faire quelque chose de plus pointu qu'un routeur.
Reste à voir si la version unstable fait l'affaire... Concernant les failles de sécurité, elle semble beaucoup plus réactive. D'un autre côté, les debianistes que je connais utilisent tous la version unstable, mais passent pas mal de temps à la maintenir. Est-ce seulement une question de niveau d'exigence (ce qui ne m'étonnerait pas tellement), ou aussi de nécessité ?
N'oublions pas néanmoins que si l'intérêt technique d'une Debian est loin de ce que prétendent les debianistes, il lui reste au moins un intérêt éthique indiscutable.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Durée de support
Posté par Arthur Accroc . En réponse à la dépêche "8 Règles d'Or" pour les produits Mandrake Linux. Évalué à 7.
La durée pendant laquelle le support du produit est assuré est respectée, et peut parfois même être étendue.
Ayons une pensée émue pour la 8.2 qui est sortie à l'époque du support 24 mois et dont le support s'est finalement arrêté 18 mois après sa sortie, ou 12 mois après son remplacement.
À la décharge de Mandrake, la période était difficile et puis ils n'avaient pas réellement pris d'engagement sur la durée de support.
MandrakeSoft will provide 12 months of "desktop" updates for distributions, and 18 months of "base" updates for distributions.
Mandrake Linux 9.2 September 30, 2004 March 30, 2005
À voir les dates, il s'agit donc bien de 6 et 12 mois après le remplacement d'une distribution, ça fait bien court pour celui qui l'achète dans les derniers !
J'aime bien MandrakeSoft, ses distribs et sa politique générale par rapport au logiciel libre, je comprends que vu la conjoncture globale aussi bien que leur situation, il ne peuvent sûrement pas se permettre un support plus long, mais cela ne m'empêche pas de trouver cela bien court...
L'idée serait peut-être de faire un regroupement d'utilisateurs, dans le but de prolonger le support officiel par un support minimum non officiel en se répartissant la création de paquets et en se bornant aux mises-à-jour qui concernent des failles de sécurité.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Marche pas avec chipset sis
Posté par Arthur Accroc . En réponse à la dépêche MandrakeMove est disponible. Évalué à 3.
Cela dit, sur la Mandrake 9.2 (je ne me rappelle plus pour la 9.1), l'install graphique propose une option à cocher pour désactiver l'APIC. Reste juste à savoir que le problème vient de là...
À part ça, pour info, après utilisation d'une carte à base de SiS depuis plusieurs mois (en connaissant le coup de l'APIC), je trouve que ça marche assez bien.
Moins de problèmes de support qu'un chipset nVidia : les gens de chez SiS ont fourni en GPL les drivers de base pour le contrôleur disque et le contrôleur réseau intégré, qui sont maintenant intégrés au noyau standard; l'effort est peut-être moindre que celui de nVidia, mais au moins va-t-il dans le bon sens.
Moins de risques de bugs qu'avec un chipset VIA (au boulot, on a des machines avec des chipset VIA de deux séries différentes qui ont des problèmes bizarres, sous Windows ou sous Linux...).
Par contre, l'USB qui est sensé être 2.0 sur le SiS 746 n'est reconnu que comme du 1.1.
Enfin pour le prix de ma carte, je ne me plains pas...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Marche pas avec chipset sis
Posté par Arthur Accroc . En réponse à la dépêche MandrakeMove est disponible. Évalué à 3.
L'APIC, ça n'a rien à voir avec l'ACPI (même si c'en est un anagramme), c'est la gestion des interruptions avancée, qui permet d'avoir des numéros d'interruptions au dessus de 15 et gère des trucs pour le SMP.
mais dans le cas courant, ce n'est pas indispensable et dans le cas des chipsets SiS, ce n'est pas (encore ?) supporté.
Cela dit, l'idéal c'est de désactiver l'APIC au niveau du BIOS, mais toutes les cartes mères ne le permettent pas (j'avais vérifié avant pour la mienne...).
J'ai essayé une fois en le laissant sur le BIOS et en passant le paramètre noapic, ce qui avait l'air de fonctionner, mais je n'ai rien de vital non plus qui prenne les interruptions au dessus de 18 sur ma machine. C'est-à-dire qu'en ne faisant ni l'un ni l'autre, seul le port série semble poser problème...
Tiens-nous au courant.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Marche pas avec chipset sis
Posté par Arthur Accroc . En réponse à la dépêche MandrakeMove est disponible. Évalué à 3.
C'est-à-dire ?
impossible d'aller plus loin et ce sur les cartes mères équipées d'un chip sis 735 (mon ancienne carte) et sis 748.
J'ai fait tourner sans problème une 9.0 avec noyau mis à jour, une 9.1 et une 9.2 avec une carte mère à base de SiS 746.
Par contre, en désactivant le support de l'ACPI dans les paramètres de démarrage du noyau (acpi=off), mais surtout l'APIC au niveau du BIOS. Cela dit, j'ai essayé une fois en le désactivant au niveau des paramètres du noyau (noapic) et ça avait l'air de marcher aussi.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Avec Perl
Posté par Arthur Accroc . En réponse au message [Terminal] Pour renommer des fichiers avec des chiffres. Évalué à 1.
cd ton_répertoire
\ls -A | perl -e '$n = 0; while (<>) { chomp; rename $_, ++$n.".jpg"; }'
Sans renommer les fichiers commençant par un point ni les répertoires, et en conservant les suffixes pour les fichiers qui en ont :
cd ton_répertoire
perl -e '$n = 0; while (<*>) { -f $_ and rename $_, ++$n.(/^.*(\.[^.]{1,4})$/ ? $1 : ".jpg"); }'
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# "actualités"
Posté par Arthur Accroc . En réponse au sondage Ma source principale d'actualités (non liées à l'informatique) est :. Évalué à 3.
Par exemple, le Monde Diplomatique est une source d'informations mais pas d'actualités (c'est un mensuel), tandis que le jounal de TF1 est une source d'actualités... mais pas d'informations.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Re: Ma source principale d'actualités (non liées à l'informatique) est :
Posté par Arthur Accroc . En réponse au sondage Ma source principale d'actualités (non liées à l'informatique) est :. Évalué à 1.
Eh oui, pour arriver à voir au delà de la Pensée Unique malgré la soupe des journaux télévisés et l'épais brouillard de désinformation produit par le gouvernement (à commencer par la redéfinition de mots "négociations" ou "modernisation"), je me suis mis à lire le Canard régulièrement.
En plus, ce doit être l'un des derniers journaux indépendant des grands groupes...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Marché du travail, licenciements abusifs et offshore en informatique
Posté par Arthur Accroc . En réponse à la dépêche Marché du travail, licenciements abusifs et offshore en informatique. Évalué à 4.
À partir du moment où on est en concurrence avec des gens qui travaillent pour un bol de riz, sans protection sociale, on finira tous logiquement par travailler pour un bol de riz ou par être au chômage.
Seuls espoirs de sortie :
- la suppression du libre-échange (donc la sortie de l'OMC) ou
- un syndicalisme mondial fort face au marché mondial (mal parti).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Re: c'est mal l'OMC ?
Posté par Arthur Accroc . En réponse au journal c'est mal l'OMC ?. Évalué à 2.
Passons sur les mesures plus polémiques et réfléchissons juste à l'effet de ses principes de base.
Supposons que tu possèdes une plantation dans un pays en voie de développement. Tu peux soit cultiver des "produits exotiques" pour les occidentaux (les trucs qui ne poussent pas sous nos latitudes), soit faire des cultures vivrières pour tes compatriotes qui crèvent de faim et qui n'ont pas un rond, et sans incitation ni soutien de l'état puisque celui-ci n'a pas le droit d'intervenir.
Qu'est-ce que tu fais ?
Cela dit, tout le monde ne trouve pas forcément ça "mal" : les gens de l'OMC et ceux qui veulent l'imposer sont justement ceux qui trouvent ça "bien"...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Re: @RT Flash parle de Logiciel libre, TCPA, et Palladium
Posté par Arthur Accroc . En réponse à la dépêche @RT Flash parle de Logiciel libre, TCPA, et Palladium. Évalué à 5.
Quelqu'un sait-il si le sénateur Trégouët est de la majorité ou de l'opposition ?
Parce que s'il n'est pas de la majorité, autant dire que son opinion, aussi valable soit-elle, n'aura que très peu de poids...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # oë
Posté par Arthur Accroc . En réponse à la dépêche Pilote de clavier canadien normalisé en beta test. Évalué à 1.
Oui, mais il n'est sûrement pas collé dans ce cas.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Forme du clavier
Posté par Arthur Accroc . En réponse à la dépêche Pilote de clavier canadien normalisé en beta test. Évalué à 2.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Détail...
Posté par Arthur Accroc . En réponse à la dépêche Compte-rendu de la conférence sur la directive sur la brevetabilité du logiciel des 7 et 8 mai 2003 au parlement européen à Bruxelles. Évalué à 1.
Oui, c'est bien, mais il y a quand même une petite limitation : c'est plus ceux-là qui gouvernent...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Mainteneur ?
Posté par Arthur Accroc . En réponse à la dépêche Dernière (longue) ligne droite pour Linux 2.6. Évalué à 4.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Re: De Windows à Linux : Prélude
Posté par Arthur Accroc . En réponse au journal De Windows à Linux : Prélude. Évalué à 2.
J'ai a mon boulot comme chez moi des bécanes pas plus puissantes, voire moins (P2 350 MHz et Celeron 300A), mais avec carrément plus de mémoire et la majorité des applications courantes (de xterm jusqu'à Mozilla et OpenOffice, moins Galeon, qui a un temps de réaction trop important) sont tout-à-fait utilisables.
128 Mo doivent suffire pour utiliser dans de bonnes conditions une grosse appli (Mozilla, OpenOffice, par exemple), mais pour en utiliser plusieurs en même temps, mieux vaut viser 256 Mo...
Je n'irais pas charger inutilement des machines comme ça avec Windows 2000, KDE ou Gnome, là où Windows 98 (ou NT 4 pour un peu de sécurité), IceWM ou fvwm (mieux à condition de configurer longtemps) rendent un service suffisant en laissant beaucoup plus de ressources aux applications.
Ils vont peut-être acheter un peu de RAM (arrgg j'ai essayé d'installer une barrette de 128Mo de RAM en 133 , mais elle ne fonctionnait pas)
Les barrettes mémoire sans marque actuelles sont souvent bien pourries et réussissent même à ne pas fonctionner sur des machines récentes prévues pour leur type (il y a par exemple des barrettes qui ne marchent que sur des chipset Via et pas des chipsets Intel)...
Cela dit, je suis arrivé à trouver des 256 Mo PC133 fonctionnant sur les machines en question et d'autres de la même époque, mais avec difficulté et au compte goutte.
Ça doit être beaucoup plus facile en demandant spécifiquement des barrettes PC100, puisque si elles ne marchent pas sur les machines de l'époque, on ne voit pas bien sur quoi elles pourraient marcher...
Sinon, il faut faire attention au nombre de composants (la capacité des composants supportés par les machines de l'époque étant moindre que pour les machines récentes), c'est-à-dire 8 pour une 128 Mo et 16 pour une 256 Mo. Et encore, à moins de prendre de la mémoire de marque, tu risques de tomber plus souvent sur des barrettes avec des composants plus gros montés en parallèle (ça permet de recycler les rebuts : on les mets par deux en espérant que pour chaque adresse, il y en aura bien un des deux qui va marcher et on vend comme ça de la mémoire qui aurait dû aller à la poubelle)...
Pas dit non plus que certaines barettes avec des composants de la bonne taille ne posent pas de problèmes à cause de leur partie "contrôleur".
Autant dire que de la PC100, tu mettras un peu de temps à la trouver, mais de la PC133, tu mettras bien autant de temps à en trouver avec le bon nombre de composants, et en plus tu devras en passer beaucoup plus à les tester et à retourner les échanger (expérience vécue), à moins de prendre des barrettes de marques garanties compatibles avec toutes les machines (il y en a, c'est dur à trouver aussi, et c'est plus cher).
La vérification des barrettes mémoires sans marque avec un bon logiciel de test, comme memtest86, n'est pas forcément superflue...
(oui, nous avons des données sensibles)
Surtout que les ONG font partie des cibles privilégiées des services d'espionnage...
Voila, s'ils arrivent à installer et faire fonctionner GPG, ce sera positif... et ils 'attaqueront alors probablement à d'autre applications (Outlook, Word, etc)
Je me demande si ce n'est pas plus coûteux en temps d'informaticien (qu'ils n'ont pas vraiment d'après ce que tu dis) de faire une transition progressive.
Pourquoi ne pas leur faire essayer Linux avec IceWM, Mozilla pour le mail et le web et OpenOfice (plus, éventuellement, un gestionnaire de fichier léger comme ROX-Filer), voir ce qu'ils en pensent (et, si besoin, ajuster en fonction) ?
Sans augmenter la mémoire, peut-être vaut-il mieux Galeon que Mozilla, Galeon étant moins gourmand en mémoire.
Note : ça nécessiterait de la configuration "à la main" (notamment pour les menus et icônes d'IceWM et les associations de fichiers de ROX-Filer), mais après tout, il suffirait de la faire une fois et de recopier ensuite.
Note 2 : la version d'IceWM de la Debian Woody semble boguée au niveau du placement des fenêtres (ou alors c'est mon thème fait main qui l'induit en erreur, mais ça ne le fait pas avec les autres versions que j'ai utilisées).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: SCO-Caldera attaque RedHat et SuSe
Posté par Arthur Accroc . En réponse à la dépêche SCO-Caldera attaque RedHat et SuSe. Évalué à 10.
Bon eh bien, puisque de toute façon les sources des noyaux Suse et Redhat sont publics, qu'attendent-ils pour nous montrer quel est le code qui leur appartient ?
Allez, faut pas être timides !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Une interrogation
Posté par Arthur Accroc . En réponse à la dépêche Polices Vera de Bitstream, version 1.10. Évalué à 10.
Sans sérif, il n'y en a pas. Exemple : helvetica.
Chasse fixe, c'est que chaque caractère prend la même largeur (éventuellement avec du blanc sur les côtés), aussi bien le i que le W. C'est le cas de la police courier et pas celui des polices times et helvetica.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Contre la copie illicite, il faut être beaucoup plus radical !
Posté par Arthur Accroc . En réponse à la dépêche Lutter contre la copie informatique favoriserait la croissance. Évalué à 2.
Y compris par les éditeurs eux-mêmes.
Comme ça, en ne diffusant plus leurs logiciels, ils ne courront plus aucun risque de piratage. Et puis le contrôle sera bien plus facile à assurer par les pouvoirs publics que si on autorise la diffusion en masse de copies soi-disant légales.
De même pour l'industrie du disque, il faut leur interdire aussi la diffusion sous forme de support numérique ou pas (risque de copie) et encore plus la diffusion radio ou télé (carrément une incitation à la copie).
Ainsi, nous pourrons enfin vivre tous heureux dans le meilleur des mondes, sans la moindre copie illégale...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Oui, mais...
Posté par Arthur Accroc . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 2.
Pas forcément, en effet.
La question est déjà de savoir, dans le cas où un objet A dépend d'un objet B, si le GC assure bien que A soit détruit avant B, sinon l'ajout de destructeurs au langage ne marchera pas fort...
File.open("foobar.txt") { |filehandle|
...
}
C'est un cas plus simple que celui auquel je pensais. Je précise ma pensée avec un exemple plus pratique (que je vais tenter de faire ressembler à du Ruby, bien que je n'aie plus trop ça en tête) :
# Le constructeur me charge le fichier alias en mémoire,
alias = AliasFile.new("/etc/aliases")
# je travaille dessus en mémoire...
alias.add("visiteurs", "toto")
alias.add("employes", "toto")
...
# et après, je m'attends à ce qu'un destructeur se charge d'enregistrer les modifications tout seul à la fin.
Bon, il y a peut-être une façon de faire plus Ruby qui ne nécessite pas de destructeur (définir une fonction équivalente à File.open sur ma classe ? enfin utiliser une fonction de ce genre avec une closure n'est pas tellement moins contraignant qu'un appel explicite à une méthode finalize...), mais ça, c'est ma façon de concevoir le truc. Et, pour reprendre les expressions de Matz dans son interview, s'il faut que je contourne ma façon de penser objet habituelle, c'est un stress et ça m'empêche d'"enjoy programming" avec Ruby, donc ça me donne plutôt envie de regarder un peu Python...
Cela dit, c'est plutôt par hobby que j'essaie de me trouver un langage sympa.
Pour mon boulot (sysadmin), je m'en tiens au choix de raison, Perl :
- plus répandu;
- pratiquement la garantie de trouver tous les modules dont je pourrais avoir besoin pour mon boulot;
- peut remplacer un script shell en un peu plus lourd, du sed et de l'awk en à peine plus lourd, mais avec la puissance d'un langage de programmation "sous le pied";
- supporte les destructeurs ;-) (enfin il faudra voir ce que ça donne avec la version 6, qui devrait utiliser un GC...).
Au chapitre des inconvénients, il y a la syntaxe "top space" et la POO lourdingue, mais bon, j'ai déjà fait l'effort de m'y habituer...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Oui, mais...
Posté par Arthur Accroc . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 3.
Ce n'est pas complètement lié à la présence ou non de destructeurs, même si certains modèles de gestion mémoire se prêtent mieux au support des destructeurs qu'un garbage collector.
Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même. C'est même plus intéressant lorsqu'on a pas systématiquement à la provoquer explicitement, parce que si on en est là, il suffit juste d'appeler une méthode "finallize" avant l'appel à la désallocation, voire essayer de mettre la désallocation à la fin de cette méthode.
L'utilité des destructeurs, par exemple, c'est que si on définit une classe pour par exemple manipuler en mémoire un fichier d'état ou de préférences (c'est tout ce qui me vient comme exemple assez général tout-de-suite), le constructeur le charge, on le manipule avec les méthodes qu'on a définies, et le destructeur se charge de l'enregistrer quand on a fini.
En C++, quand on défini un objet directement (sans pointeur), il est détruit à la sortie du scope courant. Sinon, il est vrai, si on a géré l'allocation avec new, il faut gérer soi-même la destruction avec delete, mais c'est inhérent à la gestion mémoire du C++, pas au support des destructeurs.
Perl (mais il question que ça change pour la version 6) et Python, procèdent par comptage de références, c'est-à-dire que lorsqu'un objet n'est plus référencé, il est détruit. Le défaut est que ça alourdit les objets et que ça ne marche pas trop (c'est-à-dire pas du tout en l'absence de mécanisme supplémentaire) en cas de références cycliques, mais dans le cas général, ça garantit l'appel optimal des destructeurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Oui, mais...
Posté par Arthur Accroc . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 4.
C'est-à-dire habituellement à la fin du programme, ou tout du moins assez rarement si le programme tourne assez longtemps... Eh oui, les GC ont des avantages, mais là on touche à leur principal inconvénient. Non pas que je n'aie pas confiance sur le fait qu'ils se lancent avant que la consommation mémoire devienne génante, mais pour l'appel des destructeurs, ce n'est pas génial... C'est d'ailleurs il me semble la raison qu'invoque Matz pour ne pas en avoir implémenté.
une méthode peut être appelé (pour fermer des sockets, des fichiers, ce genre de trucs) ceci grace à define_finalizer().
Je connais. C'est peut-être plus approprié pour certains cas particuliers, mais dans le cas général, ça ne vaut pas un vrai destructeur défini au niveau de la classe.
J'avais pensé à étendre la classe de base appropriée (pour ceux qui ne connaissent pas, Ruby permet d'étendre des classes de manière très souple, en dehors de leur module) pour que son contructeur fasse automatiquement un appel à cette fonction si l'on a défini une méthode finalize au niveau de la classe, mais define_finalizer m'a causé quelques soucis et comme je n'avais pas vraiment l'utilité de Ruby...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Oui, mais...
Posté par Arthur Accroc . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 3.
Cela dit, j'ai deux reproches à lui faire :
- Il n'y pas de destructeurs ! Et un langage objet sans destructeurs, pour moi, c'est un peu comme une voiture sans marche arrière : quelles que soient ses autres qualités, c'est bien génant...
- La forme des structures de contrôle de type while... end est certainement celle qui garantit la vérification la plus difficile qu'on a bien refermé toutes les boucles là où on le pense. Avec Python, qui prend en compte directement l'indentation, c'est clair tout de suite et avec des blocs entre accolades, comme c'est le cas pour Perl ou pour le C et C++, le premier éditeur un peu correct venu mettra en évidence les accolades correspondantes quand on passera dessus, sans même avoir besoin d'un mode spécifique au langage qu'on utilise.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # NFS et ext3...
Posté par Arthur Accroc . En réponse à la dépêche Détails sur la sortie du 2.4.21. Évalué à 1.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Qualité des noyau actuels...
Posté par Arthur Accroc . En réponse à la dépêche Détails sur la sortie du 2.4.21. Évalué à 10.
Et tu les utilises en production, les noyaux de Marcello ?
En tout cas, sûrement pas pour un serveur NFS en environnement hétérogène...
Depuis le 2.2.0 (et en passant par maintes versions du 2.2, le 2.4.3 et le 2.4.8), j'ai un serveur NFS sous Linux qui sert des clients Linux, mais aussi quelques Sun et cela s'est avéré parfaitement stable... jusqu'aux versions de Marcello.
Avec le 2.4.18, les Suns arrivent à générer sur le serveur des erreurs bloquant l'accès par NFS aux fichiers les plus utilisés jusqu'au reboot (ça génère des messages du style : "kernel: nfsd Security: etc/cshrc bad export."), même en limitant le serveur au mode NFS v2, considéré comme stable depuis bien longtemps.
J'ai renoncé à essayer le 2.4.19, qui introduit un bug important dans l'ext3fs, et le 2.4.20, qui, non content de ne pas le corriger, en ajoute un autre. Il est vrai que l'ext3 est considéré comme expérimental, mais c'est une question de choix : soit décide de considérer comme stable une fonctionnalité cruciale qui fonctionne parfaitement en production depuis plusieurs versions, ou tout du moins d'essayer d'assurer au mieux le maintien de sa stabilité non officielle, soit on décide de changer massivement le support de l'IDE dans une sous-version avancée d'une version stable du noyau...
Si comme il le semble, Marcello ne décale pas le numéro de la future 2.4.21 pour intercaler une version du 2.4.20 patchée contre la faille de sécuritée actuelle, ça s'inscrit parfaitement dans la même logique.
Je ne dis pas que Marcello soit mauvais. Certainement peu de personnes au monde seraient capables de faire son boulot (et je suis loin d'en faire partie).
Je ne dis pas non plus que je ne suis pas satisfait de son travail : après tout, pour ce qu'il me coûte, je n'ai pas de raison de lui en vouloir, même s'il ne me convient pas. Qui plus est, il me convient tout-à-fait pour ma machine perso.
Je ne dis même pas que Marcello n'est pas à la hauteur d'Alan Cox.
Je dis juste que son sens des priorités fait que Linux, sous la forme de son noyau officiel, n'est plus un système de production mais est redevenu un système de hobby. Et qu'il faut maintenant compter sur les distributions pour founir des noyaux de qualité production, alors que jusque là on craignait plutôt que les nombreux patches plus ou moins gadget qu'elles ajoutaient au noyau ne mettent en péril sa stabilité.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone