steph1978 a écrit 3559 commentaires

C'est de l'open hardware ? On peut fabriquer le sien ?

Comme en gros il faut reprendre le protocole terminal support par le minitel (VT100 ?)., ça doit pouvoir se faire avec n'importe quel ordinateur équipé d'un port série. Donc je dirai un RPi, une imprimante 3D, deux fils et un peu de logiciel. D'ailleurs, ça a été fait : https://hackaday.io/project/180473 et https://hackaday.io/project/181202, entre autres.

• sqlite, stockage par ligne (rows) propice à du transactionnel (OLTP).
• duckdb, stockage par colonne (cols) propice à de l'analytics (OLAP).

Les deux en embarqué (dans le process principal).

Tu pourrais même avoir une application qui stocke dans les deux db : les données live en sqlite et les données historisées en duckdb.

Pas de raison de n'en choisir qu'un seul donc.

je me contente de systemd-nspawn unprivileged

Et donc soit ton système hôte doit embarquer toutes les dépendances soit ton chroot doit embarquer toutes les dépendances soit ton binaire doit embarquer toutes les dépendances soit un mix de tout ça.

ou de vm avec qemu.

Et donc tu as les mêmes problématique de construction d'une image que pour de la containérisation.

Ces solutions répondent à certaines problématiques (une VM plus sécursée qu'un container car par de partage du kernel ; un spawn plus simple à gérer qu'un docker) mais pas à " Comment sécurisez-vous les images [applicative] ?"

D'ailleurs pour Ethercalc, j'ai l'impression que le plus officiel est ceci et ça pèse 375MB.

mais je suppose qu'il suffit de tester.

je n'aurai pas dit mieux :)

En node, l'exemple que j'ai, c'est ethercalc, dont le conteneur pèse 1G.

Ça parait big en effet. J'ai pas trop fait l'exerce pour l'écosystème JS. J'ai testé le Google Closure Compiler sur un petit projet en Elm. Ça donne de bon résultat.

Je vous en sais gré.

Vous êtes bien urbain.

Je suis d'accord que cela ne protège par contre un bufferover flow avec exécution de code et l'exploit qui va bien.

Ça protégera contre une injection de code qui tenterai un exec.

car l'effort risque d'être trop grand pour un bénéfice pas ouf (si on reste que sur la sécurité).

Tout à fait. C'est pour ça que je parle d'effet collatérale. Et que la motivation première est la taille de l'image.

nettoyer un truc en python ou en node

En node je ne sais pas mais en python ça se fait bien. On peut arriver a une taille de quelques 10aines de MB.

Attiré par les CMS statiques, j'avais essayé.

Je pense que c'est très sympa pour un non développeur et que cela réduit la marche vers un CMS autre que wordpress-like pour cette population.

En revanche, pour un développeur qui a déjà son gitflow (markdown -> commit -> push -> build -> deply) ça n'a pas énormément d’intérêt.

Maintenant, je consulte 5-6 comptes, via Nitter

Idem avec Fritter sur mobile.

J'ai essayer les "trends" pour avoir des nouvelles fraîches mais ça parle à 50% de footballers ou de football 🤮, à 90% de people 🤢. Inutilisable.

ressortir la sécurité à tout bout de champ car ça ne fait qu'obscurcir ce qui est important

Je vous demande donc de m'excuser pour cet acte d'obscurantisme bien indépendant de ma volonté.

L'un des classiques étant de monter le FS host sur le container guest.

$ mount
Command 'mount' not found, did you mean:
[...]

Et en vrai, il n'y a pas de shell.

+1

J'ai cette obsession d'avoir des images les plus petites possibles, principalement pour économiser stockage et bande passante. Donc minimiser les dépendances, utiliser alpine comme base et le graal : partir de zéro.

Le multistage aide beaucoup pour ça : 1/ construire le builder 2/ builder l'application 3/ ne garder que le nécessaire.

L'effet collatérale est que cela minimise la surface d'attaque et doit probablement améliorer la sécurité.

Bien évidemment, cela vient en complément de bonnes pratiques plus essentielles : vérifier la source de ses dépendances, faire un scan de vulns, faire des images non root, limiter les capabilities.

