It is scary to think about how much of web relies on projects maintained by 1 or 2 people.
[flagged]
Had a nuclear launch code. He doesn’t remember it anymore.
Freenginx: Core Nginx developer announces fork
201–210 of 501 posts
Re: Freenginx: Core Nginx developer announces fork
#202How the heck am I supposed to pronounce that? "Free-en-gen-icks"?
Re: Freenginx: Core Nginx developer announces fork
#203Earlier quoted context omitted.
I haven't read the content of the patches to understand the impact of the bugs, but from my own experience [0] I can suggest a few reasons: - CVEs are gold to researchers and organizations like citations are to academics. In this case, the CVEs were filed based on "policy" but it's unclear if they are just adding noise to the DB. - The severity of the bug is not as severe as greater powers-that-be would like to think…
To summarize: the more CVEs a "security researcher" can say he created on his resume, the more impressive he thinks he looks. Therefore, the incentive to file CVEs for any stupid little problem is very high. This creates a lot of noise for developers who are forced to address sometimes nonsense that are filed as "high" or "critical".
[deleted]
Re: Freenginx: Core Nginx developer announces fork
#204Earlier quoted context omitted.
if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!
If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
[deleted]
Re: Freenginx: Core Nginx developer announces fork
#205Earlier quoted context omitted.
If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
BRB, filing CVE's against literally any project with example code in their documentation...
I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...
Re: Freenginx: Core Nginx developer announces fork
#206Earlier quoted context omitted.
Thanks, I've never seen this fork mentioned before. This alone is compelling: "Simplifying configuration: the location directive can define several matching expressions at once, which enables combining blocks with shared settings."
Also owned by a for-profit company who offers a pro version.
Gotta pay the bills somehow
Re: Freenginx: Core Nginx developer announces fork
#207Earlier quoted context omitted.
I keep a Caddy server around and the config format is actually much, much nicer than nginx's in my experience. The main problem with it is that everybody provides example configurations in the nginx config format, so I have to read them, understand them, and translate them. This works for me because I already knew a fair bit about nginx configuration before picking up Caddy but it really kills me to see just how many…
> The main problem with it is that everybody provides example configurations in the nginx config format, so I have to read them, understand them, and translate them. This is so real. I call it "doc-lock" or documentation lock-in. I don't really know a good scalable way to solve this faster than the natural passage of time and growth of the Caddy project.
[deleted]
Re: Freenginx: Core Nginx developer announces fork
#208Earlier quoted context omitted.
FYI: Serving static files is easier and more flexible in modern versions of HAProxy via the `http-request return` action [1]. No need to abuse error pages and no need to embed the header within the error file any longer :-) You even have some dynamic generation capabilities via the `lf-file` option, allowing you to embed e.g. the client IP address or request ID in responses. [1] https://docs.haproxy.org/dev/configura…
Nice, I will have to play around with that. I admit I sometimes get stuck in outdated patterns due to old habits and being lazy. I'm a community contributor to HAProxy. I think I recall chatting with you on here or email, I can't remember which. I have mostly interacted with Willy in the past. He is also on here. Every interaction with HAProxy developers have been educational and thought provoking not to mention plea…
> I think I recall chatting with you on here or email, I can't remember which.
Could possibly also have been in the issue tracker, which I did help bootstrapping and doing maintenance for quite a while after initially setting it up. Luckily the core team has took over, since I had much less time for HAProxy contributions lately.
Re: Freenginx: Core Nginx developer announces fork
#209Earlier quoted context omitted.
LLMs baby! Input nginx config, output caddy config. Input nginx docs, output caddy docs. Someone get on this and go to YC.
LLMs do a horrendous job with Caddy config as it stands. It doesn't know how to differentiate Caddy v0/1 config from v2 config, so it hallucinates all kinds of completely invalid config. We've seen an uptick of people coming for support on the forums with configs that don't make any sense.
For just blasting a config out, I'm sure there are tons of problems. But (and I have not been to your forums, because...the project just works for me, it's great!) I've had a lot of success having GPT4 do the first-pass translation from nginx to Caddy. It's not perfect, but I do also know how to write a Caddyfile myself, I'm just getting myself out of the line-by-line business.