totof2000 a écrit 1920 commentaires

Le défaut d'alimentation aurait pu endommager l'electronique interne de l'un des disques … :(

FARPAITMENT !! MACHIN A RAISON !

Je ne dis pas que ça date d'hier, mais de mémoire j'ai vu à l'époque pas mal de messages indiquant que cette option n'était pas prise en compte par systemd.

C'est une des rasons pour lesquelles je déteste systemd, qui ( à une époque au moins), ne permettait pas de paramétrer cette durée (de 3 minutes) pour les processus pour lesquels on sait ne pas devoir attendre aussi longtemps.

µIl me semble que maintenant avec une séquencve de touches il est possible de tuer le processus en question mais je n'en suis pas certain.

La comparaison est foireuse : elle serait valable si stallman avait changé de position sur le libre et la vision de la FSF, ce qu'il n'a jamais fait. Ses positions décriées concernent pour beaucoup des sujets en dehors de la liberté logicielle. Note que je ne le défends pas bec et ongles (je ne suis pas d'accord avec lui, la FSF et GNU sur pas mal de points ), mais je n'aime absolument pas les méthodes employées à son encontre.

Ni à un problème congénital car lorsqu'il était dans le NAS, ce disque était vérifié automatiquement une fois semaine et il n'a jamais montré le moindre problème.

Le contexte d'utilisation a changé, on n'est pas sûr à 100% de la façon dont les contrôleurs gèrent le disque, et le contrôleur du NAS n'a peut-être jamais généré la condition qui cause le blocage. Peut-être que le disque n'est pas mort, mais le firmware a peut-être besoin d'une mise à jour. Si le disque continue à être récalcitrant, c'est peut-être une option à envisager.

je confirme avoir déjà eu des problèmes de ce genre sur un disque mal alimenté. Et de mémoire (donc pas 100% fiable), il me semble avoir déjà du faire des modifs sur des machines avec bios legacy au niveau du contrôleur de disque pour la reconnaissance de disque "récalcitrant".

Après il y a peut-être autre chose (j'ai eu un disque défectueux, à cause d'une mauvaise série qui au bout d'un moment bloquait la tête de lecture en mode parking, sans aucune possibilité de corriger le problème :(. Voir si ton disque ne souffrirait pas de ce genre de problème (récupérer le No de sére et aller voir sur le site du constructeur ou sur divers forums ..).

Je pense qu'aujourd'hui, les sites sans pisteurs sont plus une exception que la règle :(

C'était au mois d'aout … je suis passé à côté de plein de choses en aout, comme si j'avais vécu sur une autre planète.

J'ai été appelé par des artisans ou commerçants à propos de travaux de rénovation. Initialement j'avais pensé que quelqu'un avait laissé mon numéro au hasard sur un site quelconque de mise en relation entre artisans/commerçants et potentiel client (un site qui demanderait de fournir ses coordonnées avant de fournir des infos ), mais à la lecture de ce fil de discussion, je me demande si effectivement ce ne serait pas des spammeurs qui auraient fait ce genre de chose.

Un peu loin pour moi, mais merci pour le lien.

ah c'était peut-être les premiers MO5 qui étaient en gomme, je ne me rappelle plus.

De mémoire les premiers M05 avaient des claviers en gomme. Mais je ne sais pas si les TO7 en ont eu. En tout cas je ne les ai pas connus.

Non, je veux dire qu'un BSd avec un uptime important ne signifie pas qu'il n'est pas suivi.

Je ne vois pas d'incohérence : la 33dfx a ammené une révolution avec son API Glide (contextualisation du début d'article), mais la GeForce a introduit le concept le Transform and Lighting (T&L) sur une carte qui techniquement semblait en dessous des autres (gravure, vitesse du processeur) mais qui utilisait ses ressources diféremment (pour ne pas dire plus efficacement).

Ca donait ça.

(le site d'ou est extrait l'image)

… c'est de mémoire le premier ordinateur que j'ai utilisé.

J'étais en CM1, l'instituteur avait amené un TO7 au fond de la classe et tour à tour nous sommes allé jouer à un jeu de "destruction d'immeubles" par un avion (je ne me rappelle plus le nom, et il y a eu plusieurs clones de ce jeu).

Ensuite il nous a fait faire quelques petits programme (toujours tour à tour au fond de la classe), puis il y a eu les cours donnés à toute la classe (théorie en classe, puis pratique au collège à 10-15 mn de marche ou il y avait une salle d'informatique - plein de TO7).

C'est là que l'instituteur nous disait sans cesse que "l'ordinateur il est bête comme ses pieds, il ne fait que ce qu'on lui demande".

Il y a eu aussi la "salle informatique improvisée" dans l'école primaire ou les profs amenaient leur TO7 pour que l'on puisse faire nos manips … ( ça a été ponctuel, peut-être avant d'aller jusqu'au collège d'à côté, ou à des moments ou la salle n'était pas dispo).

A cette époque c'était les TO7 de ce type. Ensuite le collège a été équipé des MO5 avec claviers à gomme.

C'est à cette époque que j'ai décidé de mon avenir professionnel ( en CM1).

bah les touches des premiers TO7, qui n'avaient même pas la gomme, c'était encore pire …

Que pense-tu alors de MySQL ou MariaDB

Sur Apache, PHP, Bind, Samba, et OpenVPN tiens aussi, c'est plus que probable qu'il y ai eu des CVEs graves en 10 ans.

ce n'est pas du BSD ça. C'est de la mise à jour de softwares (ports sous FreeBSD, pkgsrc sous Netbsd …). Je ne sais pas s'ils ont fait les mises à jour de leurs paquets. Je ne sais pas si ça a été fait, mais tu peux toujours mettre à jour cette partie sans mettre à jour l'OS.

Maintenant je ne défends pas bec et ongles l'intervenant (si la machine n'a eu aucun suivi, c'est effectivement un problème), mais je veux juste souligner que BSD et Linux ce sont deux mondes différents, et qu'on ne peut pas forcément appliquer (ou s'offusquer de la non application) des mêmes règles de chaque côté. Autrement dit, un uptime de 300 jours sur un BSD m'inquiètera moins qu'un uptime de 90 jours sur une machine Linux …

Dejà il faudrait voir si des failles critiques sur ces composants ont été remontées …. Si ce n'est pas le cas, pas de quoi s'affoler. Ensuite, si des failles critiques ont été remontées, étaint-elles utilisables dans le contexte de ce serveur ?

Je n'i pas le temps de faire la recherche maintenant sur les CVE xBSD. Ah, il y a peut-être eu effectivement un problème avec ssh ces dernières années … a voir si le serveur en question était concerné.

Pensez-vous réellement, que les dirigeants se lèvent le matin en se disant : "comment vais-je réussir à mal gerer mon entreprise aujourd'hui, il faut vraiment que je trouve une solution pour faire que de la merde, sinon je risque la faillite car je ferais les choses bien".

La question n'est pas posée ainsi … ce serait plutôt "Comment je vais réussir à maximiser les profits de mon entreprise (et de mes actionnaires) aujourd'hui pour pouvoir augmenter mes propres profits et mes bonus, au moins pendant les 3 à 5 ans durant lesquels je serai à la tête de celle-ci ?". On a quelques exemples sympa en France, Atos étant le dernier en date, mais il y a eu des précédents (Vivendi, Alcatel, Arcelor, etc …) ou le but a été de se faire le max de pognon quitte à mettre les entreprises en faillite.

Après ce n'est pas une généralité : pour certaines strutures plus petite, la queston est de pouvoir survivre en faisant des compromis sur le court/moyen terme car le libre est parfois un investissement qui s'averera payant que sur le long terme.

Dans certains cas comme le machine learning ou l'analyse de données, la performance est primordiale et c'est pour ca que python est choisi.

Bah c'ezst pas réellement du Python, il y a beaucup de binding python vers C. Ce n'est pas un reproche ni une attaque, mais une précision qui me parait importante, car dans ce cas on ne peut pas dire qu'on choisit python pour ses perfs. Les perfs, c'est le code C compilé qui l'assure.

Attaque classique, mais sans fondement

Pourquoi voir une attaque là ou il n'y en a pas ?

Je pense que c'est l'exception : MSDos6 est la meilleure version de DOS que Microsoft ait pu sortir.

Je pense que Perl6/Raku répondait à un réel besoin, mais est arrivé bien trop tard : d'autres langages on répondu à ce besoin. D'autre part la rupture majeure entre perl5 et Raku de mon point de vue était trop importante pour séduire la communauté Perl.