Sytoka Modon a écrit 4546 commentaires

Faut arrêter de colporter des erreurs aussi énormes sur les licences.

Je suis d'accord pour dire que j'ai fait un peu exprès de simplifier mais cela dis, si tu diffuses un code qui dépend du bibliothèque GPL, si tu souhaites de mettre en "conformité", tu es sensé prendre la GPL et non une autre licence ;-) C'est un des rares cas où justement, tu n'as pas trop à te poser de question.

c'est tout, la licence reste inconnue.

C'est toi qui raconte des conneries (effet miroir), c'est pas inconnue, c'est directement le droit d'auteur…

Je n'ai rien affirmé, j'ai dis "SI" ;-)

Donc en général, l'absence d'une licence signifie que les lois sur le droit d'auteur par défaut s'appliquent.

Voila pourquoi il faut toujours mettre une licence libre à la racine du projet si on souhaites partager un jour le code. Et si on ne le partage pas, le fichier licence ne coûte rien !

Sinon, dans ton cas, si le code dépend d'une bibliothèque sous licence GPL, il est alors automatiquement sous cette licence. C'est un des rares cas ou la licence peut je pense s'imposer après coup…

Le script principal ne doit pas avoir de .sh On ne met pas d'extension sur les programmes utilisateurs sous UNIX ;-)

Sinon, je mettrais tout le reste dans un dossier ../lib/monproj/bin et je rajoute en début du script un truc du genre :

distribpath=$(dirname $(which $0))
export PATH "${distribpath}/../lib/monproj/bin:$PATH"
Voile une piste ?

Tout ce qui est peer-to-peer rend pas mal de choses beaucoup plus complexes

Oui et non ;-) Si tu regardes du coté des bases de données NoSQL, pas mal de base sont maître maître et n'assure pas l'intégrité comme dans une base de données relationnels mais privilégie d'autres paramètre du théorème CAP. Au début, on aurait pu croire que ces bases allaient complexifier tout alors que non. Sur certains problèmes, elles s'avèrent que les bases relationnelles… Les clusters de bases NoSQL sont un peu un réseau peer-to-peer spécialisé !

Le peer-to-peer est plus complexe pour certain cas et plus simple pour d'autres. Pas exemple, pour le partage vidéo, un coup de licence globale à 10€ et non seulement, il n'y a plus de gros nœuds et de problème de taille de tuyau mais en plus, l'état retrouve des marges de manœuvres pour la création nationale (70% aux ayant droit et 30% à la création). Bref, les 10€ ne patent pas aux Bermudes et tu te fait pas chié par un empilement de loi ;-)

Le problème est que depuis 10 ans, nos gouvernants bannissent tout raisonnement en peer-to-peer donc on a le cerveau ramolli sur le sujet !

Le P2P c'est bien pour les débit, pas pour la latence. Ce n'est pas le truc optimal qui va marcher pour tout.

Je suis d'accord mais pour écouter la radio ou regardez les vidéo de l'équipe le lundi matin au boulot, c'est parfait ;-)

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 ;-)