stay safe

l'option pull=always

C'est pareil que docker build --pull ... ?

Moi aussi j'utilise ça, en fixant la version majeur pour avoir les fix et éviter les régressions.

Et tant pis pour le cache, les électrons perdus et tout ça.

Si rien a bougé, rien ne sera téléchargé à part les metadata.

"il a un Linux, sûrement un hacker qui vient piller notre magot".

Assurément l'expérience utilisateur est meilleure sur un tracker privé.

Exactement, même ma montre connectée, pas connectée, s'est mise à l'heure d'hiver toute seule.

file /usr/share/zoneinfo/Europe/Paris 

/usr/share/zoneinfo/Europe/Paris: timezone data, version 2, 13 gmt time flags, 13 std time flags, no leap seconds, 184 transition times, 13 abbreviation chars

D'expérience : draw.io si tu veux être maître du placement et plantuml si tu veux laisser le placement à la main de l'outil et donc être plus rapide.
Je privilégie Plantuml sauf si j'anticipe que je vais galérer.

Bridgy ?

Nice ! Et tu le scannes avec quoi le qrcode ? ton deuxième mobile ?

C'est vrai que l'email pour recevoir des messages électronique, que honteux détournement….

En même temps, le temps libre c'est ce dont on dispose. Et l’investir dans une communauté autour d'un logiciel, pourquoi pas. Et pourquoi ne pas l’apprécier.

ou un rocket.chat …

Les goûts et les couleurs …

Moi j'aime bien. J'aime bien le mail mais le souci dans le mail c'est de suivre la conversation entre ceux qui répondent en dessus, en dessous ou dans le précédent message. Le mail c'est pas trop pensé pour une discussion.

J'aime bien aussi le système de badge où plus tu participes plus tu as de privilèges (un peu comme sur stackexchange). Une forme de méritocratie légère.

Si un TRUCMACHIN-autopilot te reconnaît pas, il te passe dessus.
Et il reste … un cas intéressant pour la justice.

J'y vois plusieurs raisons.

Parce que d'un point de vue utilisateur la frontière entre un bug et une fearture request peut être fine. En gros, ça marche pas comme je le pense.

Parce que les outils ne font pas la différence : c'est un ticket. La différence peut se faire dans les champs à remplir ou dans les tags. Mais ça compte toujours pour 1 dans le total.
GH a introduit le concept de "discussions" qui pourrait délester la section issue des demandes d'aide et des discussion de nouvelles features. Peu de projets l'active de ce que je connais.

Parce que les contributeur n'ont qu'un seul endroit où aller voir. Et pas de resaisi à faire entre deux outils. Certains projets on un chat pour le support, un forum pour les discussions, un outil de tickets pour les bugs. C'est un choix valide aussi.

Le moindre document office pesant plusieurs MB, je me demande ce qu'ils mettent sur une disquette. À moins que le Japon ait interdit les formats bloated au profit des formats texte style markdown, dans ce cas, exemple à suivre.

"inflate the baloon !"

Je partage moyen car je ne vois pas en quoi un "format de serialisation"/"un protocole de transpor"e - bref du RPC - est réellement différent d'un autre. En tout cas ferait passer de "artillerie monstrueuse" à "un truc simple (?)".

• oauth2 pour sécuriser les canaux.

Pour des utilisateurs humains, oui mais du coup on est plus vraiment sur du webservice mais plutôt de la webapp. En webservice, on va plutôt utiliser des API keys, des tokens.

• une simplification des règles firewall puisque tout passe par le port 443 sans pour autant sacrifier à la sécurité (cf. oauth2)

Et du coup on met une API Gateway WAF. Vachement plus simple …

• une grammaire standard (PUT, GET, POST, DELETE, …)

Alors oui mais ça c'est la sémantique REST qui est certes plus naturelle over HTTP mais qui aurait pu être mappée sur n'importe quel RPC.

• des fonctionnalités intégrées (le choix du format de réponse quand le serveur le supporte, la description de l'encodage et du format retourné, …)

Pas sûr que ce soit moins monstrueux du coup …