Sytoka Modon a écrit 4565 commentaires

Je voulais dire que basé sur du http(s), on fait du point à point donc on a tendance a centraliser les ressources via un modèle classique client serveur. C'est un peu dans le protocole lui même. Après on peut avoir une architecture plus ou moins décentralisé de serveur ;-)

Cependant, je ne vois pas beaucoup le navigateur/OS pousser les protocoles peer to peer pour le moment et pourtant, pour la diffusion de certain flux comme des télé ou des radios, c'est pas si mal pour l’infrastructure.

Est-ce réellement un problème ?

Le tout http, je pense que oui… Pour régler les problèmes, on va binariser les en-tête puis on va rajouter un en tête 'port' pour multiplexer car le champs tcp port est déjà à la valeur immutable 443 ;-)

Il y a des choses bien mais la voie actuelle est trop centralisée et encombre les tubes de l'internet. Un peu de peer to peer ne fera pas de mal pour fluidifier un peu tout cela (et le multicast (centralisé) ne marchera pas de sitôt sur internet).

On a bien compris depuis longtemps que le javascript prends la même voie que Java. On bascule petit à petit coté serveur, on binarise le truc via du pseudo-code (ASM.js), un truc que Java a cru inventé via la machine virtuelle mais qui existait déjà depuis longtemps (Pascal USCD par exemple)….

Vous ne voulez plus de Java, vous aurez le Javascript. La partie graphique est mieux intégré (c'est du HTML avec du beau CSS de partout) mais dans l'absolu, cela revient dans les gros codes a vouloir prendre le navigateur pour un OS ;-)

Et oui, j'ai confiance dans l'ANSSI :)

Moi pas toujours. J'ai déjà vu un document qui datait un peu…

macos a des virus, peu mais pas moins que GNU/Linux !

iOS n'a pas de virus a priori mais cet OS devrait être interdit en Europe si nos gouvernant avaient un tant soit peu de jugeote… En effet, il est limité a un et un seul dépôt de paquetage entièrement piloté depuis la Californie ! Ceci dis, ce n'est pas un OS sans bogue ;-)

RTFM ;-)

     ps -edf --no-headers | wc -l

En fait, je viens de tester, cela marche aussi… Je suis sur qu'il y a quelques années, cela ne marchait pas d'ou la forme avec cat que j'avais mis au point. Ceci dis, la seconde forme semble préférable et ne pose pas de problème de tty…

# Forme 1
ssh server << END
ls   
END

# Forme 2
ssh server 'bash' << END
ls   
END

J'ai déjà lancé pas mal de jeux de commande à distance via ssh et la commande cat marche mais pas << ! Pourquoi ? Je ne sais pas du tout… Normalement, le << est géré par le shell donc ne devrait pas être transmis à la commande distante comme un post le dis ci-dessus.

Pourrais-tu être plus explicite ? À priori il ne devrais y avoir aucune différence de comportement entre les deux versions.

C'est peut être un bogue du bash mais la solution avec cat marche mais pas l'autre… Une autre soluce consiste à mettre des guillemets (pas testé ici) qui en gros donne une chaîne multi-lignes. On voit alors que le <<END est fait sur le serveur distant et non local.

ssh user@server2 "psql << END
     select tablename from pg_tables LIMIT 1;
END"

Et voilou !

cat <<END | ssh $uat5_oltp psql
select tablename from pg_tables LIMIT 1;
END

Si tout le monde s'accordait à dire que l’espéranto est la langue internationale officielle, et que tous les gamins l’apprennent, alors dans quelques décennies tout changerait.

Giscard parle l'Espéranto et ne l'a pas mis en place dans les programmes scolaires alors qu'il était président. D'ailleurs, les petits français apprennent deux langues étrangères mais quasiment jamais l'Espéranto…

Il faudrait former des profs et avoir une politique bien plus volontariste auprès des jeunes.

Je connais Awk, je ne connais pas Perl.

On passe facilement d'Awk à Perl car Awk est une des bases d'inspiration de Perl ;-)

Pour info, il y a des paquetages tout fait pour YAML ou JSON pour PHP dans Debian. C'est plus facile que d'aller chercher à droite ou à gauche un machin sous github… et en général, c'est assez stable coté API ;-)

Comme c'est du code pour un serveur web, il vaut mieux prendre la licence AGPL que juste GPL.

Sous Windows, il faut que l'utilisateur ait le droit d'installer une imprimante. C'est pas toujours le cas.

Par manque d'inode sur un FS je vais devoir archiver beaucoup de dossiers sur un autre FS.

Jamais eu le cas malgré des gros volumes pleins d'images ou de courriels IMAP… Mes volumes sont tous en XFS.

