totof2000 a écrit 9656 commentaires

Laisse tomber, avec 128 Mo, ça rame à mort, j'ai essayé.

Mais en python, c'est la structure de base

Qu'entends-tu par la ? Quelle est la différence avec Python ?

Pour les objets nous sommes d'accord : je déteste l'approche objet de Perl. J'ai toujours évité, mais à un moment quand tu commences à avoir un truc assez complexe ça devient ingérable.

A l'origine ce langage était un "assembleur amélioré" qui permettait de faire des manips "bas niveau" assez facilement (manipulations de bits, etc).

Depuis quelques années, avec les "optimisations" des CPU ou des compilateurs, le code compilé ne correspond absolument plus au code généré. On se retrouve avec des octets "de bourage" dans les structures pour que celles ci soient alignées sur 32/64 bits ...

Je pense que, de nos jours, il est possible via une directive fourni au compilo, de ne pas activer ces "optimisations" et de travailler "à l'ancienne". Un man de GCC devrait t'en dire plus (il me semble avoir cherché il y a quelques mois sur ce sujet).

Quitte à prendre du dédié, et pour débuter, je conseillerais plutot une Dedibox qui elle a l'avantage de proposer des distribs assez standards ... Par contre faut tout faire soi même ...

Dans ton cas, et pour ce que tu veux faire je pex te conseiller debian, avec un bon bouquin ....

