steph1978 a écrit 3461 commentaires

Les codes de chiffrement ne sont plus spécifiques

J'en déduis que ext4 peut chiffrer les données, tout comme F2FS. C'est ce que confirme la page wikipedia de ext4.

Quels sont les avantages / inconvénient à chiffrer au niveau FS par rapport à chiffrer au niveau block (dmcrypt) ?

J'ai souvent vu du chiffrement block (c'est ce que m'a proposé ma distrib), rarement au niveau FS. D'ailleurs les man de mount ou mke2fs ne semblent pas dire comment faire.

une abomination tel que pulseaudio

Des analyses plus précises pour nous éduquer ?

Parce que là le seul retour que j'ai c'est celui de mon casque audio qui me dit que c'est tombé en marche…

Je trouve l'approche "user story" très bienvenue.
Le site est plutôt agréable et donne envie.
Par contre j'ai butté sur la punchline : "liberate your genius" je trouve que ça fait très franglish.
Bon c'est pas ça qui va m'empêcher de tester, histoire de comparer à Gitlab que nous utilisons en ce moment.

il a été PROUVÉ par un audit que EncFS n'est pas sécurisé

Est-ce qu'il a été prouvé que crashplan est sécurisé ?

bof,
j'utilise le gestionnaire de package de ma distrib pour le FF mainstream.
Et le targz de la nigthly qui ensuite se met à jour tout seule.
ça me parait pas insurmontable.

C'est intéressant.
Mais ça explique pas l'utilisation de l'extension de fichier.

Je partage ton espoir concernant les containers.
Cela serait une solution élégante pour protéger sa vie privée.
Pour l'instant j'utilise les profiles : un profile poubelle, un profile surf intense, un profile par membre du GAFAM.
Mais cela consomme pas mal de ressource. Et la gestion des mots de passe est un peu pénible.
Reste à rendre la fonctionnalité compréhensible et utilisable (un peu comme le mode privé sauf que c'était plus simple).

J'avoue ne jamais avoir plongé dans le code de FF. Mais quand tu pointes

protection lors du téléchargement contre un large panel d'exécutables sous GNU/Linux, macOS et Windows ;

avec un lien vers le fichier source ApplicationReputation.cpp, cela fait un peu peur.

Cela commence à la ligne 399 : // Extracted from the "File Type Policies" Chrome extension
Pour finir à la ligne 682. Soit presque 300 lignes pour lister des extensions de fichiers qui auraient pu être mises dans un fichier de configuration ou à la rigueur dans une liste.

Je suis perplexe.

D'autre part, ce code n'explique finalement pas en quoi consiste cette "protection".
Ceci l'explique un peu.

Moi je trouve sain que Mozilla se préoccupe de l'usage qui est fait de son produit. Les extensions sont la raison principale pour laquelle j'utilise FF et je suppose ne pas être le seul dans ce cas.
IMHO, cela ne veut pas dire qu'il faut aller jusqu'à inclure des extensions dans le cœurs (c'est très mal passé pour la tentative pocket). Car cela augment la taille du logiciel inutilement. L'idée même d'un système d'extension est bien d'avoir un cœur réduit qui soit "étendable".
Les releases ne sont bloquées que lorsqu'il y a un changement majeur des API voire de l'architecture du logiciel comme pour e10s. Lors des changements mineurs, c'est plutôt les mainteneurs d'extensions qui font les ajustements.

Tu peux créer un miroir du repository fedora sur le PC connecté, sur un disque externe par exemple.
Puis utiliser ce repository local comme source de mise à jour sur le PC non connecté.
Un tuto ici.
C'est typiquement ce que fait un hébergeur pour mettre à jour ses machines.

Si tu sais que tu ne veux que quelques packages, tu peux les télécharger les .rpm un par un puis utiliser la commande rpm pour les extraire. Mais tu vas perdre la gestion de dépendances. Étant sous debian et donc apt, je ne peux pas te donner les commandes exactes. Cela dit, j'ai déjà fait la manip avec apt, justement pour ne pas avoir les dépendances. Et ça fonctionne.

Dans les releases, en effet.
Désolé pas eu le réflexe de regardé.
Mais ça m'a pas manqué, comme je l'expliquais ;)

J'aime bien :

ghash est un exe

puis

elle est primordiale dans la sécurité

Nous n'avons pas les mêmes pratiques de sécurité : j'évite d'installer un exe qui vient de n'importe où. Soit c'est un package officiel de ma distribution, soit je compile en examinant tant que faire se peut les sources. Ça tombe bien, la source go est relativement simple. Donc soit j'installais golang soit je traduisais avec les outils que j'ai sur mon poste : bash, coreutils, sha512 et bc en l’occurrence.

Je trouve ça bien plus primordiale que la génération rigoureuse d'images psychédéliques. Si tu sais lire le bash (tu peux lancer le script avec bash -x au lieu de bash pour voir ce qu'il fait), je veux bien que tu me dise en quoi ma génération de floats est moins secure que la tienne. Ou inversement.

PS: d'ailleurs tu le donnes pas l'exe ou j'ai loupé un truc ? Donc il faut bien compiler le go.

très sympa !

comme je trouve qu'installer golang pour lancer un exe est un peu too much,
voici une version (non exacte) en bash :

#!/bin/bash

function hache {
    sha512sum <(echo -n "$1") | cut -d\  -f1
}

