301–310 of 501 posts
Using Caddy instead.
A point came where I realised I didn't enjoy Nginx. Configuring it was hard and it felt brittle.
A particular pain point is certificates/ssl. I absolutely dreaded doing anything with certificates in Nginx.
When I heard that Caddy automatically handles SSL/ certificates I jumped the nginx ship and swam as fast as I could to Caddy.
It is scary to think about how much of web relies on projects maintained by 1 or 2 people.
It is also why companies don’t buy SaaS services from single founders or small companies where risk of key people leaving is high impact.
(Obviously once bigco buys such a startup's offering, that startup needs to hire, fast)
Earlier quoted context omitted.
I've recently needed to build a docker image to run a static site. I compiled busybox with only it's httpd server. It runs with 300kb of ram with a scratch image and tini. I didn't compile in fastcgi support in to my build, but it can be enabled.
yes busybox httpd or civetweb is even smaller, both around 300kb. for tini you mean https://github.com/krallin/tini ? how large is your final docker image, why not just alpine in that case which is musl+busybox
In this case, I didn't need alpine. I generally aim to get the image as minimal as possible without too much hassle. I end up doing stuff like this alot when I feel like a community image maybe too bloated when something like alpine or distroless can be used. Entry point scripts have all kinds of envars and a shell dependency, I'd rather rebuild the image to cater for my needs and execute the binary directly, and mount in any config via k8s.
Earlier quoted context omitted.
> Also this is kind of why everything is ever so slightly broken, IMHO. OTOH, things that update too often seem to be more than slightly broken on an ongoing basis, due to ill-advised design changes, new bugs and regressions, etc.
I am thinking with things that don't update often, we just get used to the broken parts. People learned to save every five minutes in Maya since the app crashes so often, for example. Every now and then, a PuTTY session will fill the screen with "PuTTYPuTTYPuTTYPuTTYPuTTY[...]" but it's been that way for at least 20 years, so it's not that remarkable.
Earlier quoted context omitted.
Because it's not actually part of the distribution unless you compile it yourself. It is not released any sense of the word. It is not even a complete feature. I am actually completely shocked this needs to be explained. Legitimate insanity.
It's in the published source code, as a usable feature, just flagged as experimental and not compiled by default. It's not like this is some random development branch. It's there, to be used en route to being stable. People will have downloaded a release tagged version of the source code, compiled that feature in and used it. By what definition is that not shipped? > I am actually completely shocked this needs to be…
Where did you get this info? It might be the feature is actively being worked on and the DoS is a known issue which would be fixed before merge. Lot of projects have contrib folder for random scripts and other things which wouldn't get merged before some review but users are free to run the script if they want to. Experimental compile time build flags are experimental by definition.
It is scary to think about how much of web relies on projects maintained by 1 or 2 people.
Earlier quoted context omitted.
I am thinking with things that don't update often, we just get used to the broken parts. People learned to save every five minutes in Maya since the app crashes so often, for example. Every now and then, a PuTTY session will fill the screen with "PuTTYPuTTYPuTTYPuTTYPuTTY[...]" but it's been that way for at least 20 years, so it's not that remarkable.
tangent but i havent seen that happen on any of my putty clients in years and i use it everyday, so i think that finally got fixed? or maybe was a side effect of something stupid
Earlier quoted context omitted.
It's in the published source code, as a usable feature, just flagged as experimental and not compiled by default. It's not like this is some random development branch. It's there, to be used en route to being stable. People will have downloaded a release tagged version of the source code, compiled that feature in and used it. By what definition is that not shipped? > I am actually completely shocked this needs to be…
>just flagged as experimental and not compiled by default Are UML diagrams considered in scope too?
Given this fork still boasts a 2-clause BSD license, the corporate nginx can still make the effort to backport patches. It's certainly harder than requiring a single converged development branch, but how closely they track Maxim's work is ultimately up to them. If nginx continues to receive more attention from security researchers, I imagine Maxim will have good reasons to backport fixes the other way too, or at leas…
I'm curious to see where this fork will go. The whole situation is a mess: - nginx is "open core", with some useful features in the proprietary version. - angie (a fork by several core devs) has a CLA, which sounds like a bait and switch waiting to happen and distro's won't package it - freenginx is at least open source. But who knows if it'll still be around by June.
I admit I haven't followed closely this issue, but what is he talking about? >In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers’ position.
We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.