J'abonde assez dans ce sens. A mon avis tu devrais :
- choisir une distribution ( au hasard Debian, ou Fedora - bien que je n'aime pas Debian, je la conseille. Suis-je devenu fou ?)
- acheter un bon bouquin qui explique la structure de la distrib et la façon de l'utiliser ( il en existe de très bon sur Debian). Tu apprendras ainsi à gérer les fichiers.répertoires, users,droits, etc ...
- acheter un bon bouquin sur Subversion (il en existe un bon chez O Reilly). Tu apprendras ainsi à gérer les users/droits, structure des repositories etc ... vu de Subversion. SVN n'est pas trop compliqué à gérer, il faut juste savoir ce que l'on veut faire. Par contre ça risque d'être complexe et confus si tu apprends les deux en même temps (Linux/SVN).

Pour moi, la différence entre ces langages de script, c'est les structures de données. Pour simplifier outrancièrement, en shell, la structure de données, c'est la chaîne ; en Perl, le tableau ; en python, la table de hashage et tout ce que tu veux.
Bel exemple de "simplification" qui déforme et conduit à la désinformation ....
en Perl, le tableau
Non, il y a aussi la table de hashage, et tout ce que tu veux, comme en python .... Les différences majeure entre perl et python sont :
- la lisibilité
- la programmation objet qui est native en Python et qui est une glue infame en Perl.

Pour le reste les deux langages font plus ou moins les mêmes choses.

"administration système " ... c'est vague ....

un exemple : créer/agrandir/supprimer des Volume Group/filesystem dans un environnement hétérogène (AIX,Solaris,Linux, HP-UX ayant VxVm ou pas, Vxfs ou pas), de façon plus ou moins automatisée ... Si tu raisonnes pas en "Objet" ça devient vite ingérable.

J'espère que les pythonneux vont arriver à me convaincre à m'investir dans ce langage !

Je ne peux que te conseiller de t'investir un peu dans ce langage, ne serait-ce que par curiosité intellectuelle, et pour savoir si tu passes à côté de quelque chose ou non.

Personnellement je ne suis pas pythonneux, mais je m'y suis mis pour le comprendre et voir ses qualités/défauts.

J'étais perleux avant, et j'étais capable d'écrire des programmes qui poussaient assez loin les possibilités du langage en jouant sur le style de programmation. Cependant, celà rendait mes programmes assez illisibles pour les autres .... et pour moi lordque je devais les retoucher un ou deux ans après. De plus la gestion de la programmation objet est assez rustique et fastidieuse, même si elle existe, et ça j'aime pas trop ....

Python c'est un peu l'autre extrême: assez rigide et une seule façon de faire. C'est pratique pour la relecture mais ça peut être gênant dans certains cas.... Le "natif objet" est très pratique pour résoudre des problèmes complexe, mais à mon gout il pousse un peu trop loin la rigidité. Avantage : un programme écrit en Python est assez lisible, même après des années sans y toucher, et n'importe qui connaissant les bases du langage pourra te relire.

Entre deux il y a Ruby que j'ai découvert relativement récemment et qui est pour moi un bon intermédiaire.

Ne pas confodre "parler", "discuter" avec "polémiquer".

De plus quand on voit comment ont lieu les débats a l'AN ne serait-ce que sur HADOPI, ça ne sert absolument à rien.

Ici, comme à l'AN, tu pars du principe que la loi est bonne, parfaite, qu'elle doit passer et les discussions vont dans ce sens. Si encore c'était le cas, mais là il y a une telle mavaise foi manifeste et affichée, un tel mépris vis à vis des détracteurs que ça ne sert à rien.
Donc tout dialogue à partir de ce moment est inutile et contre-productif,; perte de temps.

J'ai juste un mot à dire : CASSE-TOI PAUVRE CON !!!

Tu te rends compte de ce que tu dis ? Je suis convaincu que oui. On se retrouve avec des propos du même accabit que la censure qui a eu lieu il y a des siècles pendant l'inquisition.

Je vois pas pourquoi vous vous fatiguez à lui répondre : c'est un militant UMP qui est la pour troller et nous faire perdre notre temps pendant que les députés font leur cirque.

Ses commentaires ne méritent pas de réponse. C'est trop gros.

Alors qu'au contraire, sur les machines les plus puissantes de la planète, on ne trouve "que" linux :-)
Non : AIX, et autres Unix propriétaires y sont bien représentés.

Bonjour.

Je ne veux pas être désagréable mais si tu veux des réponses claires, essaie de formuler tes phrases correctement avec ponctuation, et de préférence en évitant les fautes. C'est très difficile de te lire et de te comprendre. Merci.

Je ne pense qu'il faille mettre au même plan la vulgarisation scientifique et la manière dont un journaliste peut rapporter une information.

... si enfin dans certains cas ....

Ce que je veux dire, c'est que, lorsqu'on déforme une information (scientiique ou autre) pour la rendre accessible à des non-initiés il est indispensable de le préciser dans ses arguments ....

au hasard ... derriere le portable ils ont un matos que l'amaeur n'aura pas les moyens de se payer .... De plus en général, ce n'est pas le portable qui génère le son, il ne fait que de l'ordonnancement, lLes sons sont générés par un autre matos controlé par un bus dédié (t'as entendu parler de Midi par exemple ... mais il doit y en avoir d'autres).

c'est un peu comme si tu t'insurgeais contre la vulgarisation scientifique, au prétexte que les livres contiennent trop peu d'équations.

Personnellement je ne suis pas contre la vulgarisation scientifique, par contre je n'aime pas que sous prétexte de "simplification" on en vienne à utiliser des exemples ou des explications qui, par trop simplistes, en viennent à déformer la réalité et à tromper les gens (les journalistes font ça avec l'information : sous prétexte de "simplification" ils en viennent à faire de la désinformation).

La GUI ne te permettra de nefaire que ce que son concepteur a pensé ou jugé utile de faire. La CLI te permettra d'agencer le tout comme tu en as envie et au final d'avoir un résultat personnalisé.

Et le camembert colore est certainement BEACOUP plus explicite que la ligne suivante (Mr les drosophiles, excusez les valeurs farfelues):
total free % used
12045 1240 80
N'importe quoi. c'est plus clair pour toi, pas pour moi.

L'association Vert bon rouge pas bon est biem plus naturel, parlant et instantane que de devoir lire et comprendre % used (qui peut tres bien rechercher l'espace libre et pas utilise et va donc devoir machiner pour avoir le pourcentage libre).

Vachement bien pour un daltonien ...

Oui, en somme, apprendre par coeur la syntaxe d'un commande c'est complique, et c'est pourquoi tu fais des anti seches.
Et apres avoir consulte plusieurs fois ton anti seche, tu as fini par la retenir.
C'est bien plus facile de noter une anti seche pour CLI qu'une anti seche pour GUI.

Ca sert a illustrer un point, le point en l'occurence etant qu'une GUI est bien plus explicite et permet de retrouver par soi meme le cheminement pour mettre en oeuvre une fonctionnalite.

Affirmation totaement absurde et erronnée.

Mais je croyais que la ligne de commande etait achement plus simple a utiliser?
Pourquoi as tu besoin d'anti seches? Serait ce parce que tu utilises des dizaines d'utilitaires en CLI et que tu n'es pas capable de te rappeler de leur syntaxe/parametres?

Des anti seches yen a aussi dans les GUI ....
Par exemple sous Excel, je ne me rappelle jamais comment on fait pour figer les titres d'un tableau en haut de la feuille lirsqu'on scrolle le tableau. C'est pas intuitif ce truc et j'ai jamais réussi à le retrouver dans l'aide excel ...

Marrant, c'est tres precisement ce que je dit: la CLI n'est pas fondamentalement mauvaise, par contre elle requiert beaucoup de memoire, et ca caymal.
Autant que la GUI .... La GUI nécessite de se souvenir dans quel menu il faut passer pour retrouver une fenetre qui te donnera la bonne case à cocher. C'est pareil sauf que d'un coté la mémoire est visuelle, de l'autre c'est un autre cheminement.

Et surtout parce qu'elle est bien mieux utilisee a retenir des trucs pertinent qu'une syntaxe idiote d'un outil qui n'est qu'un outil.
Tu sais les CLI c'est comme les GUI ... Yen a qui sont bien faites et intuitives, d'autres qui sont tout pourris ...

il y a un paquet de règles qui ne sont pas "logiques" quand on n'est pas familier de cet outil,

C'est exactement la même chose avec la GUI .....

Un enfant de 4 ans peut être capable de retenir un numéro de téléphone .... une séquence de quelques lettres c'est tout a fait possible.

Ce n'est pas une preuve mais un avis. Et ca ne prouve pas que la GUI est plus facile a utiliser mais qu'elle s'utilise autrement.

Sauf que le GUI est, comme déjà dit, souvent bien plus intuitif, du coup le 3 va être très rapide (alors que sed il faudra passer un moment à jongler entre le man et un shell pour tester si on a bien compris)
Ceci est absolument faux : la GUI n'a rien de plus intuitif que la CLI. Tout dépend du contexte d'utilisation. Avant de trouver le bouton qui va bien dans la fenetre ouverte par l'option du menu qui va bien , en supposant que la GUI n'a pas la mauvaise idée de me cacher les entrées de menu les moins utilisées, il faut chercher dans l'aide en ligne, la documentation, et bien formuler sa demande dans la zone de recherche. La démarche reste la même.

Oui mais .....

1/ Il faut connaitre l'outil
2/ Il faut l'installer
3/ il faut apprendre à connaitre la GUI

alors que sur un systeme fraichelent installé, sed, c'est natif ...

Ou, plus simplement, tentez d'afficher un fichier texte sans connaitre le nom (plus précisément, le nom de l'executable !) d'un éditeur de texte ou l'existence d'une commande à la more/less. Roger aurait fouillé dans le menu de son clicodrome, ou utilisé l'association par défaut d'un fichier texte à un quelconque éditeur. De même, situation déjà rencontrée.

man -k editor ...

vi (1p) - screen-oriented (visual) display editor

La ligne de commande ne permet pas l'expérimentation, une interface graphique complète (j'insiste sur le complète) le permet. Et, amha, l'expérimentation est malheureusement une phase nécessaire de l'utilisation de l'outil informatique, pour le commun des mortels du moins.

Etrange lorsque je dois construire des regexp, j'y vais par expérimentation... De même pour plein d'autres choses en CLI. Par contre ce n'est pas la même logique je te l'accorde mais ce n'est pasplus compliqué (je pense qu'à la base ça dépend de la façn dont on a l'habitude de réfléchir ...).