Sytoka Modon a écrit 4556 commentaires

Ça veut dire bronsonisé !

Xen est l'hyperviseur. Chaque logiciel tourne dans un machine virtuelle sous Xen. Une VM par logiciel. C'est un peu comme les containers mais plus sécurisé /a priori/ car les containers, c'est pas encore top top coté sécurité.

Sinon, c'est bien pour du code privateur mais c'est aussi bien par exemple pour de la navigation web anonyme… Le javascript tourne dans la boite fermé de ton navigateur qui tourne lui-même dans une VM fermé.

Le principe de Qubes m'attire terriblement mais je reste dubitatif quant au bien fondé d'un système orienté sécurité comportant des logiciels privateurs

Parfois, tu es obligé d'utiliser un logiciel privateur dont tu ne contrôle pas le code source. C'est aussi une partie de l'intérêt de ce genre de projet de mettre ce bout de code non sécurisé dans une boite bien fermé dont tu contrôles les trous.

Attention, x2goclient ne fonctionne plus si on est trop sévère coté algo… Je pense que le problème doit être du coté du client ssh en python qui doit être un peu faible ?

Tu pourrais envoyer depuis ton serveur https le knock qui va bien en CGI qui ouvre le port SSH. Du coup, cela sépare bien les choses ;-)

Une question que je me pose a propos de ce genre de matériel, cela fonctionne comment avec la téléphonie filaire, par exemple avec Orange ?

Le /boot est séparé si tu chiffres ton poste. C'est l'unique raison pour laquelle nous l'avons mis à part. Sous Debian Squeeze, on arrivait à booter avec du /boot sur LVM avec grub… Sur les dernières versions, cela ne semble effectivement plus marcher.

Pour le SWAP, on disait il y a très longtemps deux fois la RAM puis la taille de la RAM pour le suspend. On met 120Mo max sur nos postes et cela marche très bien. Sur la plupart des serveurs, j'ai viré la SWAP qui ralenti inutilement. Sur les machines de calcul, j'ai aussi viré le swap qui fait bien plus de mal que de bien.

Bref, on vit très bien sans SWAP.

Perso, je suis abonné aux planets via les flux RSS/Atom dans Thunderbird ce qui permet d'avoir deux logiciels différents pour lire les posts.

Je doute que le logiciel soit d'une grande aide pour la conception de barrage. C'est un problème de charge statique et si on veut calculer l'écoulement qui sortirait par une conduite forcée, dans le cas de petite retenue, il y a des problèmes de surfaces libres fluides / air sur la surface libre du lac qui sont un merdier à gérer…

C'est d'après ce que j'ai compris un code turbulent donc c'est plus adapté aux problèmes de calcul de turbine (encore faut-il gérer les maillages tournant) ou les écoulements turbulents dans des tunnels (simulation de l'écoulement dans les veines de soufflerie par exemple).

A savoir qu'il y a en gros deux types d'écoulement : laminaire et turbulent. Tu as les deux types en ouvrant ton robinet de lavabo. Laminaire au début puis turbulent ensuite lorsque le débit augmente. Les écoulements turbulents sont chaotiques d'où quelques soucis pour les simuler ;-)

on peut raisonnablement considérer

Depuis quand les juristes sont des gens raisonnables ;-)

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"