gUI a écrit 6008 commentaires

Ah oui, j'ai lu trop vite, je te confirme !

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Le prix annoncé semble être uniquement la valeur foncière et ne contient donc pas la valeur du mobilier

C'est surtout que on dirait qu'il n'y a pas l'immobilier !

Le foncier c'est le terrain, l'immobilier c'est la construction, le mobilier c'est les gadgets.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Lu sur le site :

What you get later, with the subscription

• Librem Files – pay-as-you-go end-to-end encrypted cloud storage
• Librem Backup – pay-as-you-go end-to-end encrypted long-term full cloud backups
• Librem Contacts – end-to-end encrypted contact sync and storage
• Librem Pay – cryptographic payments
• Librem Dial – pay-as-you-go phone service

Je me doute que ce sera toujours pour $8/mo. Au total l'offre est plutôt sympa je trouve.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Il y a environ 100% de chances que ce soit faux. Ils envoient des mails au hasard "j'ai hacké votre adresse email, j'ai tout, je sais tout sur vous" et ils attendent que des gogos payent.

Première chose à faire : changer le mot de passe de la messagerie en question. Si tu y arrives, alors c'est clair : tu n'as pas été hacké.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

C'est pas mon domaine, mais je sais que Redis est à la mode et en RAM.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

La plupart des compagnies de bus n'accepte pas de vendre des tickets si on n'a pas l'appoint. (Et ils en ont le droit : https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006072026&idArticle=LEGIARTI000006643951&dateTexte=20140731)

