totof2000 a écrit 9656 commentaires

Quand un humain doit choisir un nom, il choisi rarement un nombre mais plutôt un mot

Va dire ça aux gens qui ont inventé les UUID en FSTAB, et on en reparle.

Un code en morse eou en binaire ….

C'est plus facile à identifier et à communiquer.

Pour le morse c'est ta ta ti ta ti ta ta …..

Pour moi la meilleure démo serait d'utiliser l'environnement sur son propre poste (portable ou fixe) et de montrer à son interlocuteur à quel point il est productif avec.

Bref, je suis à la recherche d'une belle démo de gnome shell pour montrer à mes amis linuxiens ce qu'il loupe, auriez vous ça en stock ?

Toutes les démos du monde ne me feront pas passer à Gnome Shell (au moins tant que les points qui me gène ne seront pas corrigés).

Je connais autour de moi des gens qui l'aiment, d'autres qui ne l'aiment pas, et pas un seul ne l'a pas essayé au moins une fois. Mais là tout dépend de l'utilisation que l'on en fait.

Je reconnais cependant comme toi que Gnome Shell est moins pire que Unity, mais ce n'est que mon point de vue, fortement lié à l'utilisation que je fais de mon environnement. D'autres personnes autour de moi utilisent Unity et en sont très satisfaites. Alors pourquoi vouloir à tout prix les faire changer ?

Vu les circonstances, j'ai une crainte à l'idée de commencer a modifier les données du disque d'origine, au risque de remettre en cause le fonctionnement complet de la machine.

ATTENTION !!! Personne ne t'a suggéré de modifier les données d'origine. Toutes les manips suggérées sont à faire sur la copie de destination.

Il s'agit d'un OS à part entière, contrairement à une distribution Linux qui va chercher des morceaux à droite et à gauche et qui compile le tout.

ces machines doivent être conçues et validées pour plusieurs systèmes,

Pourquoi ? Elles sont vendues sans os, mais rien ne dit que tous les OS tourneront dessus.

Pour certains, "from scratch", c'est juste prendre un framework, et dériver quelques classes déjà toutes faites pour répondre au besoin métier. De plus il est très rare que le code et les commentaires te donnent une idée précise de l'architecture logicielle. Donc dans certains cas, tout recoder peut se justifier.

Maintenant, comme dit plus haut, tout dépend de ou on part et des outils que l'on a. Et si le "développeur" n'a appris dans sa formation qu'à utiliser un framework, dans ce cas je comprends sa réponse.

C'est sur quelle distrib ? J'étais prêt à taper sur Gnome, mais entre temps je me suis dit que c'est peut-être un problème d'intégration dans la distribution (un truc oublié comme ça arrive parfois sur les environnements complexe).

Oh, un nouveau; Bonjour nouveau :), et bienvenue sous Linux. Ca fait plaisir de voir que certains tentent l'aventure même si ce n'est pas toujours simple.

Pour le problème d'extinction, j'ai un peu la même chose ici : une machine qui ne s'éteint pas via le bouton "éteindre" ou via le menu de l'interface graphique : c'est la dernière Ubuntu LTS. Ca doit être lié au matériel (un PC HP) parce que sur une autre machine à côté, il n'y a pas de proœblème.

Pour l'imprimante : personnellement je fuis les imprimantes Canon car elles ne sont quasiment jamais reconnues sous Linux : ce n'est pas la faute à Linux mais à Canon : personnellement je me tourne vers les imprimantes HP qui fonctionnent plutôt bien sous Linux.

En ayant le modèle d'imprimante, la version Ubuntu et le modèle du PC, on pourrait mieux t'aider. Sinon, pour l'imprimante, si elle est toute neuve, il faudra peut-être attendre un peu pour qu'elle soit reconnue : parfois il arrive que du matériel trop récent ne soit pas reconnu de suite.

Essaie de voir sur http://fr.software.canon-europe.com/index.asp si ton imprimante y est.

Reste à savoir ce qu'on fait avec les "updates" de RedHat : tu les appliques sans tester? La ou tu utilisais une version x.y, tu installes le jour suivant une version y.x+1 sans tester?

Par principe, sur un système de prod, je désactive les updates automatique, je passe chaque modif sur un système de test, que ce soit du Redhat, ou n'importe quoi d'autre. Et bien souvent, je me renseigne par rapport à ce qui tourne dessus : est-ce que l'on garde le support éditeur des softs par dessus l'OS si on applique les updates ? En général, c'est oui, mais il arrive que ce soit non dans l'immédiat. Et ça c'est valable tant pour les softs windows que les softs Unix/Linux.

Je ne veux pas "casser du Linux", juste faire remarquer que sous Linux il y a aussi des updates (c'est vicieux les updates, ça prévient moins qu'un SP) qui peuvent casser des choses (tiens, ma clé SSH ne marche plus depuis le dernier apt-get update…).

C'est même plus vicieux que sous Windows : vu que toute la distrib est gérée par le sustème d'update, lorsque tu lances un apt-get update (ou un yum update), tu peux te retrouver avec un truc cassé sans savoir quelle mise à jour a pêté quelque chose : mise à jour des couches basses OS ou mises à jour applicative : c'est pour ça que je préfère de loin la gestion de l'OS "à la BSD" ou il y a séparation des diverses parties que tu peux mettre à jour progressiveent : plus facile de savoir à quel endroit ça pête.

Je conçois qu'on trouve que les updates sont moins violents que les SP, n'empèche c'est pas le truc parfait qui bouge rien de rien non plus.

On est d'accord, et pour celà, les mises à jour automatiques devraient être désactivées sur tout système de prod un tant soit peu sensible.

A noter qu'avec Yum, il est possible de faire un retour arrière sur les installation de packages. Je me demande si c'est possible avec les mises à jour (pas encore testé), et si on a la même chose sur Debian.

Je ne sais pas pour XP ou Windows Enterprise seever, mais par contre je me rappelle avoir eu de mauvaises surprises lors de l'application de SP sur NT4 à l'époque ou je faisais du Windows. Et je sais que sur SAP R/3 par exemple, il était hors de question d'appliquer un SP tant qu'il n'avait pas été validé par SAP.

Cela dit, ouvrir sa gueule pour « dire la vérité » n'apporte souvent que des choses négatives. La meilleure stratégie lorsqu'on n'est pas aux manettes c'est de la boucler. Sa évite par exemple de se trouver dans la liste noire de son supérieur.

Effectivement. Par contre si tu apportes une proposition avec les chiffres qui vont bien, les preuves précises et les arguments précis, ça peut passer. Mais ça prend du temps et quand ce n'est pas le dossier ur lequel on t'a demandé de bosser, ça peut poser problème.

Parce qu'à l'époque j'étais occupé à autre chose et surtout on ne m'a pas demandé mon avis … Mais comme dit plus haut, aujourd'hui, avec le recul, je ferais autrement.

Sincèrement, je ne vois pas comment on peut arguer que le support du noyau ne dure que 3 ans, surtout avec RedHat et SuSE pour les professionnels. Et puis ce n'est pas vraiment mieux du coté d'AIX : http://www-03.ibm.com/systems/power/software/aix/support/release_strategy.html ! Ça me laisse à penser que ceux qui ont fait ces choix ne connaissaient pas vraiment l'alternative aux des systèmes fermés du genre AIX.

C'est un peu ce que je me suis dit à l'époque, mais comme j'ai vu passer le projet de loin et que je ne participais pas aux instances de décision, je n'ai pas cherché plus loin. Par contre vu que la boite disposait d'un parc conséquent AIX, la maintenance ne posait pas trop de problème, et ce pour une durée de plus de 5 ans. Si c'était aujourd'hui, je pense que je ne laisserai pas passer, et que je ferais une proposition/chiffrage à base de lames sous Linux à côté de la proposition AIX.

Pour le projet sur lequel j'ai bossé, le choix Linux se serait imposé si le soft avait été dispo sous Linux lors du lancement du projet. D'ailleurs, initialement, le projet devait se faire sur Superdome, puis le choix s'est porté sur des chassis C7000 avec lames Itanium et lames x86/Linux. L'intéret est de pouvoir remplacer à l'avenir les lames Itanium par des lames x86 Linux, lorsque la qualif aura été faite.

