-
C’est une bonne initiative.
Maintenant, il faut relativiser. Que cela ne fut pas fait plutôt par l’auteur même du serveur, ça craint un tant soit peu. Sur ce coup, httpd est “arriéré” ; aujourd’hui le support des formats compressés est généralisé. Le faire QUE pour gzip, sans oublier le support de “deflate”, même si c’est très bien, a peu de sens. Il faut aller plus loin dans la démarche, et bien supporter des formats actuels, comme brotli, webp, avif, etc… Et, là, httpd est encore à la traîne.
Quoiqu’il en soit, ne plus avoir à se servir d’un serveur CGI en sus, pour cela, c’est quand même une bonne chose !
Voilà.
PS : Merci à toi. :D Mais bon, perso, je préfère toujours… nginx
-
À la lecture de ton message, quelques remarques me viennent :
- L’auteur original de httpd a refusé la compression dynamique (à la volée), et à juste titre en terme de sécurité. Il semble se consacrer à autre chose actuellement, mais il a laissé un serveur http robuste, fonctionnel et simple. Tellement simple que même moi j’ai pu y ajouter une fonctionnalité.
- Tu évoques “deflate” et reproche ensuite à httpd d’être à la traine ?
- brotli : je me doutais que tu ferais cette remarque XD. À vrai, dire, si tu regardes le code, c’est assez simple à ajouter. C’est dans ma todo-list, mais j’aimerais déjà savoir si l’équipe veut bien de ce genre de choses. étape par étape.
- webp, avif : tu peux tout à fait en servir avec httpd. Du coup je ne dois pas comprendre le propos.
ps : nginx était excellent. C’est devenu d’une complexité navrante.
-
Bien que le sujet ne soit pas nginx, je ne vois vraiment pas en quoi il est d’une complexité navrante ! Il est aisé d’avoir une configuration fonctionnelle, correcte et utile.
Je pense ne pas être le seul à affirmer la “supériorité” de nginx, sa simplicité de configuration, ses “qualités”. Te connaissant, c’est plutôt le nombre de fonctionnalités qui te rebutent, non ?! À préférer l’un de l’autre, je n’hésite même pas à choisir nginx, qui supportent nativement bien des fonctionnalités utiles. Tu es dans le “minimalisme fonctionnel”, choix que je n’apprécie pas personnellement et que je ne plébisciterai pas. httpd en est un exemple.
Bref…
PS : je sais pertinemment qu’on ne sera pas du même avis, et que le mien a tendance à être “dissident”, si je puis me permettre l’expression.
-
je ne vois vraiment pas en quoi il est d’une complexité navrante
$ cd /usr/src/usr.sbin/httpd $ cloc * 22 text files. classified 19 files 19 unique files. 6 files ignored. github.com/AlDanial/cloc v 1.90 T=0.13 s (122.9 files/s, 101376.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 11 1390 706 7424 yacc 1 276 67 2169 C/C++ Header 3 133 86 921 make 1 4 2 16 ------------------------------------------------------------------------------- SUM: 16 1803 861 10530 -------------------------------------------------------------------------------$ cd src/nginx $ cloc * 100 files 200 files 300 files 400 files 452 text files. classified 449 files Duplicate file check 449 files (443 known unique) Unique: 100 files Unique: 200 files Unique: 300 files Unique: 400 files 449 unique files. Counting: 100 Counting: 200 Counting: 300 Counting: 400 86 files ignored. github.com/AlDanial/cloc v 1.90 T=1.97 s (186.3 files/s, 120252.4 lines/s) ----------------------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------------------- C 230 47921 5037 136723 XML 2 3902 14 25297 C/C++ Header 113 4312 955 8709 vim script 4 150 259 2057 Perl 4 71 51 159 make 2 55 2 138 SKILL 3 24 0 99 XSLT 1 39 0 89 Bourne Shell 1 33 3 84 HTML 2 2 0 40 DTD 2 14 0 30 C++ 1 9 3 19 Windows Resource File 1 3 2 1 ----------------------------------------------------------------------------------- SUM: 366 56535 6326 173445 -----------------------------------------------------------------------------------Voilà
-
Et, c’est sensé démontré quoi ? Que nginx comporte plus de fichiers embarqués. Qu’il semble être accessible à certains langages, et encore est-ce que c’est bien ce que cela signifie ? C’est certes une démonstration… mais pour l’heure incompréhensible !
Ce serait vraiment plus intéressant de démontrer les qualités, voire les défauts, les fonctionnalités supportées…
En quoi c’est navrant ? En quoi cela fait de lui qu’il est moins génial qu’avant, selon ce que tu affirmes ?
-
-
Je comprends ton raisonnement. Mais ne le partage pas ; la soit-disante “complexité” du code que tu lui octroies est différent de l’usage. Et, concernant l’usage : nginx est simple, et souvent bien plus pertinent qu’httpd d’OpenBSD.
httpd est pratique, certes dit sécurisé, léger, embarqué d’office, mais ne tient pas la charge face à nginx, ni n’a les qualités de nginx. C’est du “fonctionnel minimaliste”. Il m’est d’avis que fournir un logiciel aux fonctionnalités minimalistes, surtout au prix de la sécurité du code, doit être en effet plus léger qu’un logiciel offrant différentes fonctionnalités, permettant celles basiques dont par exemple la gestion des entêtes HTTP, mais aussi d’autres avancées, dont tu ne “rêveras” jamais ni avec httpd+relayd, alors que c’est natif à nginx (proxy, haute disponibilité, …). Et tout aussi facilement configurable.
Après nginx est assez modulaire, pour ne pas avoir besoin de certaines fonctions, si pas nécessaires.
Pour terminer, c’est quand même toi qui as écrit :
nginx était excellent
Perso, j’affirme que nginx est toujours excellent, et le préfère d’amblé à httpd.
-
-
-
-
-
-
[Comment removed by author]
-
Il n’est pas obligatoire d’apprendre un langage de programmation pour écrire un Makefile. On peut très bien écrire directement son site en html (ou que sais-je) et laisser le Makefile se charger du reste. Les outils que j’ai choisi d’utiliser, en C ou en shell, correspondent exactement à mes besoins. J’ai fait le choix d’étendre le Makefile à l’aide de ces scripts pour ajouter des éléments à mon site. Ils me sont pratiques, mais totalement facultatifs en définitive. Aussi, cette présentation a pour but de donner des idées : quelqu’un pourrait s’en inspirer pour faire des choses semblables, mais par des méthodes différentes.
ps : le programme codé en C n’existe que parce que je publie en http et gemini. C’est loin d’être courant, et n’est pas un prérequis au makefile.
-
-
PengouinPdt il y a 4 ans | lien | sur : Thunderbird : le client de messagerie open source trouve un nouveau support pour son développement
Bonne nouvelle que ce client soit pérennisé, et qu’ils aient trouvé un moyen légal de le faire “sainement”
:D
-
-
Je le ferai passer dans les liens intéressants du Journal du hacker semaine 50 pour mettre en avant la communauté autour de OpenBSD.
Tcho !
-
-
L'idée est bonne, mais plusieurs choses me dérangent dans cet article.
- Syncthing est un très bon outil, mais il n'est pas du tout adapté pour faire de la sauvegarde.
- Devoir chiffrer et déchiffrer manuellement, c'est vraiment pas pratique. Et ça nécessite d'avoir les données en double sur la machine source (données réelles, et données chiffrées).
- À moins de désactiver la synchro automatique (si c'est possible), on risque de perdre sa “sauvegarde” en la supprimant de la machine source.
- Même s'il propose du versioning, sans déduplication, ça consomme vite beaucoup de place.
- Si la nouvelle “sauvegarde” est un fichier différent, il va uploader la totalité du fichier, ou il ne télécharge que les bouts qu'il ne connait pas déjà ?
Pour de la sauvegarde, je te conseillerais plutôt de regarder du coté d'outils faits pour ça, comme Borg ;)
-
syncthing s'est bien amélioré niveau performances. - Je le trouve très adapté pour de la sauvegarde. Il faut toujours des copies de sauvegardes, pas qu'un seul exemplaire : syncthing permet de garder tout ça synchronisé. - Tu peux désactiver la suppressiond e fichiers qui auraient disparus, mais à quoi bon sauvegarder puis supprimer la sauvegarde ? - Tu as des exemples sur la place prise ? - Si tu chiffres, même avec rsync, ça sera un nouveau fichier, peu importe son nom, et le tout sera réuploadé.
Je connais borg, il ressemble beaucoup à rsync, et ce sont mes 2e choix au travers d'un tunnel SSH pour mes sauvegardes.
-
J'ai l'impression qu'on a pas la même notion de sauvegarde, ça doit influer sur la perception qu'on a de chaque outil :)
Ton article est intéressant, et Syncthing est très bien, c'est juste la notion de sauvegarde qui me gène ici :P
- Je le trouve très adapté pour de la sauvegarde. Il faut toujours des copies de sauvegardes, pas qu'un seul exemplaire : syncthing permet de garder tout ça synchronisé.
Je ne comprends pas trop ce que tu veux dire. Synchronisation et sauvegarde sont justement deux choses bien différentes pour moi.
- Tu peux désactiver la suppression de fichiers qui auraient disparus, mais à quoi bon sauvegarder puis supprimer la sauvegarde ?
Si je dois chiffrer une archive contenant la totalité de mes documents, je n'ai pas envie de conserver cette archive sur la machine source. Elle y est inutile, occupe de la place, etc.
- Tu as des exemples sur la place prise ?
Je n'ai pas fait de tests, donc je n'ai pas d'exemple, mais comme Syncthing travaille au niveau des fichiers, je suppose que conserver 3 sauvegardes de 1 GB de données occupe 3 GB, non ?
- Si tu chiffres, même avec rsync, ça sera un nouveau fichier, peu importe son nom, et le tout sera réuploadé.
Justement, je n'ai pas cité rsync mais Borg, qui peut chiffrer et dédupliquer (et ne ressemble absolument pas à rsync).
Sur une sauvegarde d'environ 500 Mo de data diverses, avec une connexion ADSL 5 Mbps/900 kbps, ça met en moyenne 3~5 secondes pour créer une nouvelle sauvegarde ne contenant aucune modification. Je n'aimerais pas avoir à uploader ces 500 Mo à chaque fois. Et je fais cette sauvegarde sur deux machines distantes différentes, ce qui serait encore plus problématique (elles sont faites séparément, pour éviter de synchroniser une corruption d'un backup :P).
-
-
En passant, BURP est pas mal aussi si tu veux économiser les ressources : https://burp.grke.org/index.html
-
:)
-
ah ben bravo, voilà que ma ligne ADSL ne tient pas la charge… :/
-
-
-
-
le service extérieur, tu le connais… mais tu ne veux pas l'utiliser ! :p
-
-
Là, t'es à côté… cherche plus proche de toi… un certain arrakiss ;)
Tu sais très bien que Google, je m'en fous Et, puis pour le monitoring, tu as celui dont je me sert pour le serveur A :D (rohhh, purée j'ai oublié le nom !)
-
Letsmonitor.org !!!
-
-
-
-
-
-
-
Ça fonctionne bien, c'est verbeux, ça fait du bien aux serveurs :)
-
Justement, on ne parle pas de performance ici, mais de sécurité.
-
Ben oui, surtout après avoir déménagé au fond de la cambrousse Nantaise avec un débit minable. Vivement la fibre, d'ici quelques mois ou 1 an, ils sont très flous à ce propos.
-
Intéressant. Il serait bon de détailler les avantages que ça apporte en termes profanes, notamment en comparaison d'un unbound par exemple.
-
Non ! Non, mais… dis, donc, toi, hein :p
Chut, y'a mieux encore ;)
Une histoire de couple entre unbound (en mode DNSSEC, bien sûr) et stubby… T'inquiètes, je prépare la vaseline, euh, non, pardon, les informations ;)
-
-
Quelle belle page sur ce wiki ! Bravo à l'auteur, quelle réactivité! ;=
-
Le compliment me va droit au cœur. Merci :D
-
-
Cette semaine, c'est publication d'isotop : une image d'installation d'OpenBSD 6.2 pour plus facilement l'utiliser en desktop. L'interface est simplifiée, on peut maintenant faire une installation en ligne ou hors ligne selon la patience, plusieurs scripts facilitants ont été corrigés… À suivre ^^
-
J'aimerais mieux utiliser ces calculs pour un projet BOINC à vrai dire.
Avant de taper sur les Proof Of Work, regarder la consommation électrique engendrée par une recherche google fait réfléchir aussi… Et monero est suffisamment différent de bitcoin quand même, bien que ça ne soit pas parfait.
@Buzut : oui je ferai un retour. Là, en 4 jours, j'en suis à 0.00111 XMR générés. C'est pas si anecdotique comparé aux pubs en fait.
-
-
Je dois maintenir plusieurs sites dont https://obsd4a.net. Je publie isotop, une iso pour installer une OpenBSD-desktop. Je me colle à une traduction simplifiée de mon guide sur l'auto-hébergement doucement.
-
Salut. Je me prépare à devenir un CHATON. Pour l'occasion, je gère désormais entièrement ma zone DNS en me faisant serveur autoritaire.
-
- Travaux sur la documentation pour s'auto-héberger avec OpenBSD. Plusieurs ajouts sont prévus notamment au niveau renforcement de la sécurité, avec quelques outils développés par bibi.
- Etude du code de txt2tags, j'aimerai reprendre la syntaxe pour faire un outil en python3, au moins pour la génération html. Cependant, de nombreuses améliorations du code n'ont pas encore été publiées donc c'est un peu brouillon
- Relecture des cahiers du débutant (debian)
Ce lien ne parle pas du tout d’OpenBSD et encore moins de Raspberry !
Le bon lien est :
Merci de corriger ;-)
Ce matin le lien parlait bien d’openbsd. L’auteur a du changer l’organisation des pages depuis.
Soit !
De toute façon, l’article est en soit très pauvre - c’est plus du #JeRaconteMaVie, qu’un modus operandi. Et si l’auteur n’est pas capable de garder correctement ses URL… dommage pour lui. :(
Bref.
Merci à toi, quand même ;)
Le mode opératoire est dans la doc officielle de toute façon. Je trouve intéressant de lire “ça marche” et les choix effectués.
Pourquoi ?
mode taquin : parce qu’il te cite à plusieurs reprises ?! :p
C’est indéniablement une personne de bon goût ! :P