Surtout que c'est une commande intégrée à Bash ;-)

Eh eh, nous sommes d'accord ;-)

Ben euh… tu sais qu'il y a la completion en PowerShell hein ?

Oui ;-)

Mais sinon, le problème de nouveau c'est pas le nombre de commandes ou le nombre d'options, c'est la fragilité du bousin à cause du formattage en texte plutôt qu'avec un format solide qui assure que tu ne lis pas la mauvaise colonne 3 mois plus tard à cause d'un tab ou espace mal placé.

awk gère pas mal les espaces variables ;-)

Comment je fais un programme Fortran qui s'intègre bien dans PowerShell, comment je connecte tout cela avec mes scripts Perl ou OCamel ? Le paradigme du shell (Bash) et très simple : une entrée standard, deux sorties et un code entier de retour. C'est pas top top mais c'est universel. On enchaîne alors du traitement de texte pour faire de la glu sur tout cela. C'est pas objet, c'est pas typé mais c'est souple comme un langage humain et ça marche pas si mal depuis des dizaines d'année (pour certaines tâches précises).

Pour d'autres tâches, un langage plus typé est mieux. C'est pas pour rien que Larry Wall a crée Perl qui a donné un boom énorme ensuite à tous les langages de script.

Bref, je n'ai pas dis que PowerShell est de la merdiasse. Je dis juste que l'approche texte du shell Bash qui est orthogonale au langage de programmation "classique" est aussi très intéressante et assez universelle pour ce qu'on lui demande de faire ;-)

mais on apprendra pas grand chose d'enrichissant d'un point de vue personnel.

L'objectif d'ERASMUS n'est pas d'apprendre l'anglais mais que les étudiants d'un pays aille voir ce qu'il se passe dans un autre pays. C'est un peu l'équivalent du service militaire a une époque ou les gens du sud montait au nord et réciproquement. Si tu ne trouves pas cela d'enrichissant, je suis inquiet pour toi. Il n'y a pas que les USA ou le royaume unis qui sont à découvrir les yeux grand ouvert !

ERASMUS marche très bien. Le nombre de bébé 'Européen' a explosé ! C'est pas avec les vieux que la construction européenne va se faire mais avec la nouvelle génération qui auront une famille dans deux pays. Il est en train de se produire la même chose qu'au niveau national. Il est tout a fait classique de nos jours d'avoir de la famille au quatre coin du pays. Ce sera pareil demain avec l'Europe en grande partie grâce à ERASMUS.

Ca fait des lignes plus longues à lire oui, mais plus claires et plus solides.

Parles pour toi. Perso, je trouve cela imbitable… En plus il y a un mélange de CamelCase et de non camel case.

Dans la philosophie shell bash, tu passes effectivement par du traitement de texte dont dans 99% des cas, une commande sors du texte que tu vas traiter avec : sed, grep, awk, cut… Bref, cela revient toujours à faire a peu près la même chose. Pas besoin de connaitre un arbre de classe et de méthode, on travaille sur une analyse de texte.

Ensuite, l'objectif est de rester sur du script shell donc on ne fait pas un programme de 20000 lignes ;-) Quand tu commences à vectoriser les variables en bash (en gros simuler un dictionnaire), c'est qu'on va un peu loin…

D'abords, les sorties des commandes ne changent pas si souvent (bien penser à se mettre en LANG=C), ensuite coté réseau, les choses ont tant évolué en 20 ans qu'il est normal que cela change. Avec de l'objet, cela serait pareil.

Exemple, de nos jours, on peut répondre sur la même interface que la demande, même si c'est pas la route définit… Il faut bien un moyen d'avoir un retour. http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming

Aucune chance, le CamelCase est vraiment dégueu !

Peut être que si c'est ISO, les droits appartiennent à l'ISO et ne peuvent être publié ailleurs sans payer ?

Malheureusement, les normes sont rarement gratuites (et sont parfois/souvent un moyen de faire du protectionnisme/élimination de la concurrence).

Pas tout à fait vrai. Tu travailles en shell sur un pipe ASCII. En gros sur un texte qui se fait transformer. C'est assez proche du langage avec des possibilités très large. Ainsi, il y a plus d'une manière de faire une chose comme on le vois régulièrement dans les réponses sur le forum. TimTowTdi - There Is More Than One Way To Do It. Rare sont les langages objets a inscrire cela dans leur cœur. C'est à mon avis un gage de pérennité, de souplesse.

De plus, tu peux écrire une nouvelle commande dans le langage que tu veux, comme tu veux. Tout s'interface juste par traitement de texte. L'API imposé est hyper simple et très souple.