Je baigne aussi professionnellement dans ce genre d'univers avec du Mainframe, de l'AIX, du Linux, mais aussi de la (grosse) base de données DB2 qui a migré sur de l'Oracle tout ça sous Linux (et même du Windows Server pour d'autre choses). Le problème étant que certaines sociétés savent se montrer "persuasives" envers les décideurs, qui n'ont pas forcement les compétences techniques pour déceler un enfumage caractérisé.

Aujourd'hui les choses changent. Linux devient de plus en plus le choix No 1, et les autres OS proprios arrivent derrière, avec justification du besoin. On a parfois affaire à des réfractaires à Linux en raison des habitudes, mais ça devient de plus en plus difficile pour eux de se justifier.

Le projet en lui-même ne collait pas trop avec le noyau : simplement les gens qui ont travaillé sur le sujet ont simplement argumenté sur le fait que le support noyauu de Linux n'était que de 3 ans, qu'au bout de 3 ans ça les pousserait à changer de noyau et refaire des tests, et ils sont partis sur AIX. Le contexte du projet, je ne m'en rappelle plus trop, ça remonte à plusieurs années déjà (plus de 5 ans). C'était basé sur une base de données Oracle, avec forte volumétrie, et un applicatif par dessus dont je ne me rappelle plus.

Sinon, des projets qui prennent plus de 3 ans à être développés, ce n'est pas si rare. Le dernier projet important sur lequel j'ai bossé a bien mis ce temps entre le moment ou les premiers dossiers sont passés devant moi et le moment effectif de la mise en production. C'était un grops projet de refonte du système de facturation d'une grosse boite. Les bases tournaient sur de l'Oracle RAC sous Linux, mais l'applicatif lui tournait sous HP-UX. La version sur laquelle les tests avaient été faits n'était pas dispo sur Linux, mais la version N+1 l'était. Mais comme le changement de version aurait eu un impact non maitrisé, ils ont décidé de laisser l'applicatif sur HP-UX, et de réserver le passage à Linux lors d'une future évolution.

Dans ce cas je suppose que l'argument avancé pour ne pas utiliser Linux dans certains projets en raison de la faible durée de support ne tient plus. Ca m'avait surpris à l'époque mais je n'avais pas les arguments et les preuves nécessaires, donc j'ai laissé couler.

Il faut surtout éviter de commencer par faire apprendre l'installation : meilleure façon pour faire peur.

Pour installer Linux, vaut mieux encourager les gens à contacter quelqu'un qui sait faire (via un LUG par exemple).

Red Hat, c'est 10 ans,

Avec support pendant 10 ans de la même version du noyau (modulo correction de bugs et de failles de sécu ) ?

… je trouve que 3 ans c'est un peu juste pour le monde de la prod.

J'ai travaillé dans certaines structures ou 3 ans, c'est le temps que met un projet pour sortir. 3 ans, c'est la phase de développement + tests (et encore, certains durent plus longtemps). Certains des projets que j'ai vu passer ne sont pas sorti sous GNU/Linux justement parce que les 3 ans de support étaient trop courts. On ne pouvait pas se permettre de relancer une batterie de tests juste avant la sortie en prod. Donc un OS proprio a été choisi.

C'est dommage, parce que je suis sur que je ne suis pas le seul à avoir vu passer ce genre de cas de figure. Si on prend Microsoft par exemple, on en a au moins pour 10 ans; Alors certes 10 ans c'est peutêtre un peu trop long, mais passer de 3 ans à 5 ans, ce serait peut-être un juste milieu ?

Note : j'ai bien vu que le 2.6.32 reste supporté 5 ans, mais ça reste une exception.

Peut-être, mais dans le cas présent, sur ce commentaire, ce n'est pas le but: j'essaie juste d'expliquer pourquoi je peux paraitre résistant aux changements (et l'un des changements majeurs de l'écosystème Linux aujourd'hui c'est bien systemd donc un peu normal qu'on en parle beaucoup). J'ai essayé de ne pas lancer de troll dans ce commentaire, c'était juste une explicatiuon. Et en général je fais ça le Vendredi, jour traditionnel des trolls. Sinon j'évite (bien que ça me démange dans certains cas …).

Certains ici ont tendance à me classer dans la catégorie "résistance au changement". Ce genre de situation que j'ai vécu dans de nombreux cas devrait vous faire comprendre pourquoi je vois souvent d'un mauvais oeil certains changements.

J'ai subi de nombreux changements de ce genre (changer pour changer, modifier un truc qui marche bien et qui fait son travail pour un autre qui marche moins bien mais qui fait "plus moderne"), tant dans le domaine organisationnel (au taf par exemple), que vis à vis des outils informatiques (la grand mode de tout passer en IHM graphique m'a fait perdre beaucoup de temps et de productivité dans certains cas par exempmle : des choses que j'avais automatisées en scriptant n'étaient plus possible à automatiser). J'ai connu aussi ls changements "pas fini" qui ne faisaient que la moitié du boulot (et sur ce point Mandrake me laisse un goût amer : en se présentantcomme distribution "facile" à utiliser, mais avec plens de bugs partout, elle a dégouté plein de monde de Linux).

En ce moment je vois systemd comme une belle erreur (dans l'état actuel des choses : j'espère que ça va changer, en tout cas je demande pas mieux). Ce n'est pas tant l'outil en lui-même que la façon dont c'est fait qui me gène. Et certes, j'insiste beaucoup sur ce sujet (en partant sur des trolls parfois, c'est juste pour me défouler), mais c'est surtout parce que je crains un fiasco comme j'en ai connu par ailleurs. Wayland par exemple, ne me fait pas le même effet : je déplore la disparition de la transparence réseau qui est très pratique, mais d'un autre côté je suis moins réticent à ce changement (peut-être tout siplement parce que contrairement à systemd, Wayland ne veut pas faire de choses qui ne le regardent pas : il veut juste afficher).

Tout ça pour dire que le changement pour le changement c'est idiot. Le cangement pour le "moderne" ça n'a pas de sens. Par contre changer pour répondre à un besoin réel (mais ne pas chercher à étendre inutilement le besoin), là je suis d'accord.

et comment tu distingues un disque amovible, que tu vas monter à la demande, et pouvoir ejecter
d'un disque interne non monté au demarrage que tu vas monter à la demande et pouvoir ejecter

Ce n'est que la reformulation de ma question ça.

et apres va expliquer à madame michu que sa clef USB est dans /media/michu/clefusb
alors que les photos du petit dernier sont dans /media/diskdur

Et comment fais-tu dans le cas ou plusieurs personnes sont connectées en simultané ? Ou doit apparaitre le disque Windws ? Chez Mme Michu p l'autre utilisateur ? Et comment dis-tu à Mme Michu si c'est la session de M Michu que les donées se trouvent maintenant dans /media/MMichu/diskdur ?

Tu sous-estime Mme Michu. Si tu lui dit que les données des disques internes sont dans /media/disque et que les données des périphériques amovbles (disque dur externe/clé USB) sont dans /media/MmeMichu/usb, elle comprendra.

C'est un peu mal fichu là je trouve non ? Je ne remets pas en cause le multi-seat (bien que je ne m'en serve pas pour le moment), seulement là il est ridicule de traiter un périphérique amovible de la même façon qu'un périphérique non amovile. N'y a-t-il pas moyen de modifier la règle udev pour que cette façon de faire ne s'applique qu'aux périphériques amovibles ?

Les distribions GNU/Linux ont favorisé cette confusion en refusant de séparer le système de base des applications. D'autre part, les OS proprios, en voulant intgrer tout et n'importe quoi par défaut ont aussi participé à cette confusion.

Pour moi, et je pense que pour beaucoup ici, un OS correspond à ce qui est intégré dans une installation de base Netbsd. J'aurais tendance à y intégrer le serveur X qui est une interface permettant de programmer/utiliser le matériel graphique, mais je n'y pas un environnement de bureau. Ca correspondrait pour moi plus ou moins à une installation minimale de Debian ou Redhat/Centos. avec quelques petits utilitaires en plus qui n'y sont pas forcément intégrés (le serveur X pour ne pas le citer) et peut-être deux ou trois choses en moins, mais à quelques détails près, il s'agit de la définition historique d'un OS.

C'est une des raisons qui me fait préférer les xBSD aux distribs Linux.