Hacker Newsnew | past | comments | ask | show | jobs | submit | SOLAR_FIELDS's commentslogin

It’s worth pointing out that it can be both. The hub and spoke model, relays, is often used for cloud setups where the overhead of installing clients on nodes is not worth the tradeoff

I believe strongly that people have zero problem paying their knuckle dragging police fuckwad of the day $150k if they would actually do the job they signed up for. It’s the fact that 99% of them can’t handle it that pisses people off

I’m glad Benn has gone into the YouTube space. He has demonstrated a great balanced view on how to sell your soul for advertisement money in YouTube land.

I’ve known of him a long time simply because of his extremely progressive views towards releasing his own music. In other words, I would not care about Benn Jordan but for the fact that he was releasing his own torrented music on WCD 15 years ago


Are you saying that because you fundamentally just don’t believe the db is a good place for auth, or because these low-code frameworks tend to roll it in and as such you see a lot of low quality implementations of auth from these systems simply because using them is within reach of someone who has no idea what they are doing?

To me it’s important to make this disambiguation. One take says that auth in db itself is a problem. The other take says “auth in db is a symptom of low code garbage”


I like to separate concerns. Unix philosophy and all that. That was the primary concern on my mind when writing my comment above.

I think the feature is there not necessarily because it’s the best technical idea but instead because of its ability to pull in less educated developers. That makes sense financially because there are fewer people out there with a higher degree of expertise. But from my perspective it shows that it’s not meant for me.


FWIW firebase auth and firebase DB are two separate things, and you can use them completely separately. However "Firebase" is a PaaS so I see how it gets confusing.

Fair call out but if I am a firebase customer, as I have been in the past but less frequently so, I treat them as a singular entity. In other words, there’s no situation I would use firebase and not use its auth, because the reason I might use firebase is Because Of the auth, not In Spite Of. There’s no world for me where firebase is the preferred option that doesn’t use auth, the integration like that is literally the only reason I would ever consider ClosedSourceOwnedByGoogle over alternatives

It’s even worse than No Idea what you are Doing. One can, as has been alluded to in other comments, be a completely naive rube who is using Supabase under the hood with v0 or Lovable and not have any idea that you’re even using it or that it exists at all.

The situation is more nuanced than your comment implies, and a lot of this due to direct product decisions from the Supabase team themselves: https://github.com/orgs/supabase/discussions/4547

The tldr is that Supabase makes this less secure by default because Security is Hard and they don’t want to scare off new users


More likely reason is that Supabase is a BaaS. Between client and DB there is no backend for secret management. So RLS is the only way to directly create API on the DB.

I’m not sure anyone’s scared off by this. It’s more that it’s more intuitive to declare your user queries (like Meteor did or how GraphQL works) than to reason about RLS.

It’s not about being scared off, I’m simply challenging the notion that Supabase is secure by default. It depends on your definition of secure, since everyone has a different threat model, but the above thread demonstrates that probably a good chunk of people would say No, it’s not actually secure by default. Being scared off would be probably the best possible outcome over the current situation which is “we don’t really have a good story to tell about whether this is secure or not”.

The fact that it takes a whole thread of conversation to even unwrap whether the default approach they took is good enough is a strong signal to me that it isn’t, because that level of complexity in the implementation often implies a model with a large enough attack surface with weaknesses that can be exploited without too much effort


My beef with zeds implementation is they haven’t kept it up to date. I really like the ide integration but when you don’t support half the things that make Claude code really nice, like hooks, it kinda defeats the purpose

GitLab CE has the runner implementation baked in.

Keep in mind GitHub Actions is actually like 5 different products. So are you asking for the webhooks/events implementation, the runner orchestration implementation, the runtime image, the secrets storage implementation or the marketplace? All of these could theoretically be disparate components. GitLab gives you everything above but the marketplace


This is a much lighter take than mine which is that our behaviors being input into this system will eventually be used to subjugate and control future generations. I like it

In Texas the law exists as well, phrased as cannot offer price below wholesale price for alcohol which in effect bans “bottomless/all you can drink” deals as well. It is indeed designed as a way to discourage consumption


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

Search: