L’aspect sécurité de l’article et effectivement très difficilement compréhensible. Pour moi c’est juste du verbiage sans aucun argumentaire technique.
Et non les vilains pirates (de l’air) ne vont pas réussir à déchiffrer les flux HTTPS ;)
Du coup si je comprends bien, dès lors qu’on se connecte à un wifi public, les protections de type TLS/SSL ne s’applique plus. Dans ce cas en quoi ajouter un VPN se basant sur les mêmes protocoles ajoute de la sécurité ? À moins que les VPN ne se basent pas sur TLS/SSL ?
C’est possible d’expliciter la phrase «En conséquence, ils peuvent facilement accéder à toutes vos données lorsqu’elles passent par leur ordinateur.» ?
La commande composée man cmd | sed…en soi est valable en ligne de commande (càd pas dans un script). Mais cela implique que l’utilisateur maîtrise les expressions régulières, ce qui est justement l’inverse du résultat recherché en créant un script Shell. Sans compter les inconvénients potentiels.
La fonctionnalité adéquate est implémentée dans LESS. Les solutions avancées (courantes) forment une sorte d’antithèse (elles produisent un aspect cosmétique). Maladroit, inélégant et superficiel. Néanmoins, cela est potentiellement plus efficace que de connaître tout un tas de choses.
/^[[:blank:]]+-\bk
L’utilisateur effectue une recherche dans un fichier. On lance less <nom du fichier> puis on saisit une expression régulière. La barre oblique / est une commande interne à less pour lancer une recherche. man repose sur less par défaut.
La sécurité est un sujet complexe, et pour ma part je ne suis aucunement surpris que des réseaux d’ordinateurs zombies continuent d’exister. C’est tellement facile de louper quelque chose…
Au cas ou je propose une piste pour limiter son exposition dans un 2e article : Cloudflare Tunnels
Voir à travers un prisme. Contraindre la pensée. Pour quelle finalité ? Des termes n’ayant aucun sens, donc inutiles (si l’on s’en fie à leur terme « crypter » sur chiffrer.info). Déplorable.
En voulant survoler l’administration système, je suis parti loin. À force, je m’approche (tourner autour) de la programmation système. Cela peut paraître bizarre dit comme cela. Donc, récemment, je faisais encore de l’auto-hébergement grâce à un RPi 2 avec YunoHost. Cela fonctionne mais j’ai quand même des inquiétudes. D’abord, mon site Web (blog) n’a pas les caractéristiques souhaitées. Le problème est que je dois avoir un bon modèle en fonction du contenu. Or, soit je ne connais ni l’un ni l’autre, ou alors, l’un ne va pas sans l’autre. Un système de gestion de contenu ne me convient pas, pour ainsi dire. Ensuite, faire les choses à moitié ça m’énerve. Prendre du temps ça devient lassant. Donc, j’essaye d’acquérir de nouvelles bases afin de me faire une représentation et redéfinir. C’est pas forcément terrible mais je fais comme je peux. Mon objectif c’est d’avoir une infrastructure gérée avec du code grâce à GNU Guix. Pour finir, par nécessité, il faut absolument que je renforce la sécurité : je n’ai aucune envie qu’on exploite mon matériel, qu’on me prenne des données (ou pire encore). Il faut aussi que je me forme en cybersécurité pour réagir dûment (avoir sa propre protection). Bref, j’ai commencé par les bases, et les choses finiront par se compléter (en rajoutant un peu de rétro-ingénierie pour s’assurer de la compatibilité de l’ensemble). Effectivement, à notre époque, je ne comprends pas pourquoi les réseaux d’ordinateurs zombies continuent d’exister.
Il y a aujourd’hui tellement de petits logiciels qu’il n’est plus possible pour les distributions de tout packager elle-même. Certains logiciels évoluent rapidement et c’est compliqué de les avoir à jour dans les distro (si déjà ils sont présents dans les dépôts car c’est pas forcément le cas).
En tant que développeur d’application, je vois un autre intérêt à Flatpak : je peux packager moi-même mon logiciel d’une manière compatible avec toutes les distributions. À une époque j’avais un PPA pour Ubuntu, des paquets AUR pour ArchLinux, quelques RPM (pas trop dans les règles de l’art) pour Fedora / Mageia, etc. Mais je n’ai plus le temps de m’occuper de tout ça.
Je suis d’accord pour les Flatpak, très pratique pour les logiciels propriétaires.
Le fait d’aller vers ce format est je pense la course à la nouvelle technologie.
Si une nouvelle version d’un logiciel a besoin d’un Qt plus récent par exemple, il est pris directement via le framework disponible en flatpak et on peut s’affranchir d’une bibliothèque obsolète sur le système source.
Je peux comprendre que certains restent sur une Debian stable par exemple tout en voulant des logiciels un poil plus récent qui corrigent parfois des bugs ou ajoutent des fonctionalités intéressantes.
Dans le cas d’un LibreOffice sous Debian, il y a en effet les DEB du site tu me diras, mais s’il y a une bibliothèque pas assez récente sur le système, tu es coincé.
Je privilégierais un Flatpak sur une base Debian au lieu d’un PPA ou dépôt tiers, qui causera, pour un logiciel, moins de soucis sur le long terme (car rappelons le, on n’installe pas son système toutes les semaines)
Flatpak c’est pas mal dans deux cas de figure. 1) Quand il faut installer des bousins propriétaires comme Teams, Skype, Zoom ou Spotify, et 2) Quand on a une appli avec des dépendances complexes et qu’on n’arrive plus à compiler une version récente sur sa distrib (comme Darktable > 4.0 sur une base RHEL 8.x par exemple). Ce qui est bien avec Flatpak, c’est que ça t’installe toute l’appli dans une sorte de bac à sable à part, ce qui peut être une base pratique pour isoler certaines applis potentiellement intrusives comme Skype.
Ceci étant dit, la tendance des distributions à aller de plus en plus vers ce format (ou vers Snap) pour leurs “App Stores” me paraît assez funeste. Faudrait rappeler aux mainteneurs des distributions la signification de “partagées” dans “bibliothèques partagées”.
Merci pour ton billet très intéressant.
“Du coup, pas de contenu statique, pas besoin de suivre les comptes. “ -> pas de contenu dynamique tu voulais écrire non?
Merci pour ton retour ! Alors je n’étais peut être pas assez clair dans mon introduction, mais mon ambition n’était sûrement pas de faire un état des lieux du champ des possibles sur le sujet, mais plus de partager mon approche personnelle, avec mes choix, par rapport à mes besoins.
J’ai le sentiment de par mon expérience que les debian-like sont plus populaires en termes de volume d’utilisateurs, et si j’en crois les estimations ce ressenti semble plutôt vraisemblable. Après, je ne compare en aucun cas la qualité ou les fonctionnalités de l’une ou l’autre des solutions, je ne connais pas suffisamment les *BSD pour juger. Mais je me met en todo de tester FreeBSD prochainement ;)
Pour résumer mon expérience, j’ai testé différentes choses (clairement pas toutes !) et je suis arrivé aujourd’hui à un fonctionnement qui me permet de facilement expérimenter de nouvelles choses, et de répondre à mes besoins long terme qui sont en effet d’héberger différents services. Je m’essaye à l’exercice de partager cette expérience, à la fois pour la faire connaître et également pour en débattre et collecter d’autres retours d’expérience qui peuvent me faire découvrir de nouvelles manières de faire. Donc en tout cas, merci d’avoir pris le temps de me lire et de me répondre ainsi !
Je sens que les esprits s’échauffent, je vous invite tous les deux à un dialogue dans le calme et le respect. Vous pouvez également échanger via les Messages privés du Jdh.
Il a été rédigé par ChatGPT cet article ? Il est rempli d’absurdités.
L’aspect sécurité de l’article et effectivement très difficilement compréhensible. Pour moi c’est juste du verbiage sans aucun argumentaire technique. Et non les vilains pirates (de l’air) ne vont pas réussir à déchiffrer les flux HTTPS ;)
Du coup si je comprends bien, dès lors qu’on se connecte à un wifi public, les protections de type TLS/SSL ne s’applique plus. Dans ce cas en quoi ajouter un VPN se basant sur les mêmes protocoles ajoute de la sécurité ? À moins que les VPN ne se basent pas sur TLS/SSL ? C’est possible d’expliciter la phrase «En conséquence, ils peuvent facilement accéder à toutes vos données lorsqu’elles passent par leur ordinateur.» ?
La commande composée man cmd | sed… en soi est valable en ligne de commande (càd pas dans un script). Mais cela implique que l’utilisateur maîtrise les expressions régulières, ce qui est justement l’inverse du résultat recherché en créant un script Shell. Sans compter les inconvénients potentiels.
La fonctionnalité adéquate est implémentée dans
LESS. Les solutions avancées (courantes) forment une sorte d’antithèse (elles produisent un aspect cosmétique). Maladroit, inélégant et superficiel. Néanmoins, cela est potentiellement plus efficace que de connaître tout un tas de choses.L’utilisateur effectue une recherche dans un fichier. On lance
less <nom du fichier>puis on saisit une expression régulière. La barre oblique/est une commande interne àlesspour lancer une recherche.manrepose surlesspar défaut.merci beaucoup
La sécurité est un sujet complexe, et pour ma part je ne suis aucunement surpris que des réseaux d’ordinateurs zombies continuent d’exister. C’est tellement facile de louper quelque chose…
Au cas ou je propose une piste pour limiter son exposition dans un 2e article : Cloudflare Tunnels
Voir à travers un prisme. Contraindre la pensée. Pour quelle finalité ? Des termes n’ayant aucun sens, donc inutiles (si l’on s’en fie à leur terme « crypter » sur chiffrer.info). Déplorable.
Pour moi flatpak a 3 avantages :
*Intégrateur/analyste/admin/what else hors Dev, c’est un Devops maintenant ^^, mais ceci est un autre débat
En voulant survoler l’administration système, je suis parti loin. À force, je m’approche (tourner autour) de la programmation système. Cela peut paraître bizarre dit comme cela. Donc, récemment, je faisais encore de l’auto-hébergement grâce à un RPi 2 avec YunoHost. Cela fonctionne mais j’ai quand même des inquiétudes. D’abord, mon site Web (blog) n’a pas les caractéristiques souhaitées. Le problème est que je dois avoir un bon modèle en fonction du contenu. Or, soit je ne connais ni l’un ni l’autre, ou alors, l’un ne va pas sans l’autre. Un système de gestion de contenu ne me convient pas, pour ainsi dire. Ensuite, faire les choses à moitié ça m’énerve. Prendre du temps ça devient lassant. Donc, j’essaye d’acquérir de nouvelles bases afin de me faire une représentation et redéfinir. C’est pas forcément terrible mais je fais comme je peux. Mon objectif c’est d’avoir une infrastructure gérée avec du code grâce à GNU Guix. Pour finir, par nécessité, il faut absolument que je renforce la sécurité : je n’ai aucune envie qu’on exploite mon matériel, qu’on me prenne des données (ou pire encore). Il faut aussi que je me forme en cybersécurité pour réagir dûment (avoir sa propre protection). Bref, j’ai commencé par les bases, et les choses finiront par se compléter (en rajoutant un peu de rétro-ingénierie pour s’assurer de la compatibilité de l’ensemble). Effectivement, à notre époque, je ne comprends pas pourquoi les réseaux d’ordinateurs zombies continuent d’exister.
Il y a aujourd’hui tellement de petits logiciels qu’il n’est plus possible pour les distributions de tout packager elle-même. Certains logiciels évoluent rapidement et c’est compliqué de les avoir à jour dans les distro (si déjà ils sont présents dans les dépôts car c’est pas forcément le cas).
En tant que développeur d’application, je vois un autre intérêt à Flatpak : je peux packager moi-même mon logiciel d’une manière compatible avec toutes les distributions. À une époque j’avais un PPA pour Ubuntu, des paquets AUR pour ArchLinux, quelques RPM (pas trop dans les règles de l’art) pour Fedora / Mageia, etc. Mais je n’ai plus le temps de m’occuper de tout ça.
Je suis d’accord pour les Flatpak, très pratique pour les logiciels propriétaires.
Le fait d’aller vers ce format est je pense la course à la nouvelle technologie. Si une nouvelle version d’un logiciel a besoin d’un Qt plus récent par exemple, il est pris directement via le framework disponible en flatpak et on peut s’affranchir d’une bibliothèque obsolète sur le système source. Je peux comprendre que certains restent sur une Debian stable par exemple tout en voulant des logiciels un poil plus récent qui corrigent parfois des bugs ou ajoutent des fonctionalités intéressantes. Dans le cas d’un LibreOffice sous Debian, il y a en effet les DEB du site tu me diras, mais s’il y a une bibliothèque pas assez récente sur le système, tu es coincé. Je privilégierais un Flatpak sur une base Debian au lieu d’un PPA ou dépôt tiers, qui causera, pour un logiciel, moins de soucis sur le long terme (car rappelons le, on n’installe pas son système toutes les semaines)
Flatpak c’est pas mal dans deux cas de figure. 1) Quand il faut installer des bousins propriétaires comme Teams, Skype, Zoom ou Spotify, et 2) Quand on a une appli avec des dépendances complexes et qu’on n’arrive plus à compiler une version récente sur sa distrib (comme Darktable > 4.0 sur une base RHEL 8.x par exemple). Ce qui est bien avec Flatpak, c’est que ça t’installe toute l’appli dans une sorte de bac à sable à part, ce qui peut être une base pratique pour isoler certaines applis potentiellement intrusives comme Skype.
Ceci étant dit, la tendance des distributions à aller de plus en plus vers ce format (ou vers Snap) pour leurs “App Stores” me paraît assez funeste. Faudrait rappeler aux mainteneurs des distributions la signification de “partagées” dans “bibliothèques partagées”.
Oups >.< j’ai fini par m’emmêler entre statique et dynamique. C’est corrigé, merci pour la remarque :)
Merci pour ton billet très intéressant. “Du coup, pas de contenu statique, pas besoin de suivre les comptes. “ -> pas de contenu dynamique tu voulais écrire non?
Nokia et son n9 a visé le grand public aussi. C était un excellent système mais la c’est Microsoft qui l’a flingué.
Si vous souhaitez un phone alternatif, mais plus grand public (j’ ai pas dit ouvert hein). Il reste Jolla Mobile avec son Sailfish OS.
Merci pour ton retour ! Alors je n’étais peut être pas assez clair dans mon introduction, mais mon ambition n’était sûrement pas de faire un état des lieux du champ des possibles sur le sujet, mais plus de partager mon approche personnelle, avec mes choix, par rapport à mes besoins.
J’ai le sentiment de par mon expérience que les debian-like sont plus populaires en termes de volume d’utilisateurs, et si j’en crois les estimations ce ressenti semble plutôt vraisemblable. Après, je ne compare en aucun cas la qualité ou les fonctionnalités de l’une ou l’autre des solutions, je ne connais pas suffisamment les *BSD pour juger. Mais je me met en todo de tester FreeBSD prochainement ;)
Pour résumer mon expérience, j’ai testé différentes choses (clairement pas toutes !) et je suis arrivé aujourd’hui à un fonctionnement qui me permet de facilement expérimenter de nouvelles choses, et de répondre à mes besoins long terme qui sont en effet d’héberger différents services. Je m’essaye à l’exercice de partager cette expérience, à la fois pour la faire connaître et également pour en débattre et collecter d’autres retours d’expérience qui peuvent me faire découvrir de nouvelles manières de faire. Donc en tout cas, merci d’avoir pris le temps de me lire et de me répondre ainsi !
Perso, je suis très calme et tiens à le rester ;)
Et, je n’irais pas plus loin dans la discussion.
Je sens que les esprits s’échauffent, je vous invite tous les deux à un dialogue dans le calme et le respect. Vous pouvez également échanger via les Messages privés du Jdh.
Tcho !
Merci d’utiliser le biais cognitif d’argument d’autorité ; vous vous rendez compte que vous vous décrédibiliser par vos propres soins ?!
Vous vous rendez compte que vous comparez des informations complètement hors de propos l’une de l’autre pour essayer d’asseoir votre argument ?!
Bref…