Je chipote, mais il me semblait qu'on ne peut pas refuser justement (argent qui a cours légal). Par contre en effet, ils peuvent très bien ne pas te rendre la monnaie, ce qui n'est pas tout à fait la même chose (tu prends ton bus au final, mais ça va te coûter 20€).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Mon père : pas de smartphone. Même pas de téléphone mobile d'ailleurs. Il s'en contre carre et ça l'emmerde. Par contre très à l'aise avec les ordis (emails, compte rendus d'assos…)
Ma mère : smartphone et tablette. Elle adore ça.
Mon beau-père : il tremble tellement que sa seule expérience avec un smarpthone (tactile) a duré 1h. Il est revenu au Nokia 3310 (ou dans le style) parce qu'il y a un clavier physique. Ensuite c'est un peu un handicapé technologique. Envoyer un email est une torture.
Ma belle-mère : 2 smartphones et 1 tablette (elle adore ça elle aussi).

Bref, ça fait du 50-50 qui pourrait utiliser cette appli sur mes stats perso. C'est pas ridicule, mais oui, il faudra bien faire cohabiter les 2 solutions pendant encore un moment.

Et d'ailleurs c'est marrant de constater que c'est les filles (oui, à 70 ans on dit encore une fille :) ) qui sont plus connectées que les garçons !

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Oui, une façon assez sympa de récupérer les données d'une page web c'est de laisser faire les pros :
lynx <url> --dump sort le rendu en texte brut, yapuka parser classiquement (awk, sed, grep…).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Clique sur ton pseudo, et sur la colonne de gauche, sous "rédaction", tu as une rubrique avec des infos sur ton compte, dont le karma.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

A vendre, compte créé le 13/08/2008, karma à plus de 5000, idéal SEO, indétectable par la patrouille.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

A lire la page Wikipedia, c'est autant un mouchard que tout le reste de ton smartphone Android : des services gratuits pour les développeurs dont on ne sait pas trop ce qu'en fait l'hébergeur, Alphabet en l'occurrence.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

NB : comment faire sur ce forum pour que # ne soit pas interpreté comme titre

Il faut que tu déclares du code : 3 backquotes seules sur une ligne, en début et en fin de ton listing. C'est pas très clair dans l'aide mémoire (en bas de la page d'édition), reprend l'exemple du code Ruby, mais sans mettre le mot 'ruby'

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Après tout, le port est finalement ouvert de même ?

A te lire, on a le sentiment que le port ouvert c'est le point faible de ta sécurité. Attention, il y a des nuances, et c'est là toute le cœur de la discussion entre Gérald d'une part et Bruno et moi d'autre part.

Ce qu'il faut bien comprendre, c'est que de base, ton kernel, il va dropper tous les messages. Tout ce qui entre va partir directement à la poubelle. En effet, le kernel n'implémente aucun service réseau (j'oublie ICMP pour les besoins de la démonstration - et peut-être autre chose ?), il n'est pas là pour ça. Donc pas besoin de "INPUT DROP", c'est ce qu'il fera de toutes façons.

Si un jour tu veux jouer avec Apache par exemple, tu vas lancer le programme Apache, et la première chose qu'il va faire c'est dire au kernel "bon, dès que t'as un truc sur le port 80, tu me l'envoies". Du coup, quand un message arrive sur le port 80, le kernel l'envoie au processus Apache (au lieu de le jeter).

Et attention, la faille potentielle, le trou de sécurité, la peur du petit malin, elle n'est pas dans le fait que le port 80 soit ouvert. La faille si elle existe, elle est dans Apache et nulle part ailleurs. Au moment où tu installes Apache, tu dois te dire "merde, j'ajoute un programme qui va traiter des messages venant de l'extérieur, je ne dois pas faire n'importe quoi". C'est ça LE réflexe de sécurité. Sur quel port j'écoute, et sur quelle interface j'écoute (ou quelle plage d'adresse j'autorise). Les règles de firewall qui se contentent d'ouvrir ou de fermer des ports ne te serviront à rien : en effet tu vas ouvrir le port 80 (sinon ça marche pas), et Apache les traitera, exactement comme si tu n'avais pas de règles du tout. Les règles dont vous parlez depuis le début de ce thread ne serviront en rien à mieux protéger ton ordinateur, même dans cette situation (un desktop avec qques serveurs bien définis comme SSH, Apache, MySQL etc.)

Des règles firewall intéressantes c'est par exemple ce qui te permet de bannir une IP qui tente un peu trop de se connecter à ton SSH (style fail2ban), ou qui limitent une attaque DDOS (des milliers de requêtes qui arrivent simultanément sur ton Apache pour tenter de mettre à plat ton serveur). Là oui, tu améliores la situation par rapport à si tu n'avais pas de firewall du tout. Là oui tu te protèges mieux.

Voilà donc le message c'est attention au faux sentiment de sécurité : "j'ai mis Apache, mais j'ai un firewall donc ça va". Si le firewall en question se contente de tout fermer sauf le port 80, en fait il ne t'aide pas spécialement, le kernel l'aurait fait tout seul.

Tu peux par exemple faire un simple netstat -l, qui va te lister tous les ports en écoute sur ta machine. Ça veut dire que derrière il y a un service prêt à répondre (et donc potentiellement une faille). Vérifie déjà que tu es d'accord avec cette liste et que tu as bien compris chaque service à quoi il sert. Une fois ceci fait tu peux dormir tranquille, même sans INPUT DROP :)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Tu vois en fond l'affichage précédent. Style tu lances un jeu, tu vois encore l'heure en haut à droite… puis quand tu quittes le jeu, tu vois sur ton écran d'accueil le menu du jeu en fond.

J'ai même longtemps cru que c'était un écran OLED (c'est un défaut reconnu des écrans OLED).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Ça fait 2 ans et demi que je l'ai (pour info payé 350€ neuf).

C'est globalement un bon choix vu tes critères.

• Réparabilité exemplaire : iFixit lui avait donné la meilleure note de l'année à sa sortie. Tout est démontable par vis, sauf le dogitilizer et l'écran qui sont collés (mais bon, à moins de 50€ la pièce complète, on va pas en faire une maladie)
• Batterie amovible : non seulement c'est l'assurance de pas être emmerdé dans le temps, mais en plus c'est hyper pratique au quotidien. Une 2e batterie dans ta poche (ça coûte 30€) et en cas de batterie faible, tu changes de batterie, reboot, et tu repars à 100% instantanément. Énormément plus pratique qu'une batterie de secours.
• C'est un haut de gamme, certes de 3 ans, mais ça reste très confortable aujourd'hui (merci les 4Go de RAM)

Par contre, je lui reproche sa fiabilité médiocre :

• l'écran marque avec le temps (mais je ne l'ai toujours pas changé, donc on supporte)
• j'ai eu des soucis de GPS, on m'a changé l'antenne sous garantie, mais je me demande si ça revient pas (à peu près 1 an après la réparation…)
• j'ai aussi fait changer sous garantie le bouton on/off dans le dos

Perso je suis resté encore en ROM officielle, mais maintenant que la garantie est passée, je vais sûrement passer sur LineageOS.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je voudrais déjà que ça change un peu ta façon de parler.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

C'est à cela que sert les lignes s'appuyant sur l'état ESTABLISHED

Faudrait savoir. Je croyais que iptables -P INPUT DROP était la seule règle nécessaire sur un desktop.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je reste admiratif devant tant d'aplomb, c'est tout.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Quel aplomb !

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Quel est l'objet de cette remarque ?

Tu dis que le firewall est la solution à ces problèmes, mais tu ne dis pas avec quelle règle.

Oui, c'est, de mon point de vue, la seule règle à mettre sur un firewall de desktop.

Si c'est pour dire ça, c'est pas iptables qu'il te faut, mais ifdown.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

C'était un exemple.

Bin oui mais c'est facile de prendre les gens de haut en donnant des exemples dans le vide. On égraine les autres exemples aussi ?

La seule règle de firewall que j'ai vu passer dans tes commentaires c'est iptables -P INPUT DROP.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Eviter qu'un petit malin exploite des failles avant que tu n'aies le temps de te mettre à jour (failles des clefs SSH faibles sur debian).

Excellent exemple ! Tu peux donner la règle qui protège de ça ? Que je la mette de suite sur mon bastion SSH.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Affirmer ce genre de chose avec tant d'aplomb est d'une stupidité rare …

Quel aplomb !

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

De ce que j'ai compris, mmap sert aux gros fichiers. En effet, avec mmap tu n'as pas de mise en mémoire du fichier, il n'y a pas de malloc gigantesque. C'est le kernel qui ira lire quand il le faut les données sur le disque (par page mémoire ?), mais toi tu te contentes de gérer "comme si" tout était mis en RAM.

Dans le cas de 256 octets que tu veux absolument mettre en RAM, aucune utilité, fais simplement un read, ne serait-ce que parce que c'est bcp plus lisible comme code.

A vérifier, je suis pas spécialiste, mais je n'ai vu mmap utilisé que sur des gros fichiers en tous cas.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Oui mais pour celui qui écrit cette bibliothèque, je pense que ce n'est pas une faille de sécurité, c'est juste un cas très particulier qui n'est pas bien géré : rien ne presse.

J'en veux un peu plus à celui qui a décidé que utiliser cette bibliothèque serait la première barrière de sécurité (sinon la seule ?), sans avoir sérieusement audité le code.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.