function geninput {
    md1=$(hache "$1")
    md2=$(hache "$md1")
    (echo "scale=5"; echo -n "$md1$md2" | fold -w 8 | head -n 23 | while read h;
    do
        echo "$(( 0x$h + 0 )) / 2^32"
    done) | bc | tr '\n' ','
}

o=${2-ghash.jpg}
s=${3-32}

./gmic ghash.gmic -ghash $s,$(geninput "$1") -o $o

PS : comme l'indique ton wrapper go, il faut une version récente de gmic. La 1.6.8 inclue dans debian stable ne comprend pas "-solidify". J'ai pris la dernière version statique disponible sur le site de gmic.

je veux bien te donner 500€ si tu écris un truc au moins aussi bien.

Si free.fr est bloqué, imp.free.fr le sera aussi.

Ah bon, tu bosses pour le Department of Telecommunications, Government of India ?

En dehors du fait que tu aurai pu faire un effort pour mettre un titre un peu plus explicite à ton post et que tu ne dis rien de ta config, ton problème n'est pas simple.

Pour avoir un bon support matériel, il faut une distrib récent. Or une distrib récente aura tendance à supposer un matériel relativement puissant. Donc même si Linux s'en sors mieux que mswin sur le support des vielles machines, ce n'est pas non plus magique.

En bref, quant tu aura fais le tour des distributions encore maintenues et qui se veulent orientées petites config, sans trouver ton bonheur, il faudra que tu construises ta distrib toi même : avec le noyau et drivers qui supporte bien ton matos, un window manager qui ne pompe pas trop, etc.

Si tu veux la dernière version d'un navigateur web ou un libreoffice sur ces config, oublie.

Pour ma part je faisais tourner LO, FF et PyCharm, le tout avec LXDE sur un Core2duo et c'était supportable.

Nan mais ça existe partout, y compris sous mac.
Et par shell tu veux dire que mon zsh que j'utilise tous les jours n'est pas un vrai shell ?

Le master d'origine était sous mswindows…

J'ai l'ancienne version : core i5, 250GM SSD, 8GB RAM, pas de tactile.

J'ai une mint uptodate depuis … longtemps en fait.

Ce qui marche très bien : en fait à peut près tout : wifi, bleutooth, webcam, le mutli-écran HDMI ou VGA, veille, hibernation.

Ce qui ne marche pas par moment :
- le wifi peut tarder à détecter les réseaux, dans ce cas, soit un peu de patience soit un "sudo iwlist scan".
- à la sortie de veille, il peut arriver que les caractères du window manager (titre de fenetres) disparaissent (bug carte vidéo ?) mais pas dans les applications (pas toutes). Dans ce cas, je change le paramètre d'échelle ou d'antialiasing (puis je reviens à mes réglages).
- le MTP (transferts de fichiers mobile-pc) est capricieux (il a été corrigé dans une MaJ puis re cassé). J'utilise ADB dans ce cas qui me sert aussi à backuper des données du téléphone non accessibles en MTP.

Ce qui marche mieux qu'avec le master d'origine :
- la veille se fait bien mieux, et avec une progression (eg: si je le réveille tout de suite, seul l'écran s'était éteint, puis le cpu, etc).
- l'hibernation : il en sort alors qu'avant non
- l'autonomie : on va dire 4h sans forcer.
- la manipulation de fichiers : on sent vraiment le SSD.
- un millier de trucs liés à l'OS : on peut faire de majuscules accentuées ! la quantité de logiciels installables par le gestionnaire ! un vrai terminal et un vrai shell. etc.

j'utilisais dans mon studio un vieux portable sur lequel je pouvais, avec Linux, figer la fréquence CPU et la vitesse du ventillo. Je les mettais tous les deux au plus bas. L'intérêt est que le CPU chauffe peu et a donc pas besoin de trop de ventilation et que le ventilo constamment faible est moins dérangeant qu'un ventillo qui s'allume et s'éteint régulièrement

De loin ça se ressemble, de près ça a rien à voir.
Un clavier physique fait appel au touché pour bien repositionner les doigts de manière imperceptible.
Sur un clavier virtuel tu n'as pas cet effet, c'est donc très peu utilisable pour de la bureautique. Donc le produit a échoué.
Apple essaye pour quelques boutons personnalisables par application mais ils ne seront utilisables que ponctuellement.
J'avais vu un clavier avec des touches physiques dont le motif est fait avec un écran LCD - genre ça. Ça, ça peut être intéressant.

Idem : faire le ménage dans des vieux backups.

J'ai implémenté un petit outil à base de sha512 et lmdb, avec glu python et shell.
Ça a l'avantage d'être très économe en mémoire, contrairement à l'implémentation choisie pour FIM à base de collections Java.

Après mon outil n'était pas aussi riche fonctionnellement.

tu peux donner le lien ?
je duckduckgoé mais ça donne trop de résultats.

non, il fait la conversion de l'image,

Non, il fait du rendu SVG.

rsvg in.svg -o out.png fait le rendu d'un SVG en PNG.

Les outils qui récupèrent l'information soit sous forme d'image soit sous forme de texte sont très hétéroclites, écrits principalement en shell encapsulant des exécutables.

J'aimerai tant que faire ce peut rester sur ce modèle pour l’agrégation et l'affichage.

gerer l'affichage dans le framebuffer

Il est possible de faire cat rawpixels > /dev/fb0

Reste à faire l'agrégation.

Je pensais utiliser une template en SVG et utiliser rsvg pour le rendu.