À part utiliser une CA déjà connue, pas d'autre choix que l'auto-signé.
Du coup, utiliser let's encrypt comme CA me semble faisable.
Dans tous les cas, il te faudra un nom de domaine internet, donc que le DHPC de ton LAN fournisse un DNSd qui connaisse ton serveur (dommage de passer par internet pour un accès du serveur LAN, pas vrai?).
Pour le challenge HTTP, il faut que la machine installe et fasse tourner le certbot en tant que root, ce qui peut poser problème. Il faut également, de mémoire, un httpd qui supporte les CGI, ainsi que python installé. Et, bien entendu, être joignable par le www… Si je ne m'abuse.
Perso, je regarderais plus les challenge DNS, pas d'install spécifique sur le serveur.
Notes aussi que je peux me tromper: j'ignore si le certificat vérifie la concordance de l'IP (ce qui ne me surprendrais pas). Si c'est le cas, peut-être via l'IPv6?
C'est, de toute façon, juste une piste.
Perso, je me ferais pas chier: un certificat auto-signé, une manip a faire par les utilisateurs et hop. Beaucoup plus simple ainsi. Au final, c'est même plus sûr que d'utiliser une CA, puisque ton certificat étant auto-signé, si un cert parent se fait voler/copier/whatever, tu ne sera pas affecté (ben oui: pas de cert parent. D'ailleurs, il me semble bien que ce genre de situations s'est déjà produites…) contrairement à un "vrai" certificat.
L'inconvénient, c'est que bien sûr l'auto-signé, ça scale pas, et ça demande aux utilisateurs de faire confiance au 1er usage.
Tout dépend du besoin réel en fait. D'ailleurs, pour "sniffer", il faudrait que le sniffeur, soit ait accès physique au switch ou aux câble qui relie celui-ci au serveur, soit accès au câble entre un client et le switch (pour espionner ce client-ci) soit passer par du wifi (et encore… dans le cas du wifi je ne sais pas s'il est trivial de déchiffrer les connexions des autres… et ça m'étonnerais qu'on le puisse avec tous les protocoles de chiffremment…).
Dans un hypothétique cas 100% filaire (câbles encastrés dans le mur, pas d'accès physique, etc), avec 0 logiciel malveillant installé sur la machine cliente, je pense même que le chiffrement n'apporte rien.
À noter que si le site a grepperWscrapper est sur le réseau local et que le scrap se produit par plusieurs systèmes, on peu utiliser cf-execd, composant de cfengine.
Celui-ci à l'intérêt de "randomiser" les exécutions pour éviter de s'auto DDoS.
Au moins 3 jours tous les 6 mois, juste pour monter la version… je t'avoues que la, ça semble raisonnable… tant qu'il n'y a qu'un seul projet, du moins.
J'ose espérer que cette maintenance corrige plus de bugs qu'elle n'en ajoute?
Ah, désolé, je suis en retard, c'était hier vendredi :)
En fait, la vraie question, c'est pas "combien de jours de maintenance tous les combien de mois", parce que ça, ça ne parle pas tant que ça.
Il faudrait en fait ajouter le temps nécessaire pour accomplir la tâche initiale, parce que ça permettrait d'avoir une estimation du coût de maintenance du projet, sur le long terme.
Si le coût de maintenance est trop élevé, ce qui ne me surprendrai vraiment pas, il est alors logique de jeter à la poubelle son site tous les 2 ans.
Quand un logiciel plus «traditionnel» fait ça, le comportement des utilisateurs est tout sauf tendre: gnome a reçu pas mal de reproches à cause de ça, il me semble.
Entre un robot et un rapporteur de bug hypothétique qui préférerait une forge logicielle à un courriel
Je me permets d'ailleurs de vous remémorer l'épisode ou une entreprise à encouragé le spam de rapports de bugs. Je n'arrive pas a retrouver le truc complet (en moins de 60s) mais je trouve d'autres résultats amusants (non-lus, je me base sur l'en-cart du moteur de recherche):
Ou sur https://savannah.nongnu.org/ ? Je vais être honnête, le logiciel derrière est à la ramasse, mais au moins ils ont franchi du temps, et toi, tu dis juste qu'il faudrait qu'il héberge son code sur une plate-forme centralisée avec d'autres, de ce que j'ai compris?
Pour rappel, cette instance est plus vieille que les deux instance sus-citées. Je me souviens également de gna.org, aujourd'hui décédé.
Du coup, ne serait-ce pas un manque de respect d'avoir été sur github dans un premier temps? Double, puisque d'une part on force à utiliser un soft proprio, hébergé par une entreprise fournissant un produit gratuit (ce qui augmente drastiquement la suspicion de l'usage des données, mais on pourrait arguer à juste titre que ce point est valable pour toute association de personnes)?
Serait-ce également un «manque de respect»?
D'ailleurs, est-ce vraiment un manque de respect de donner gratuitement son travail?
N'est-ce pas, au contraire, un manque de respect d'attendre de quelqu'un qu'il se connecte sur FooBar.example.com pour partager son travail?
Par exemple, github (qui refusent la connexion tant que vous n'avez pas récupéré un code dans un mail qu'ils vous envoient… oui, c'est nouveau, 3-4 mois, oui, ça m'est arrivé plus d'une fois, et oui, ça me casse sévère les couilles!) ou sur gitlab, dont une partie du code est propriétaire me semble (à moins qu'ils utilisent la version communautaire? Vraie question pour le coup).
Dans la même veine, mais ici c'était pour vérifier que l'utilisateur avais bien le manuel (et donc acheté le jeu), settlers demandait de reproduire le code (en cliquant sur 3 images) se trouvant à la page N du manuel.
Je pense avoir déjà vu cette méthode ailleurs, genre "donner les 3 premiers mots de la 2ème phrase de telle page".
Car il faut compiler chaque dépendance statiquement, et chaque dépendance de chaque dépendance, etc… C'est énormément de travail sur des grosses libs genre Qt !
On est bien d'accords, malheureusement.
heureusement, on a inventé les makefile pour lister les dépendances, les compiler une seule fois,
Tu connais beaucoup de gros projets dont le makefile n'est pas généré? Linux, peut-être, mais j'imagine qu'il ne link pas dynamique, de fait :)
Au-dela de ça, maintenir un makefile est assez difficile pour que les devs d'i3, notamment, soient passés aux autotools, puis (à en lire les commits) à meson.
Écrire son makefile est une plaie, vraiment. D'ailleurs, makefile pour quelle variante? Celle de GNU? De BSD? Un autre? Variante de quelle version?
Je préfère de loin écrire moi-même un ninja, c'est du même niveau, mais au moins je sais qu'il n'existe qu'une seule version, le fichier peut décrire pour quelle version il est censé fonctionner, et, d'ailleurs, ninja, contrairement à make (à ma connaissance), peut deviner de quels headers un .c ou .cpp à besoin, et ça, ça change la vie.
Il est aussi possible de gérer facilement quand une règle à plusieurs entrées et plusieurs sorties (utilisation de compilateurs de compilateurs (non, pas une faute de frappe)) ce que j'ai été incapable de faire proprement avec GNU make quand je me suis mis à coco-cppp.
Et puis, tout ça ne change pas le problème. Les outils en C et C++ sont, à ma connaissance, mauvais pour gérer l'ordonnancement des dépendances, et les link pètent tout le temps, avec des erreurs tout sauf compréhensibles (comment ça le symbole est pas présent? Le fichier contiens le symbole, est bien listé… ah putain il faut le décaler d'un cran dans la ligne de commande!!!).
Un jour, peut-être, je testerais mk de plan9… il paraît qu'il est intéressant, mais j'avoue que pour l'instant j'aime bien ninja (même si je devrais pas écrire mes ninja à la main…).
Dans quelle mesure? Est-ce significatif par rapport au système?
Si je prend, par exemple, busybox de debian, le binaire statique pèse 1.9 megs.
Celui de la version dynamique pèse ~700 kilos.
Si j'ajoute le poids des libs:
/lib/x86_64-linux-gnu/libresolv-2.28.s 91K
/lib/x86_64-linux-gnu/ld-2.28.so 162K
/lib/x86_64-linux-gnu/libc-2.28.so 1.8M
Comme tu peux le voir, oui, dans le cas de la gblic ça va être pertinent, parce qu'elle est utilisée par l'ensemble du système. D'ailleurs, la plupart des appimage n'embarqueront pas de libc.
Par contre pour des libs peu usitées, je ne suis pas certain que ça soit si rentable que ça.
Donc, plus gros, oui, mais ou? Sur le disque ou en mémoire? Lequel est le plus important?
et surtout en cas de faille de sécurité sur une lib (au hasard la libc), il faut recompiler tout le système
Non, juste relinker.
A ma connaissance, il n'existe que des distros qui filent soit les sources, soit les binaires finaux. Rien n'empêcherais en théorie une distro de filer les objets, et de juste faire le link à l'install.
Bien sûr, ça me semble très compliqué à réaliser, mais au niveau perfs, ça permettrait justement de ne link dynamique qu'a partir d'un certain nombre d'utilisations, voire en fonction de la fréquence d'usage.
Et question sécurité, pour le coup, l'avantage du link statique, c'est qu'on ne peux pas injecter de code avec un simple "export LD_PRELOAD=foobar" (ce qui est pratique pour le debug!).
De même, le bug de ta lib ne sera pas forcément dans tous les binaires, justement, contrairement au link dynamique.
D'ailleurs, le link statique est, il me semble, le chemin pris par go et rust, qui ont le vent en poupe ces derniers temps.
Bref, je pense que les deux approches sont valides, chacune brille a son niveau.
Les arguments que tu cites, même valides, ne sont que partiels (poids? En ram le static bouffe moins. Sécurité? Plus compliqué d'injecter du code, surface d'attaque réduite).
Il serait possible de mettre un capteur à l'extérieur aussi, et donc de faire le comparatif (par l'électronique, j'entend)?
Cette logique est de toute façon valable dès lors que l'on cherche à savoir s'il faut faire circuler un flux entre 2 zones pour améliorer la qualité de l'une (au détriment de l'autre): si on ne s'assure pas que la zone avec laquelle on échange est mieux, on risque évidemment de réduire la qualité de la «zone utile».
Enfin, forcément, ça ne serait pas beaucoup mieux puisque la pollution, ce n'est pas nécessairement du CO2, de même que le CO2 n'a rien à voir avec le taux .
Ce que je voulais dire, c'est que la grande majorité de l'ecosysteme du C, du C++, me semble (oui, je mets de l'eau dans mon vin) oublier que le lien statique existe. On ne se pose quasi plus la question: le dynamique à plus de possibilités, donc autant l'utiliser.
Moi, j'ai un peu de mal avec ça,même si je sais que parfois c'est nécessaire, je pense que pour la majorité des applications que, moi, j'ai, ce serait plus efficace sur la perf et ferai utiliser du matos plus vieux.
D'accord, donc tu mets des mots ensemble sans comprendre que le rendu final peut être insultant? Mince, je t'avais surestimé. Désolé. Je recommencerais pas.
Pas vraiment, c'est beaucoup moins évolué. AppImage, c'est simplement une image disque (nécessite fuse) qui contiens, comme tu l'indiques ensuite, d'une part le binaire, et d'autre part une partie des ressources dont le binaire à besoin, ce qui implique généralement une partie des bibliothèques partagées.
Bon, c'est plus qu'une image disque, puisque ça s'exécute, donc il y a une sorte de "bootloader", qui va également indiquer ou sont les libs à l'intérieur (on ne peux pas compter sur le ld de la distrib pour ça, l'organisation est probablement différente entre le côté "natif" et le côté "embarqué").
Autre point de différence par rapport à docker: pas de gestion de namespace, de cgroups et autres, sauf si c'est fait par l'appimage elle-même (peu probable), c'est donc "moins sécurisé". D'un autre côté, c'est aussi nettement plus simple techniquement et portable, ce qui a des avantages non-négligeables.
Le logiciel de ta distribution, lui pourra utiliser les bibliothèques prechargées par un autre logiciel si c'est le cas, sinon devra aussi charger les bibliothques nécessaires.
C'est valable également pour une partie des libs de l'appimage, celle-ci se reposant partiellement sur le système.
C'est d'ailleurs un point que j'ai tendance a reprocher tout en connaissant une partie de la réponse: pourquoi ne pas juste lier statiquement les libs partagées? Ça mènerait à une amélioration des performances après tout. Bon, la réponse, c'set que les écosystèmes C et C++ sont tellement partis dans le délire du link dynamique depuis tellement longtemps que lier en statique est bien souvent méga pénible et expose a des tonnes d'emmerdes.
Pour ce qui est de la performance, on pourrait avoir de meilleurs performances avec une appimage comparé à une installation système, sur un disque dur mécanique, du au fait que les données de l'appimage seront plus groupée, donc moins de déplacement de la tête de lecture.
Plus trop d'actualité, et l'impact est assez mineur (appimage sert surtout pour des applications de bureau à ma connaissance). Le reste, le travail de ld, ben… ça c'est totalement aléatoire: si le dev à lié en statique le binaire dans l'appimage (pourquoi pas, après tout? ça permets d'avoir les données à côté et le fichier est simple a "installer" et exécuter: chmod +x $foo && ./$foo) alors il y a fort à parier que les performances soient plus élevée. Mais la distro aussi pourrait lier en statique.
Il y a aussi, bien sûr, de nombreux autres facteurs: options de compilation, compilateur utilisé, différence de version des libs chargées par l'un ou l'autre… tout peut impacter la performance, donc on peut pas chiffre.
ça c'est la faute du BIOS, non ? C'est à lui de gérer les claviers dans ce mode.
Pas que.
De l'UEFI, de grub, de lilo, de syslinux, aussi. Et de l'USB, potentiellement, ou du clavier même?
En fait, comme toi, je sais pas, je sais pas a quoi ressemble le code derrière, je sais juste que c'est aléatoire selon le clavier, la machine et la pile logicielle.
Je ne doute pas beaucoup que PS/2 notamment est plus simple technologiquement, même si je n'ai pas de preuve ni de certitude (déjà, point de hub, mais du point à point?)
C'est beau, la théorie. Dans la pratique, on va te dire que le matos marche, alors que les composteurs sont souvent aléatoirement en panne, et quand ils marchent il faut retourner le billet dans les 20 sens différents… Oui, 20 sens différents, pour un billet qui n'en a que 4.
Et tu crois qu'il se passe quoi, si je refuse de filer date de naissance, numéro de téléphone, et autres info douteuses aux automates de la gare du Havre qui ne te laissent pas prendre connaissance de tes droits, quand tu vas causer avec le contrôleur? Lui il en a rien foutre, de ta vie privée et de tes droits, il veut juste passer en speed dans le train prendre son café. Sinon, il passerait aussi quand le train est bondé à cause du train précédent annulé…
Ok on a des sites plein de JS qui mettent plusieurs secondes à charger mais c’est à comparer à avant où la moindre page quasi vide se chargeait en plus de temps que ça.
Avant, le délai était énormément lié au temps de transfert. Forcément, avec une liaison 56K… mais ça, c'est lié au réseau.
De nos jours, les sites sont lents, mais il arrive souvent que le problème soit le CPU, et ça, ben, c'est lié au site.
C’est la même chose côté compatibilité.
Ok aujourd’hui on a parfois des choses qui ne passent qu’avec Chrome mais avant c’était tout le web qui était dans une guerre de tranchée.
Ouai. Aujourd'hui, c'est apple vs google vs mozilla, principalement.
Avant, c'était microsoft vs netscape (mozilla).
Ah… oups en fait?
Aujourd’hui je ne me pose quasiment plus la question du navigateur. Je sais que ça va fonctionner.
Chez moi ça marche (tm). Ben chez moi ça marche pas, marque de merde! Certains sites marchent sous FF, d'autres sous chrome, la plupart sur les deux.
Ce n’était pas non plus plus utilisable.
Les exemples mis en avant sont valides, pour le coup. Mais j'ai quand même un contre-exemple: ouvrir un lien dans un nouvel onglet. Plus possible: le lien, c'est du JS.
On s’est amélioré sur tous les points, sans exception. Le pire d’aujourd’hui est objectivement souvent meilleur que le meilleur de l’époque.
hum… pour de simples sites web, sans vidéo, on est obligés de migrer l'infra vers la fibre ou la 5g, a cause de l'abus d'images (bien souvent qui n'apportent strictement rien).
Ce n'est pas un progrès. Ce n'est, certes, pas lié au web en soit, mais à son usage par les développeurs…
En fait une partie des applications web
Je crois que le problème, il est la. Ici. Sur le mot applications. On a voulu faire du web un système d'exploitation, littéralement. Je doute fort que ça soit adapté par exemple aux blogs.
L'accumulation de technos et autres hacks fait qu'il est impossible d'écrire un client propre et 100% fonctionnel (dillo, netsurf essaient, mais rien que les CSS cassent de partout, JS n'est pas supporté) alors que le web se voulait décentralisé (hyper-liens) on se retrouve avec une poignée de moteurs de rendu développés de façon hyper centralisée.
Les développeurs de site, eux, utilisent la plupart du temps des frameworks pour masquer le bordel et les problèmes de compat, ce qui ne risque pas de rendre la chose plus légère…
C’est juste que les compromis et les équilibres ne pointent pas si souvent que ça dans cette direction.
Bien d'accord. Et c'est peut-être un des problèmes, justement.
Prétendre faire un nouveau web qui forcerait ce choix ne serait pas une avancée, ce serait une forte régression.
Non. Ce serait une avancée.
Parce que le «nouveau web» serait spécialisé et meilleur dans son domaine. Tout comme le web actuel est spécialisé dans les applications interactives, rendant la création d'un blog sous-optimale. Le web d'avant permettait à un ado de faire son propre site web en 3 coups de cuillères à pot.
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).
Ce n'est pas si surprenant… personnellement, je ne pense pas que «les développeurs web» en aient quoique ce soit à cirer du côté système ou de la maintenance. On parle du web la, la pile de technologies qui:
est si mouvante que même Debian met à jour Firefox tous les 3 mois (ou un truc du genre) rompant de ce fait la promesse d'un système stable.
est si complexe que seuls 3 groupes, dont 2 ont une base de code ayant la même origine, sont encore capables de développer un moteur de rendu «standard»
pour être moderne se doit d'utiliser JS pour un stupide lien de type ancre (dans la même page). En fait, pour n'importe quel type de lien… exécuter du script au lieu d'utiliser le mécanisme standard, parce que seul le web mérite d'utiliser les ressources systèmes!
Ça pourrait aussi être, tout simplement, du thrashing.
Pas simple de diagnostiquer ça sans avoir un outil de monitoring qui tourne constamment… perso j'utilise xosview, mais je ne doute pas qu'il en existe une chiée.
Avec un disque dur mécanique, on peut aussi utiliser… ses oreilles :) mais bon, de nos jours c'est plus trop d'actualité.
Bref, en gros, si quelques applis ont des fuites mémoire, ça peut vite pousser au thrashing, et la, reboot obligé (parce que l'oom-killer du kernel fait très, très mal son job de ce côté).
Pour contrer ça, j'ai appris récemment l'existence d'un outil nommé earlyoom, un oomkiller qui interviens avant le kernel, et surtout, avant que tout parte en couilles. Je ne sais pas ce qu'il vaut par contre, perso je me contente de désactiver l'overcommit (mais je connais les symptômes et je sais désactiver, je ne conseille pas de l'utiliser sans un minimum de connaissances système).
Je ne suis pas entièrement d'accord… je pense que certains comprennent. Notamment ceux qui ont acquis les bases avant d'apprendre l'info à l'école.
Je dis ça, parce qu'une phrase bien précise m'a braqué contre mes profs lors de mon BTS IRIS: "le client rachètera de la RAM".
IRIS, ça voulait dire: Informatique et Réseaux pour l'Industrie et les Services techniques hein, donc la perf et le vieux hard auraient du être omniprésents dans le principe au moins… c'était en 2000 et des bananes, C99 était déjà sorti depuis plusieurs années, et on nous enseignait encore int au lieu de int32_t: ben oui, on peut racheter de la ram, ça coûte moins chez qu'une minute d'un dev (sauf que c'est pas juste la ram, mais aussi la sram, sans parler des problèmes de compat entre les archis…).
Bon, en vrai, je les avais déjà grillés… 1er mois de cours, le prof avait sorti un truc genre "la solution opti, c'est if( foo == true ){ ... } else if( foo == false ) { ... }"… et quand j'ai pointé du doigt le problème (supposé, parce que le compilo… mais bref) "mais on s'en fout" fut la réponse (et non pas un argument logique type: le compilo optimise).
J'étais très (et je suis encore) content d'avoir commencé l'apprentissage du code comme un sauvage, 3-4 avant les «études supérieures»…
Je ne sais pas, cependant, s'il est aussi facile de trouver des ressources de qualité sur le net pour apprendre à coder… à l'époque (ou j'ai commencé), google était petit, les livres d'or courants, et le multi-coeur ou linux inconnus du grand public (moi-même ai appris au sujet du LL plus d'un an après avoir appris les bases du code)
Posté par freem .
En réponse au journal Assembleur de PC en France.
Évalué à 3.
Dernière modification le 30 janvier 2021 à 03:24.
Ah ça … les ptits jeunes savent pas la chance qu'ils ont avec :
les claviers USB
Sauf que les claviers USB marchent pas si bien avec le noyal dont le nom de ce site est tiré… je me retrouve de temps en temps, via cette blagueuse de debian, a être sous initramfs (ouai, je bricole mon boot parfois, quand je toupine) et la… ha ben non, le clavier usb, il marche pas…
Je n'avais pas les compétences à l'époque pour juger, mais les claviers PS/2 ou 232 qui marchent pas pour aller au "mode sans échec" ou autres joyeusetés du même des goût, j'ai pas souvenir.
# certbot + challenge DNS?
Posté par freem . En réponse au message HTTPS sur réseau local. Évalué à 4.
À part utiliser une CA déjà connue, pas d'autre choix que l'auto-signé.
Du coup, utiliser let's encrypt comme CA me semble faisable.
Dans tous les cas, il te faudra un nom de domaine internet, donc que le DHPC de ton LAN fournisse un DNSd qui connaisse ton serveur (dommage de passer par internet pour un accès du serveur LAN, pas vrai?).
Pour le challenge HTTP, il faut que la machine installe et fasse tourner le certbot en tant que root, ce qui peut poser problème. Il faut également, de mémoire, un httpd qui supporte les CGI, ainsi que python installé. Et, bien entendu, être joignable par le www… Si je ne m'abuse.
Perso, je regarderais plus les challenge DNS, pas d'install spécifique sur le serveur.
Notes aussi que je peux me tromper: j'ignore si le certificat vérifie la concordance de l'IP (ce qui ne me surprendrais pas). Si c'est le cas, peut-être via l'IPv6?
C'est, de toute façon, juste une piste.
Perso, je me ferais pas chier: un certificat auto-signé, une manip a faire par les utilisateurs et hop. Beaucoup plus simple ainsi. Au final, c'est même plus sûr que d'utiliser une CA, puisque ton certificat étant auto-signé, si un cert parent se fait voler/copier/whatever, tu ne sera pas affecté (ben oui: pas de cert parent. D'ailleurs, il me semble bien que ce genre de situations s'est déjà produites…) contrairement à un "vrai" certificat.
L'inconvénient, c'est que bien sûr l'auto-signé, ça scale pas, et ça demande aux utilisateurs de faire confiance au 1er usage.
Tout dépend du besoin réel en fait. D'ailleurs, pour "sniffer", il faudrait que le sniffeur, soit ait accès physique au switch ou aux câble qui relie celui-ci au serveur, soit accès au câble entre un client et le switch (pour espionner ce client-ci) soit passer par du wifi (et encore… dans le cas du wifi je ne sais pas s'il est trivial de déchiffrer les connexions des autres… et ça m'étonnerais qu'on le puisse avec tous les protocoles de chiffremment…).
Dans un hypothétique cas 100% filaire (câbles encastrés dans le mur, pas d'accès physique, etc), avec 0 logiciel malveillant installé sur la machine cliente, je pense même que le chiffrement n'apporte rien.
[^] # Re: Comment faire un robot de web scraping en 1 min avec bash
Posté par freem . En réponse au lien Créer un Robot 🤖 de Web Scraping 🕸️ en 2 minutes avec Node-Red 🟥. Évalué à 2.
À noter que si le site a grepperWscrapper est sur le réseau local et que le scrap se produit par plusieurs systèmes, on peu utiliser cf-execd, composant de cfengine.
Celui-ci à l'intérêt de "randomiser" les exécutions pour éviter de s'auto DDoS.
[^] # Re: Follow-up
Posté par freem . En réponse au journal Gitea contre les bots. Évalué à 3.
Ou tout simplement la connexion qui lâche à ce moment la, et donc impossible de récup le mail, tu passes à autre chose, donc tu remets au lendemain…
3 jours, c'est bien, ça laisse un weekend passer.
[^] # Re: Crée les comptes manuellement
Posté par freem . En réponse au journal Gitea contre les bots. Évalué à 3.
Oui, voila, eux. Merci.
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par freem . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 2.
Au moins 3 jours tous les 6 mois, juste pour monter la version… je t'avoues que la, ça semble raisonnable… tant qu'il n'y a qu'un seul projet, du moins.
J'ose espérer que cette maintenance corrige plus de bugs qu'elle n'en ajoute?
Ah, désolé, je suis en retard, c'était hier vendredi :)
En fait, la vraie question, c'est pas "combien de jours de maintenance tous les combien de mois", parce que ça, ça ne parle pas tant que ça.
Il faudrait en fait ajouter le temps nécessaire pour accomplir la tâche initiale, parce que ça permettrait d'avoir une estimation du coût de maintenance du projet, sur le long terme.
Si le coût de maintenance est trop élevé, ce qui ne me surprendrai vraiment pas, il est alors logique de jeter à la poubelle son site tous les 2 ans.
Quand un logiciel plus «traditionnel» fait ça, le comportement des utilisateurs est tout sauf tendre: gnome a reçu pas mal de reproches à cause de ça, il me semble.
[^] # Re: Crée les comptes manuellement
Posté par freem . En réponse au journal Gitea contre les bots. Évalué à 3.
Je me permets d'ailleurs de vous remémorer l'épisode ou une entreprise à encouragé le spam de rapports de bugs. Je n'arrive pas a retrouver le truc complet (en moins de 60s) mais je trouve d'autres résultats amusants (non-lus, je me base sur l'en-cart du moteur de recherche):
[^] # Re: Une phrase importante
Posté par freem . En réponse au journal Gitea contre les bots. Évalué à 7.
Ou sur https://savannah.nongnu.org/ ? Je vais être honnête, le logiciel derrière est à la ramasse, mais au moins ils ont franchi du temps, et toi, tu dis juste qu'il faudrait qu'il héberge son code sur une plate-forme centralisée avec d'autres, de ce que j'ai compris?
Pour rappel, cette instance est plus vieille que les deux instance sus-citées. Je me souviens également de gna.org, aujourd'hui décédé.
Du coup, ne serait-ce pas un manque de respect d'avoir été sur github dans un premier temps? Double, puisque d'une part on force à utiliser un soft proprio, hébergé par une entreprise fournissant un produit gratuit (ce qui augmente drastiquement la suspicion de l'usage des données, mais on pourrait arguer à juste titre que ce point est valable pour toute association de personnes)?
Serait-ce également un «manque de respect»?
D'ailleurs, est-ce vraiment un manque de respect de donner gratuitement son travail?
N'est-ce pas, au contraire, un manque de respect d'attendre de quelqu'un qu'il se connecte sur FooBar.example.com pour partager son travail?
Par exemple, github (qui refusent la connexion tant que vous n'avez pas récupéré un code dans un mail qu'ils vous envoient… oui, c'est nouveau, 3-4 mois, oui, ça m'est arrivé plus d'une fois, et oui, ça me casse sévère les couilles!) ou sur gitlab, dont une partie du code est propriétaire me semble (à moins qu'ils utilisent la version communautaire? Vraie question pour le coup).
[^] # Re: Par mail
Posté par freem . En réponse au journal Gitea contre les bots. Évalué à 4.
Dans la même veine, mais ici c'était pour vérifier que l'utilisateur avais bien le manuel (et donc acheté le jeu), settlers demandait de reproduire le code (en cliquant sur 3 images) se trouvant à la page N du manuel.
Je pense avoir déjà vu cette méthode ailleurs, genre "donner les 3 premiers mots de la 2ème phrase de telle page".
[^] # Re: delicat à chiffrer
Posté par freem . En réponse au message Différence entre une application AppImage et une application installée. Évalué à 2.
On est bien d'accords, malheureusement.
Tu connais beaucoup de gros projets dont le makefile n'est pas généré? Linux, peut-être, mais j'imagine qu'il ne link pas dynamique, de fait :)
Au-dela de ça, maintenir un makefile est assez difficile pour que les devs d'i3, notamment, soient passés aux autotools, puis (à en lire les commits) à meson.
Écrire son makefile est une plaie, vraiment. D'ailleurs, makefile pour quelle variante? Celle de GNU? De BSD? Un autre? Variante de quelle version?
Je préfère de loin écrire moi-même un ninja, c'est du même niveau, mais au moins je sais qu'il n'existe qu'une seule version, le fichier peut décrire pour quelle version il est censé fonctionner, et, d'ailleurs, ninja, contrairement à make (à ma connaissance), peut deviner de quels headers un .c ou .cpp à besoin, et ça, ça change la vie.
Il est aussi possible de gérer facilement quand une règle à plusieurs entrées et plusieurs sorties (utilisation de compilateurs de compilateurs (non, pas une faute de frappe)) ce que j'ai été incapable de faire proprement avec GNU make quand je me suis mis à coco-cppp.
Et puis, tout ça ne change pas le problème. Les outils en C et C++ sont, à ma connaissance, mauvais pour gérer l'ordonnancement des dépendances, et les link pètent tout le temps, avec des erreurs tout sauf compréhensibles (comment ça le symbole est pas présent? Le fichier contiens le symbole, est bien listé… ah putain il faut le décaler d'un cran dans la ligne de commande!!!).
Un jour, peut-être, je testerais mk de plan9… il paraît qu'il est intéressant, mais j'avoue que pour l'instant j'aime bien ninja (même si je devrais pas écrire mes ninja à la main…).
[^] # Re: delicat à chiffrer
Posté par freem . En réponse au message Différence entre une application AppImage et une application installée. Évalué à 2. Dernière modification le 10 février 2021 à 03:33.
Dans quelle mesure? Est-ce significatif par rapport au système?
Si je prend, par exemple, busybox de debian, le binaire statique pèse 1.9 megs.
Celui de la version dynamique pèse ~700 kilos.
Si j'ajoute le poids des libs:
Comme tu peux le voir, oui, dans le cas de la gblic ça va être pertinent, parce qu'elle est utilisée par l'ensemble du système. D'ailleurs, la plupart des appimage n'embarqueront pas de libc.
Par contre pour des libs peu usitées, je ne suis pas certain que ça soit si rentable que ça.
La conso de mémoire, par contre: dynamique:
Statique:
% ps -orss,vsz,args $(pidof busybox )
RSS VSZ COMMAND
4 2212 busybox sh
Donc, plus gros, oui, mais ou? Sur le disque ou en mémoire? Lequel est le plus important?
Non, juste relinker.
A ma connaissance, il n'existe que des distros qui filent soit les sources, soit les binaires finaux. Rien n'empêcherais en théorie une distro de filer les objets, et de juste faire le link à l'install.
Bien sûr, ça me semble très compliqué à réaliser, mais au niveau perfs, ça permettrait justement de ne link dynamique qu'a partir d'un certain nombre d'utilisations, voire en fonction de la fréquence d'usage.
Et question sécurité, pour le coup, l'avantage du link statique, c'est qu'on ne peux pas injecter de code avec un simple "export LD_PRELOAD=foobar" (ce qui est pratique pour le debug!).
De même, le bug de ta lib ne sera pas forcément dans tous les binaires, justement, contrairement au link dynamique.
D'ailleurs, le link statique est, il me semble, le chemin pris par go et rust, qui ont le vent en poupe ces derniers temps.
Bref, je pense que les deux approches sont valides, chacune brille a son niveau.
Les arguments que tu cites, même valides, ne sont que partiels (poids? En ram le static bouffe moins. Sécurité? Plus compliqué d'injecter du code, surface d'attaque réduite).
[^] # Re: Bonne idée ou fausse bonne idée ?
Posté par freem . En réponse au lien Fabrication détecteur CO2 (pour voir s'il faut aérer vs Covid19). Évalué à 2.
Il serait possible de mettre un capteur à l'extérieur aussi, et donc de faire le comparatif (par l'électronique, j'entend)?
Cette logique est de toute façon valable dès lors que l'on cherche à savoir s'il faut faire circuler un flux entre 2 zones pour améliorer la qualité de l'une (au détriment de l'autre): si on ne s'assure pas que la zone avec laquelle on échange est mieux, on risque évidemment de réduire la qualité de la «zone utile».
Enfin, forcément, ça ne serait pas beaucoup mieux puisque la pollution, ce n'est pas nécessairement du CO2, de même que le CO2 n'a rien à voir avec le taux .
[^] # Re: delicat à chiffrer
Posté par freem . En réponse au message Différence entre une application AppImage et une application installée. Évalué à 4.
Bonne remarque.
Ce que je voulais dire, c'est que la grande majorité de l'ecosysteme du C, du C++, me semble (oui, je mets de l'eau dans mon vin) oublier que le lien statique existe. On ne se pose quasi plus la question: le dynamique à plus de possibilités, donc autant l'utiliser.
Moi, j'ai un peu de mal avec ça,même si je sais que parfois c'est nécessaire, je pense que pour la majorité des applications que, moi, j'ai, ce serait plus efficace sur la perf et ferai utiliser du matos plus vieux.
Note: l'heure. Desolé :)
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par freem . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 3.
D'accord, donc tu mets des mots ensemble sans comprendre que le rendu final peut être insultant? Mince, je t'avais surestimé. Désolé. Je recommencerais pas.
[^] # Re: delicat à chiffrer
Posté par freem . En réponse au message Différence entre une application AppImage et une application installée. Évalué à 6.
Pas vraiment, c'est beaucoup moins évolué. AppImage, c'est simplement une image disque (nécessite fuse) qui contiens, comme tu l'indiques ensuite, d'une part le binaire, et d'autre part une partie des ressources dont le binaire à besoin, ce qui implique généralement une partie des bibliothèques partagées.
Bon, c'est plus qu'une image disque, puisque ça s'exécute, donc il y a une sorte de "bootloader", qui va également indiquer ou sont les libs à l'intérieur (on ne peux pas compter sur le ld de la distrib pour ça, l'organisation est probablement différente entre le côté "natif" et le côté "embarqué").
Autre point de différence par rapport à docker: pas de gestion de namespace, de cgroups et autres, sauf si c'est fait par l'appimage elle-même (peu probable), c'est donc "moins sécurisé". D'un autre côté, c'est aussi nettement plus simple techniquement et portable, ce qui a des avantages non-négligeables.
C'est valable également pour une partie des libs de l'appimage, celle-ci se reposant partiellement sur le système.
C'est d'ailleurs un point que j'ai tendance a reprocher tout en connaissant une partie de la réponse: pourquoi ne pas juste lier statiquement les libs partagées? Ça mènerait à une amélioration des performances après tout. Bon, la réponse, c'set que les écosystèmes C et C++ sont tellement partis dans le délire du link dynamique depuis tellement longtemps que lier en statique est bien souvent méga pénible et expose a des tonnes d'emmerdes.
Pour ce qui est de la performance, on pourrait avoir de meilleurs performances avec une appimage comparé à une installation système, sur un disque dur mécanique, du au fait que les données de l'appimage seront plus groupée, donc moins de déplacement de la tête de lecture.
Plus trop d'actualité, et l'impact est assez mineur (appimage sert surtout pour des applications de bureau à ma connaissance). Le reste, le travail de
ld, ben… ça c'est totalement aléatoire: si le dev à lié en statique le binaire dans l'appimage (pourquoi pas, après tout? ça permets d'avoir les données à côté et le fichier est simple a "installer" et exécuter:chmod +x $foo && ./$foo) alors il y a fort à parier que les performances soient plus élevée. Mais la distro aussi pourrait lier en statique.Il y a aussi, bien sûr, de nombreux autres facteurs: options de compilation, compilateur utilisé, différence de version des libs chargées par l'un ou l'autre… tout peut impacter la performance, donc on peut pas chiffre.
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par freem . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 4.
Tu devrais apprendre à lire, et à réfléchir avant d'essayer d'insulter.
[^] # Re: Du coté Serveur / Station haute performance ...
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 2.
Pas que.
De l'UEFI, de grub, de lilo, de syslinux, aussi. Et de l'USB, potentiellement, ou du clavier même?
En fait, comme toi, je sais pas, je sais pas a quoi ressemble le code derrière, je sais juste que c'est aléatoire selon le clavier, la machine et la pile logicielle.
Je ne doute pas beaucoup que PS/2 notamment est plus simple technologiquement, même si je n'ai pas de preuve ni de certitude (déjà, point de hub, mais du point à point?)
[^] # Re: Prendre des preuves que le billet n'est pas en vente
Posté par freem . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 3.
C'est beau, la théorie. Dans la pratique, on va te dire que le matos marche, alors que les composteurs sont souvent aléatoirement en panne, et quand ils marchent il faut retourner le billet dans les 20 sens différents… Oui, 20 sens différents, pour un billet qui n'en a que 4.
Et tu crois qu'il se passe quoi, si je refuse de filer date de naissance, numéro de téléphone, et autres info douteuses aux automates de la gare du Havre qui ne te laissent pas prendre connaissance de tes droits, quand tu vas causer avec le contrôleur? Lui il en a rien foutre, de ta vie privée et de tes droits, il veut juste passer en speed dans le train prendre son café. Sinon, il passerait aussi quand le train est bondé à cause du train précédent annulé…
# Quand on confond problèmes du web et problèmes du net...
Posté par freem . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 9.
Je cite:
Avant, le délai était énormément lié au temps de transfert. Forcément, avec une liaison 56K… mais ça, c'est lié au réseau.
De nos jours, les sites sont lents, mais il arrive souvent que le problème soit le CPU, et ça, ben, c'est lié au site.
Ouai. Aujourd'hui, c'est apple vs google vs mozilla, principalement.
Avant, c'était microsoft vs netscape (mozilla).
Ah… oups en fait?
Chez moi ça marche (tm). Ben chez moi ça marche pas, marque de merde! Certains sites marchent sous FF, d'autres sous chrome, la plupart sur les deux.
Les exemples mis en avant sont valides, pour le coup. Mais j'ai quand même un contre-exemple: ouvrir un lien dans un nouvel onglet. Plus possible: le lien, c'est du JS.
hum… pour de simples sites web, sans vidéo, on est obligés de migrer l'infra vers la fibre ou la 5g, a cause de l'abus d'images (bien souvent qui n'apportent strictement rien).
Ce n'est pas un progrès. Ce n'est, certes, pas lié au web en soit, mais à son usage par les développeurs…
Je crois que le problème, il est la. Ici. Sur le mot applications. On a voulu faire du web un système d'exploitation, littéralement. Je doute fort que ça soit adapté par exemple aux blogs.
L'accumulation de technos et autres hacks fait qu'il est impossible d'écrire un client propre et 100% fonctionnel (dillo, netsurf essaient, mais rien que les CSS cassent de partout, JS n'est pas supporté) alors que le web se voulait décentralisé (hyper-liens) on se retrouve avec une poignée de moteurs de rendu développés de façon hyper centralisée.
Les développeurs de site, eux, utilisent la plupart du temps des frameworks pour masquer le bordel et les problèmes de compat, ce qui ne risque pas de rendre la chose plus légère…
Bien d'accord. Et c'est peut-être un des problèmes, justement.
Non. Ce serait une avancée.
Parce que le «nouveau web» serait spécialisé et meilleur dans son domaine. Tout comme le web actuel est spécialisé dans les applications interactives, rendant la création d'un blog sous-optimale. Le web d'avant permettait à un ado de faire son propre site web en 3 coups de cuillères à pot.
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par freem . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 8.
Ce n'est pas si surprenant… personnellement, je ne pense pas que «les développeurs web» en aient quoique ce soit à cirer du côté système ou de la maintenance. On parle du web la, la pile de technologies qui:
[^] # Re: Du coté Serveur / Station haute performance ...
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 3.
J'avais l'impression que tu ciblais juste les devs, mais dans tes examples ce ne sont pas nécessairement des devs qui sont impliqués?
[^] # Re: RE
Posté par freem . En réponse au message Mon ordi plante sans prévenir depuis que je suis sous Kubuntu. Évalué à 4.
Ça pourrait aussi être, tout simplement, du thrashing.
Pas simple de diagnostiquer ça sans avoir un outil de monitoring qui tourne constamment… perso j'utilise xosview, mais je ne doute pas qu'il en existe une chiée.
Avec un disque dur mécanique, on peut aussi utiliser… ses oreilles :) mais bon, de nos jours c'est plus trop d'actualité.
Bref, en gros, si quelques applis ont des fuites mémoire, ça peut vite pousser au thrashing, et la, reboot obligé (parce que l'oom-killer du kernel fait très, très mal son job de ce côté).
Pour contrer ça, j'ai appris récemment l'existence d'un outil nommé earlyoom, un oomkiller qui interviens avant le kernel, et surtout, avant que tout parte en couilles. Je ne sais pas ce qu'il vaut par contre, perso je me contente de désactiver l'overcommit (mais je connais les symptômes et je sais désactiver, je ne conseille pas de l'utiliser sans un minimum de connaissances système).
[^] # Re: Du coté Serveur / Station haute performance ...
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 6.
Je ne suis pas entièrement d'accord… je pense que certains comprennent. Notamment ceux qui ont acquis les bases avant d'apprendre l'info à l'école.
Je dis ça, parce qu'une phrase bien précise m'a braqué contre mes profs lors de mon BTS IRIS: "le client rachètera de la RAM".
IRIS, ça voulait dire: Informatique et Réseaux pour l'Industrie et les Services techniques hein, donc la perf et le vieux hard auraient du être omniprésents dans le principe au moins… c'était en 2000 et des bananes, C99 était déjà sorti depuis plusieurs années, et on nous enseignait encore
intau lieu deint32_t: ben oui, on peut racheter de la ram, ça coûte moins chez qu'une minute d'un dev (sauf que c'est pas juste la ram, mais aussi la sram, sans parler des problèmes de compat entre les archis…).Bon, en vrai, je les avais déjà grillés… 1er mois de cours, le prof avait sorti un truc genre "la solution opti, c'est
if( foo == true ){ ... } else if( foo == false ) { ... }"… et quand j'ai pointé du doigt le problème (supposé, parce que le compilo… mais bref) "mais on s'en fout" fut la réponse (et non pas un argument logique type: le compilo optimise).J'étais très (et je suis encore) content d'avoir commencé l'apprentissage du code comme un sauvage, 3-4 avant les «études supérieures»…
Je ne sais pas, cependant, s'il est aussi facile de trouver des ressources de qualité sur le net pour apprendre à coder… à l'époque (ou j'ai commencé), google était petit, les livres d'or courants, et le multi-coeur ou linux inconnus du grand public (moi-même ai appris au sujet du LL plus d'un an après avoir appris les bases du code)
[^] # Re: Du coté Serveur / Station haute performance ...
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 4. Dernière modification le 30 janvier 2021 à 03:26.
Tu oublies le bouton turbo qui, en fait, underclock le CPU :)
[^] # Re: Du coté Serveur / Station haute performance ...
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 3. Dernière modification le 30 janvier 2021 à 03:24.
Sauf que les claviers USB marchent pas si bien avec le noyal dont le nom de ce site est tiré… je me retrouve de temps en temps, via cette blagueuse de debian, a être sous initramfs (ouai, je bricole mon boot parfois, quand je toupine) et la… ha ben non, le clavier usb, il marche pas…
Je n'avais pas les compétences à l'époque pour juger, mais les claviers PS/2 ou 232 qui marchent pas pour aller au "mode sans échec" ou autres joyeusetés du même des goût, j'ai pas souvenir.
[^] # Re: Pour quel usage ?
Posté par freem . En réponse au journal Assembleur de PC en France. Évalué à 2.
.