Hacker Newsnew | past | comments | ask | show | jobs | submit | nick-sta's commentslogin

I don't see the issue - the creator is reserving the right to create their own paid hosted version?

That's absolutely fine for them, but they shouldn't call it "Open-source" and "Fully open source" (like they do on the linked page).

This software is source-available. Open Source licenses don't discriminate on the basis use of the software.

Using the term Open Source for license like this is dishonest. It seeks to profit from the goodwill from actual Open Source software.


I appreciate your view but consensus reality does not agree: https://en.wikipedia.org/wiki/Open_source

I can link to community-edited articles, too: https://en.wikipedia.org/wiki/Open_Source_Definition

We make the consensus reality. I'm part of the faction that wants this particular reality, so I advocate for it.


OSD !== Open Source. All OSD is Open Source, not all Open Source is OSD. You are free to disagree, but the OSI has chosen (more accurately forced to choose) very explicitly to only define and trademark OSD. There's really not much more to the conversation then that.

Maybe you're right, but FSL/BSL is arguably "more open source" than GPL. We all know GPL is a poison pill that kills commercial use, while FSL/BSL just blocks competitors from stealing your app.

That's not even remotely true. GPL does not prevent any commercial use, when others (like BSL or the O'Sassy license here) explicitly prevent commercial use...

Are you kidding me? If you link against a GPL library in a proprietary commercial app, the GPL's copyleft infects that code and you'd have to release it under GPL.

Explain to me how that doesn't prevent commercial use? Are you going to say "well technically it doesn't prevent it"? No one cares. Commercial projects avoid GPL like the plague.


I'm working on a project for deploying containerized workloads across your own servers, but with great dx from starting on a $5 server to migrating/scaling to 200 servers (no downtime required for any migrations). think coolify, but with railway dx and no single server limitations.

there's no control plane, each node is equal and eventually consistant and its (so far) end to end rust so a very minimal footprint per node.


I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it?


Basically, it shows that Cloudflare's WAF (which is supposed to intercept requests before they make it to the origin server), is trivially bypassable by using the `.well-known/acme_challenge` path.

That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated


It's possible you're rendering more than just a simple 404, such as an SPA response or other result as part of an application response that may leak more information...

I think it's not a severe issue in most cases, and maybe something worth noting or addressing if you are at least aware of it, you can just 404 without content, for example in the .well-known/ path. I run most of my apps behind Caddy, which handles that path itself and doesn't forward requests to that path, so I'm curious how it handles it tbh.

I'm also not sure that there's a clear/good fix for this, since CF is allowing the traffic through so that ACME negotiation can work against the final application host.


All their examples rely on having poorly configured origins. At least the PHP and Tomcat ones might be blocked by a WAF, but the Next.js one would rely on the WAF blocking responses that included secrets (which I’m not sure they do).


I think the idea for the NextJS example was that there might be some configuration variables that are not sensitive for internal / staff users, but would be problematic if exposed externally—basically, relying on Cloudflare's WAF as a "zero trust" endpoint solution, like Google IAP.

I'm not sure how realistic this is in practice. Does anyone actually configure Cloudflare WAF this way? (As opposed to, e.g., Cloudflare's dedicated zero-trust networking product, which I think works completely differently?)


Looking forward for true async to land - nothing here gets me too excited.


You probably know about https://openswoole.com right?


I’ve also had this sound on my 3s, but only when handling them before putting them in my ears. I’d say it’s happened at least 10-15 times, and every time I’ve thought it’s so loud it’d do damage if it was in my ears.

Anecdotally I’ve done four 11+ hour flights with them so far and they’ve been super solid on the plane - no issues there.

Edit: here’s what I mean - https://youtube.com/shorts/VvEjetlYwa8


Love the website design, but that rsc lag is painful.


Have a look into singlestore - it seems like a nice fit for this use case.


Cost per search isn't really a great metric. For me, I hit the cap of 30 searches/day pretty easily, but 500 is pretty hard to hit. For me, its just a question of what tier matches my volume.


My left ear enjoyed this


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: